When you use more than one coding model, a token count stops being a useful mental model for your budget.
One model may spend most of a request on input context. Another may produce a long reasoning trace. A third may reuse cached context efficiently. The same task can have very different token shapes, and the provider cost reflects those differences. A quota that counts only raw tokens would make model choice part of the billing puzzle.
I built Codius around a different unit: provider-cost-adjusted usage. We turn the cost of a request into comparable usage units, then apply the model's configured quota multiplier. You still get a predictable allowance, but you do not have to translate every model choice into a different token budget before you start working.
This is one piece of the broader command-center problem I described in why I built Codius: once agents and models share a workflow, their resource rules need to be understandable in one place too.
This post explains how that works in the code today: the calculation, the three quota windows, the reservation and settlement path, and the limits that matter for Pro and Max.
The problem with a universal token allowance
Tokens are real and useful. They are also only one part of the accounting story.
A request can include uncached input tokens, cached input tokens, generated output tokens, and reasoning tokens. The input can also cross a context tier where the provider rate changes. Counting those as one undifferentiated token total would hide the parts of a request that actually affect cost.
That creates an awkward choice for a coding-agent product. If the quota is generous enough for the most expensive model, it is difficult to make the same allowance meaningful for lighter models. If the quota is based on the lightest model, switching models can make the allowance disappear much faster than a developer expects.
The other option is to publish a separate token allowance for every model. That is accurate in a narrow sense, but it puts a pricing table in the middle of the development workflow. I wanted Codius to let people choose a model for the task, not choose a model because they had memorized a conversion rate.
Usage units start with provider cost
The metering path begins by calculating a provider cost in integer micro-USD. The implementation handles the cost components separately:
- uncached input tokens use the model's input rate;
- cached input tokens use the cached-input rate when one exists;
- output tokens use the output rate; and
- reasoning tokens use a reasoning rate when one exists, otherwise the output rate.
The input token count selects the applicable context tier first. Every calculation uses integer arithmetic and rounds up, so a fraction of a micro-USD never disappears through floating-point rounding.
When a provider gives us an exact cost at settlement time, that reported value is authoritative. If exact cost is not available but token usage and locked model rates are available, Codius calculates the cost from the actual usage. If neither is available for a successful request, the system can settle using the conservative reservation estimate. A request known to have failed before it can be charged releases the estimate instead.
There is also a conservative admission estimate. For providers without a model-specific tokenizer, Codius estimates tokens from UTF-8 byte length using three bytes per token. Code, JSON, and tool schemas often tokenize more densely than prose, so this deliberately errs toward reserving enough capacity. The reservation is not the final bill: settlement replaces the estimate with the best cost signal available.
The result is then converted into quota units with a model multiplier:
adjusted usage units = ceil(provider cost × model quota multiplier)
The code stores the multiplier in basis points, where 10,000 basis points is 1×. For example, a request with a provider cost of 118,000 micro-USD and a 1.25× model multiplier becomes 147,500 usage units. That exact relationship is covered by the metering tests.
This is the important distinction: Codius is not pretending that every model has the same raw cost. It is making the cost difference explicit in the unit that consumes your allowance. A long-context or reasoning-heavy request can use more units. A model with a different configured multiplier can use more or fewer units for the same token shape. The quota is comparable because it follows the cost model rather than ignoring it.
The launch allowance: Pro and Max
The current launch policy is intentionally simple and locked in the billing catalog.
For Pro:
- 5,800,000 included units per monthly entitlement period;
- 1,160,000 units in the five-hour window; and
- 2,900,000 units in the weekly window.
Those shorter windows are 20% and 50% of the monthly Pro allowance. Max is exactly 5× Pro across all three values:
- 29,000,000 monthly units;
- 5,800,000 five-hour units; and
- 14,500,000 weekly units.
The plan price is separate from the unit math: Pro is $20/month and Max is $100/month, with yearly catalog prices also defined in code. The 5× relationship is enforced by validation rather than being a label on the pricing page. If someone tries to publish a Max policy with a different multiplier, the catalog and metering tests reject it.
That makes the promise easy to reason about. Max gives more included capacity and higher concurrency, but it does not introduce a second quota philosophy that a team has to learn.
Why there are three windows
A monthly cap alone is too slow to protect a developer from one unusually intense session. A short cap alone is too restrictive for a sustained project. Codius uses both, plus a weekly middle layer.
The five-hour window
The five-hour window is a fixed five-hour period that starts lazily when a request needs it. It is not a forever-renewing token bucket and it is not a calendar hour. When the active window expires, the next request starts a fresh window with the full limit.
For Pro, that limit is 1,160,000 units. If a long-running agent session consumes the window, Codius can tell the caller which window is blocking admission and when it resets. That is more useful than a generic “quota exceeded” response: your monthly allowance may still be available even though the short window is full.
The weekly window
The weekly window lasts seven days from its lazy start. It prevents a concentrated burst from consuming the whole month while still allowing a developer to use more than the five-hour limit over a longer project cycle.
For Pro, the weekly limit is 2,900,000 units. The window is independent of the billing-cycle boundary. Its purpose is to create a middle pace between an intense session and the total monthly entitlement.
The monthly entitlement window
The monthly value follows the active entitlement period. For a monthly subscription, that is the subscription period. For an annual subscription, the billing period is still divided into independent monthly entitlement periods rather than giving the account one giant annual bucket.
Included usage does not roll over. When a window expires, unused capacity is not added to the next window. That keeps the allowance predictable: a reset means a fresh limit, not a surprise pile of old capacity.
All three are enforced together
Codius checks the remaining capacity in the five-hour, weekly, and monthly windows for every request. Admission can reserve only the smallest available amount across those windows. In practical terms, a request needs to fit through all three gates.
That also makes usage percentages meaningful. The dashboard can show the percentage and reset time for each active window instead of reducing your account to one number that hides the reason a request is waiting.
What happens when an agent request starts
Quota accounting has to handle concurrency, retries, cancellations, and estimates. A simple “subtract after the response” counter would let several requests race for the same remaining capacity.
Codius handles admission and reservation atomically. Before the provider request runs, the service:
- loads the model price and quota multiplier;
- estimates the provider cost from the request body and effective output limit;
- converts that estimate into adjusted usage units;
- checks the three windows and the organization concurrency limit; and
- reserves the included units that fit across the windows.
The reservation is associated with the request and its window IDs. The concurrency lease is acquired in the same atomic admission operation, so two requests cannot both assume they own the same last slice of capacity.
If the estimate does not fit in the included windows, Codius can use wallet credit only when the organization has explicitly enabled extra usage and has available balance. Otherwise, admission returns a structured result such as an exhausted included window, a request that is too large for the current limits, or insufficient extra usage.
Settlement corrects the estimate
The estimate protects the system before the provider responds. It should not become a permanent overcharge.
When the request finishes, settlement releases the reservation and records the actual adjusted usage. If actual usage is below the estimate, the unused part becomes available again. If actual usage is higher, the service can account for additional included capacity still available in the same windows or charge eligible wallet usage according to the published wallet multiplier.
This two-phase path matters for coding agents because request shape is hard to predict. A tool call can return a large file. A reasoning model can stop early. A retry can fail before the provider accepts it. The system needs a safe admission estimate and an accurate final settlement, not a guess that is treated as truth forever.
The accounting also preserves the quality of the final cost signal: exact provider cost, calculated cost from actual token metadata, or an estimate when the request succeeded without enough data to calculate a better value. That gives us a way to be conservative without confusing a reservation with the final usage record.
What this means for a team
Usage is organization-scoped. A Pro organization with five members shares the Pro allowance across its members and active organization keys; it does not receive five separate monthly buckets just because five people can belong to the plan. The same shared model applies when requests come from the Codius App, a compatible agent, or the OpenAI-compatible API exposed by the Coding Plans.
That is useful for the way teams actually work. One developer may have a quiet week while another is running a large migration. A pooled allowance lets the organization use its capacity where the work is instead of forcing each seat to hit an artificial individual ceiling.
The free, open-source Codius App does not require a Coding Plan when you bring your own provider. Pro and Max are for organizations that want hosted Codius model access, with usage controls that follow the same organization and permission model. You can inspect the current plan catalog on the pricing page, connect supported agents through integrations, or use the Codius CLI when a terminal-first workflow fits the job.
What cost-normalized does not mean
I want to be precise about the promise.
Cost-normalized usage does not mean that every model will produce the same number of tokens for the same task. It does not guarantee that a $20 plan will complete any particular number of issues. It does not erase provider pricing differences, context length, reasoning, caching, or output volume.
It means that those differences are part of the accounting model instead of being hidden behind one raw token counter. You can choose a model for its behavior, tool support, context window, or reasoning ability and understand that the request will consume units according to its measured cost profile.
The allowance is also not an invitation to ignore limits. The five-hour, weekly, and monthly windows are intentionally visible because predictable boundaries are part of a usable plan. Optional wallet spending and auto-reload are separate controls, and extra usage remains opt-in.
Why I chose this design
The point of a Coding Plan is to remove infrastructure friction, not replace it with billing anxiety. Developers should be able to move between a fast model and a reasoning model without doing accounting in their heads. Teams should be able to share capacity without splitting it into seats that do not reflect their work. And when a request is blocked, the system should explain which boundary was reached.
That is why the implementation keeps the policy small and explicit: provider cost components, a model multiplier, three enforced windows, organization-scoped reservations, and a settlement path that corrects estimates. The rules are in the repository, the launch values are locked in the billing catalog, and the active account can see its current windows and reset times.
If you want to use your own provider, download Codius and run the open-source App. If you want hosted model access across Codius and compatible agents, start with the current Coding Plans and pricing details. For the security model behind organization access, API keys, and data handling, read the security page.