Price and limits are the most volatile part of the product and at the same time the part decisions are most often made on. Writing them as eternal truth guarantees going stale; not writing them leaves the reader without a bearing. There is one way out: show a snapshot with a date and honestly hand the current state to the live page, not to the book's memory.
The naive move is to learn a plan and a number once and rely on them as fact. Or the opposite - to wave it off since it all changes anyway. Both get in the way: the first deceives with a stale line, the second removes any footing where a bearing for the order of magnitude is still needed just to choose a plan.
The naive model breaks on the fact that billing changed entirely. In March 2026 self-serve moved from a credit system to a token-based quota: the budget is counted by tokens, and a token's cost depends on the model you chose. What was learned about credits simply stopped describing reality, and holding on to it means counting in a unit that is no longer in the interface. The switch was not cosmetic: the unit of counting itself changed, and with it the way to estimate how long a plan lasts.
How the quota works now. A plan includes a daily and weekly budget that resets by the calendar, not by a rolling window. Free models do not consume quota at all, so part of the work can be done without touching the limit. After exhausting it, paid plans may continue through extra usage billed at the API list pricing of the model in use. Enterprise ACU and legacy enterprise credits are separate billing systems, and they must not be mixed with self-serve quota: these are three different currencies, not one under different names. Trying to convert credits into tokens or ACU into quota from memory is a sure way to be off by an order of magnitude.
A dated snapshot of the plans and prices as of 2026-08-11 is gathered in the table below. It is precisely a snapshot: it records the state on a specific date, not a promise for the future, and it must be read with that caveat, not as a price list you buy from.
Why a snapshot rather than a price list. Prices, taxes, regions, grandfathering, promotions and entitlements change independently of one another and faster than the text lives: an old user may pay an inherited price while a new one in another region pays a different one with tax. Exact quota caps the public page does not record at all - so a specific limit number cannot be learned, only looked up in usage at the moment you need it. Hence the form of presentation: a figure is named with a date, and a limit is sent to be looked up in usage rather than memorized.
The professional mechanism is to treat a price line as a fact with a date and a source. Every figure here has a snapshot date and an official owner page. Applying it, you do not trust the book's memory but go to the pricing and plan page and check the current state. The snapshot poses the question and the order of magnitude, the live page gives today's answer.
| Plan | Price on 2026-08-11 | Key boundary |
|---|---|---|
| Free | $0 | Light quota, limited models |
| Pro | $20/month | Frontier models, Cloud, extra usage |
| Max | $200/month | Well above quota |
| Teams | $80/month team + $40/full seat | Collaboration, admin, billing |
| Enterprise | By contract | SSO, controls, deployment options |
The cost of trusting a stale line is a purchase or a load decision made on a figure that no longer exists. Choosing a plan by an old quota, hitting the daily limit in the middle of a task, underestimating extra usage at the API price and getting a bill larger than expected - all follow from one thing: the snapshot was taken for a price list and not checked before spending. The difference between the snapshot and the live page costs exactly one click, and ignoring it costs one wrong subscription.
When the snapshot is useful. As a bearing for the order of magnitude and the structure of the plans: to understand that Pro and Max differ by the scale of quota, not by a feature set, that Teams adds admin and billing, and Enterprise adds SSO and deployment options. For a real decision it is not enough - before buying you open the live page and look at the actual figures for the current date and your region. The snapshot answers what order the costs are, but not how much exactly to pay today.
Verify at three points before money is spent. Open pricing and confirm the current price and plan structure. Look at usage and see the actual remaining daily and weekly quota. For extra usage check the API list pricing of the model you need, so you know the cost of continuing past the limit. Three glances take a minute and cost less than a wrong subscription or an unexpected bill.
The typical failure is quoting a price from the book as current; looking for an exact quota cap where it is not published; confusing enterprise ACU with self-serve quota; treating free models as consuming budget. The sign is the same: money is discussed without a date and without a page. Name the snapshot date and open the official page - and the figure becomes verifiable again rather than learned by heart.