Pricing and Plan Selection for Design Teams

This is the most perishable page on this site, and it says so up front. Every figure below is a US-dollar list price captured from the vendors' official pages on June 1, 2026. All three major vendors changed their plans or their metering in the eight weeks before that date, and there is no reason to think the pace slows. Treat this field note as a dated snapshot plus a way of thinking, not a price list: verify every number on the official pricing page before any decision, and note that this page sits in the site's tool-watch loop, which re-verifies the figures on a recurring cadence and flags drift for correction.

Two scope notes. This is not procurement, financial, or legal advice, and it makes no claim about which option is cheapest beyond the dated figures shown — your usage pattern, billing term, region, and existing subscriptions change the answer. And it deliberately covers only money and plan fit. Everything else that goes into choosing a platform — sandboxing, instruction files, skills, MCP, churn risk — lives in the platform-comparison article, which was verified on the same date so the two pages do not disagree.

The most useful thing to understand about agent pricing in mid-2026 is not any individual number but the shape. The three big vendors have converged on the same individual ladder: an entry tier around $20 a month, a middle tier around $100 pitched at daily professional use, and a top tier around $200 pitched at all-day use. That symmetry is recent — OpenAI added its $100 tier in April 2026, and Google restructured its plans around a $100 middle Ultra tier at I/O 2026 — and it makes the ladder itself a reasonably stable mental model even as the decimals move (captured 2026-06-01).

What actually differs is how usage is metered, and for a design team the metering model matters more than the sticker price, because visual iteration is heavy: screenshots in, regenerated layouts out, long design-system context, repeated passes. There are three models. Subscription usage windows (Claude) give you a rolling allowance — currently five-hour windows shared with the chat apps — that fails by making you wait when a heavy iteration day exhausts it. Credit metering (ChatGPT/Codex since April 2026, and in effect Google's tiered limits) draws your usage against token-equivalent credits, which never stalls mid-loop but fails by surprising you on the bill or the meter. Bring-your-own-key (OpenCode and any direct API route) prices the model rather than the seat, which fails by becoming nobody's job to track until finance asks. None of these is wrong; they fail differently, and the right plan is the one whose failure mode your team can actually manage.

One more pattern worth naming because it protects you from bad comparisons: vendors describe usage limits relative to other tiers — five times Pro, twenty times Pro — not as absolute token or message counts. Any article or salesperson quoting you a hard number of messages per tier is making it up; this one will not.

• Subscription windows (Claude): predictable monthly cost, shared rolling allowance; heavy days hit the window and stall the loop.
• Credit metering (ChatGPT/Codex; Google's tiered limits behave similarly): work never stalls, but heavy review days cost multiples of normal ones.
• BYOK / API (OpenCode, direct API): pay for exactly what you use, manage your own keys and your own cost tracking.
• All limits are relative (5x, 20x); vendors do not publish absolute token numbers, so neither does this note.

The table below is the core of this note and the part most likely to be wrong by the time you read it. Every cell was captured on June 1, 2026 from the linked official pages; the ChatGPT Go and $100 tiers and the Google plan details were located via announcement posts and press on that date and should be confirmed on the vendors' own pricing pages — as should everything else — before you decide. Prices are USD list prices; regional pricing and tax differ.

Reading it as a designer rather than a buyer: every paid tier from roughly $20 up gets you a capable agent with image input; the middle ($100-class) tiers exist because daily design-to-code work genuinely consumes more than entry allowances; the team and business tiers are mostly about seat administration, central billing, and SSO rather than more capability per person; and the BYOK route is the only one where spend tracks actual usage rather than seats — which is either its best feature or its biggest administrative burden, depending on who has to track it.

Plans, monthly USD list prices, metering model, and design-relevant notes. Every cell captured 2026-06-01 from the linked official sources; re-verify on the official pricing pages before deciding. This table is re-checked through the site's tool-watch loop.

Plan pages are written for developers and general productivity users, so the capabilities that decide whether a plan works for design go un-headlined. Three things matter disproportionately. First, image input and the screenshot loop: design work is multimodal — you paste mockups in and screenshot results out — and that traffic is exactly what burns windows and credits fastest, so the realistic question is not does the plan support images but how many screenshot-review cycles a day fit inside its allowance. Second, parallel and background agents: subagents, agent teams, and cloud tasks multiply usage in exchange for time, and the middle and top tiers exist substantially because of them; if your workflow leans on a critique agent running alongside a build agent, budget for the tier above the one that looks sufficient. Third, seat administration: the moment more than two or three designers are involved, central billing, SSO, usage visibility, and the ability to mix standard and premium seats matter more than a few dollars of per-seat difference — that is what the team and business tiers are actually selling.

There is also a habits dividend that works on every plan and costs nothing: keep context scoped to the task instead of the whole repository, crop screenshots to the component under discussion rather than pasting full-page captures, use cheaper or faster models for rough drafts and the frontier model for the final pass, and clear or compact long sessions instead of letting them grow. Teams that do these things stretch an entry tier surprisingly far; teams that do not can make any tier feel small. Measure your own usage during a normal week before upgrading — the meter is better evidence than anyone's heuristic, including the one in the next section.

With the metering models understood and the snapshot in hand, plan selection mostly reduces to matching usage intensity to the rung of the ladder. These heuristics are deliberately number-light so they survive the next price change; pair them with the dated table above and the official pages on the day you decide.

Two cross-cutting notes. If your organisation already pays for Claude or ChatGPT, the agent included in that plan is the cheapest one to evaluate seriously — start there before adding a new vendor. And whatever you pick, treat the first month as the measurement period: one designer on the middle tier producing real work tells you more about your team's economics than any comparison article, this one included.

• Occasional use (a few sessions a week, prototypes and explorations): an entry tier around $17–20 — Claude Pro or ChatGPT Plus — is enough; upgrade only when you actually hit limits (figures captured 2026-06-01).
• Daily design-to-code work (one to three hours a day, screenshot loops, real components): the $100-class tier of whichever ecosystem you are already in; this is the rung built for that pattern.
• All-day power use (agent-first workflow, parallel agents, large design-system context): the $200-class tier, or API/BYOK billing if your usage is spiky enough that a flat seat price fights you.
• A mixed team (a few heavy users, many occasional ones): a seat plan with mixed standard and premium seats, or entry tiers for most plus mid tiers for the heavy users — let measured usage, not job titles, decide who gets which.
• Compliance-heavy or budget-controlled organisations: enterprise agreements or the API/Console route, where admin controls, data-handling terms, and spend limits live; expect this to be a procurement conversation rather than a credit-card decision.
• Cost must track usage exactly (agencies billing clients, finance-driven teams): the BYOK/OpenCode route — and assign someone to own key management and cost reporting on day one.

Everything here is about money and plan fit. Which platform produces better design output for your stack, how their sandboxes and permission systems differ, what ports when you switch — that is the platform article's job, and the two pages are kept consistent on the figures they share, both verified on June 1, 2026. This note also stays out of regional pricing (figures are USD list prices), negotiated enterprise terms, and anything that resembles procurement advice.

As for expiry: assume the snapshot starts decaying immediately. The figures are re-verified through the site's tool-watch loop and corrected when they drift, and the last-reviewed date at the top of this page is the honest indicator of how stale it might be. If that date is more than a quarter old, read the four linked pricing pages first and this note second — the metering models and the selection heuristic will likely still hold; the numbers may not.