Limits

What is measured, what is a fixed ceiling in the code, and what is deliberately not published yet. A guessed number would be worse than none, because publishing it makes it the promise.

The context window

GET /v1/models publishes the window under both context_length and max_model_len. When the engine does not report one, the fields are omitted rather than guessed: a client sizes its own history against that number.

The number it publishes is yours, not the box's. A plan grants a window, and the published figure is the smaller of that and what the engine serves. Read it with the credential you are going to send: a key and a browser session on the same account are not told the same number.

The window is wider on the API surface than in the browser. They are not the same workload. A conversation is a person typing; a coding client resends the files it is working in on every turn, which is what the OpenAI-compatible surface is for and what the room is spent on. The segregation is also what keeps the box answering many people at once: the engine holds one KV cache, a conversation that fills the window occupies what several short ones would have shared, and no queue discipline gives that memory back.

The widest window is the four-week commitment's. A monthly subscription carries more room in an editor than the same tier billed by the week: the KV a full-context coding session holds is the most expensive thing the product gives, so it goes to the subscription that is paid four weeks at a time. The browser window does not move with the interval.

Each plan's figures are on GET /api/billing/plans, as context_tokens for a browser and context_tokens_api / context_tokens_api_monthly for a key on each interval. They are served no wider than the engine reports, so a plan written for a wider box than the one answering today is published at what today's box can hold. What you may fill right now is the one on GET /v1/models, read with the credential you will send.

A request whose history is past your window is refused with context_overflow before the model is touched, so nothing is charged for it. That check is a deliberately generous estimate rather than a token count: the exact ceiling is still the engine's.

The published figure is deliberately below the serving ceiling, by a fixed reserve. The engine's ceiling covers your prompt and the answer together, and two of the tokens under it are not yours to count: we prepend a system prompt you never see, and the answer has to fit. Publishing the raw ceiling hands every client a number that is rejected the moment it is reached.

Treat the published number as the budget your history may fill, and compact before you reach it.

A request whose prompt plus max_tokens crosses the ceiling has its max_tokens refitted to the room the engine itself reported, and is sent again, once. A prompt that leaves less than 512 tokens of room returns context_overflow: below that there is no useful answer left to give, and only your client can compact its own history.

Reasoning ignores max_tokens

By design, and it is measured rather than chosen. See chat.

What context costs

Prompt size dominates: one stream gets slower per token the more history it carries, and a full-context turn costs several times what a short one does. Compacting your history is the single thing that most improves how fast your client feels.

The figures that used to sit here were measured on hardware this product no longer serves on. They are removed rather than restated: the model is served by a provider today, and its rate has not been measured here. When it is, the table comes back with the date it was taken.

Rate limits

Still not published, and deliberately not guessed. The per-tier request limits follow from a fair-use rate that has to be set against real usage rather than against a bench, and the measurement that decides it has not run.

What happens at the ceiling is decided, and it is a wait rather than an error. When the serving side reports that its minute is full, requests are held at our door until it resets and then sent in the order the plans buy: the better the plan, the sooner the turn leaves. Yours is sent again once when it was the one rejected, and it takes its place in that order rather than keeping the front. A 429 reaches you only if the ceiling is still there on the second try.

What is true today: chat and code are unlimited within fair use on the paid plans, images are a counted number per week, and the two lookup tools are a counted number per week on paid plans only. The counts themselves come off GET /api/billing/plans and GET /api/account/me, which is where they stay current.

The ceilings that are fixed

These are constants in the code rather than commercial decisions, and they do not move with a plan.

Where the numbers live

No figure a user sees is computed in a client. Everything above that can change with a deployment or a plan is read from the server:

• GET /v1/models for the context window.
• GET /api/billing/plans for what a plan includes.
• GET /api/account/me for what is left of it this week.
• GET /api/status for whether the model is reachable at all.