Platform · Chargeback and quotas
Somebody's name on every dollar.
Showback tells you what happened. Quotas decide what is allowed to happen. Tokenomix does both from the same request rows, so the report and the limit can never disagree.
01 — Attribution
The invoice, broken apart.
Attribution comes from the validated API key, not from a header the caller filled in. That distinction is the whole thing. A header can say anything; a key resolves to a person, their department and the application it was minted for.
So the breakdown holds up under scrutiny. When a department head disputes their number, you can show them the individual calls behind it, with timestamps and token counts, rather than arguing about methodology.
- By department
- The number finance wants. Every call rolls up to the department that owns the key, with input and output tokens priced separately because they are not the same cost.
- By user
- Who is spending, and how much of it is being blocked. A user generating a lot of refused requests is usually a workflow problem rather than a security one.
- By application
- One API key is one application. Spend broken down per key tells you which internal tool got expensive, which is the question nobody could answer before.
- By model and provider
- Where the money goes across vendors, and what a model swap would save. Useful evidence when you are deciding whether to bring something in-house.
- CSV export
- The whole breakdown downloads as a file. Finance takes it into a spreadsheet, and nobody has to build a report against your database.
02 — Enforcement
A budget that can actually stop something.
Most AI spend tooling reports after the fact, which is a receipt rather than a control. These are limits the proxy enforces at the moment of the call.
- What you can limit
- Input tokens, output tokens, total tokens, request count and dollars. Optionally narrowed to one endpoint, such as embeddings, or to a model tier.
- Who you can limit
- A department, a user, a single API key or a provider. Limits at different levels all apply, and the most restrictive one wins.
- Over what window
- Minute, hour, day or month, aligned to the calendar. A monthly budget resets on the first, not thirty days after whenever you created it.
- Warn, then block
- Every quota is set to warn or block independently. Roll a limit out in warn mode, watch who it would have stopped, then flip it once you are confident.
- When a limit is hit
- A blocking quota returns 429 with the limit, the current usage and a Retry-After header, so a well-written client backs off instead of hammering.
- Across replicas
- Counters are shared by every instance, so a restart does not hand anyone a fresh budget and two instances can never disagree about how much of a limit is left.
03 — In the console
Spend and limits, side by side.
04 — Questions
Where the edges are.
How exact are the cost limits?
Request counts are exact. Token and dollar totals are not knowable until the provider has answered, so the request that crosses your limit completes and the next one is refused. On a monthly budget the overshoot is one request. If you need a ceiling exact to the cent, no proxy architecture can give you one.
Does turning screening off also turn off the quotas?
No. The security toggle governs detection, not spend. Quotas are enforced regardless, and they are checked before screening runs, so an over-budget request is refused without costing any GPU time.
Can a department raise its own limit?
It can only lower it. The engine takes the most restrictive quota across every level that applies, so a department admin can tighten a central limit for their own team and has no mechanism to loosen one.
Where do the cost figures come from?
Token counts reported by the provider, multiplied by per-model rates you configure, with input and output priced separately. It is an estimate in the same sense your provider dashboard is one, and it matches it closely.