What the plans grant, and what is still unconfirmed
Anthropic's plan page now lists a monthly API allowance on some subscriptions. Max 5x shows $100 a month and Max 20x shows $200 a month, both described as money to build on the Claude Platform. Team shows up to $500 a month, pooled. Pro and the Enterprise tiers show no such line.1 The same page keeps a separate row for extra chat usage, which is a different thing from an API allowance. Keep those two apart in your records.
Two gaps matter before you build a budget around this. First, the plan page does not say which Console organization, workspace or key the allowance applies to, whether unused amounts roll over, or when it expires. Anthropic's docs navigation links a dedicated page for API allowances for subscribers, which I did not read, so those terms are unconfirmed here. Second, OpenAI's pricing pages returned an access error when I tried to read them, so I cannot confirm that ChatGPT Pro or Business plans grant API allowances or on what terms. If you have been told they do, get the terms in writing from OpenAI and apply the same method below.
Everything that follows holds whichever vendor grants the money. What changes is only the terms you plug in.
Why a grant is not a rate
A BYOK setup works because cost has one clean formula: usage multiplied by the rate your own provider charges you. Your gateway's per-request estimate uses your negotiated rate when you have entered one, otherwise the vendor's list rate.2 Providers invoice you directly, and INFRO takes 0% of model spend.3
A plan allowance breaks that formula in three ways.
- It is a fixed amount, not a ratio. A negotiated rate is a steady fraction of list. A $200 grant covers 100% of the first $200 of usage and 0% after that.
- It is per period. It resets monthly, so the effective price of a token depends on the day of the month the request is made.
- It is tied to a subscription, not to a contract. It may follow a person or a plan seat, and it can disappear when someone changes plan.
So never encode it as a price. If you enter a rate that makes the estimate match the invoice in a month where the grant was fully used, the same rate will understate the real cost in the next month's tail, and overstate it when the grant is not touched. Keep estimates gross and put the grant in the ledger.
Which keys and projects the grant touches
Finance needs one answer before anything else: which spend can the grant absorb? The usual candidates are the Console organization attached to the plan, a workspace within it, or every key in the account. Find out which, then write it down per key.
Anthropic's Usage and Cost Analytics API is the tool for checking. It reports token usage and cost in USD and can group by model, workspace, API key, service tier, and the user or service account behind a request. It launched in beta on 29 October 2026, and the older Usage and Cost API is now marked legacy but still supported.45 It needs an Admin API credential, and the Admin API is unavailable for individual accounts.5 That has a practical consequence: if a grant lands on an individual Max account's usage, you may have no admin-level report to read it back from, and that spend sits outside any reconciliation you run.
Map each key into one of three classes and tag it in your cost tool:
- Grant-eligible: keys in the organization or workspace that the grant is confirmed to cover.
- Invoiced only: production keys on a separate organization or contract, where the grant never applies.
- Unknown: personal keys and Claude Code sign-ins on individual plans, treated as invoiced until proven otherwise.
Production traffic belongs in class 2 on purpose. A monthly allowance that ends partway through a billing cycle is a poor thing to hang a customer-facing feature on, and it makes unit economics unstable.
A ledger that keeps both numbers
Give each month a small ledger with a gross line, a grant line and a net line. The estimate you compute per request feeds only the first.
| Ledger line | Source | Changes when |
|---|---|---|
| Gross estimated spend | Per-request estimates at your rate or list rate | Traffic, model mix, rate edits |
| Provider-reported cost | The provider's own cost API, per UTC day | The provider restates or applies the grant |
| Plan grant applied | Plan terms, read back from the provider's report | Monthly reset, plan change |
| Net invoiced spend | Provider invoice | Matches reported cost less the grant |
Whether the provider's cost report already nets the grant is something I could not confirm from the pages read. Test it: pick a day where you know the usage on a grant-eligible key, compare the reported cost with usage multiplied by list rate, and note the direction of any gap. If reported cost equals gross, the grant shows up only on the invoice and you subtract it in the ledger. If reported cost is already net, you add it back to compare against your estimate.
# Illustrative: allocate a monthly grant across days, oldest spend first.
def net_by_day(gross_by_day: dict[str, float], grant: float) -> dict[str, float]:
remaining = grant
net = {}
for day in sorted(gross_by_day):
absorbed = min(remaining, gross_by_day[day])
remaining -= absorbed
net[day] = round(gross_by_day[day] - absorbed, 2)
return netThis is a finance view only. Do not feed the net numbers back into the estimator.
How the grant skews estimates and budgets
Four failure modes recur.
The step. Daily reported cost jumps when the grant is exhausted. Anomaly detection and forecasts read that as a spike. Annotate the date on the ledger and exclude grant-covered days from any trend you extrapolate.
The false rate. Someone notices the invoice is lower than the estimate and enters a lower rate. Estimates for every later request are now wrong, and budgets that check estimated spend before a call will let more through than intended. A rate is a ratio; refuse to model a lump sum as one.
The lowered cap. Teams sometimes set a budget at invoice level, net of the grant. Then the cap does not move at the moment the grant runs out, and developers hit a wall mid-month with no change on their side. Keep caps on gross spend; let finance reduce the forecast of cash outlay separately.
The orphan key. An engineer on a Max plan uses a personal key, and the cost lands on a plan account outside your gateway. Reported cost for that account exceeds what you sent through the gateway. That is the same signature as traffic that bypasses your control plane, and the guide on detecting provider usage that bypassed your gateway covers how to find those keys.
Reconciling against what the provider reports
Daily reconciliation compares your estimated cost with the cost the provider reports for the same UTC day, and names the likely cause of a persistent gap. INFRO's reconciliation reads Anthropic's cost report and OpenAI's costs endpoint with a separate admin credential, and its causes include a steady negotiated rate, a rate that changed on a specific day, premiums it does not model per request, and traffic that bypasses the gateway.2
A grant will show up in that list as one of those causes, and the suggested fix will be wrong. A gap that looks like a steady fraction produces a suggested rate; do not apply it when the real cause is a fixed monthly amount. Check the pattern first. A negotiated rate produces a similar ratio every day. A grant produces a ratio that is large early in the month and returns to zero after the grant is spent. If you see the second shape, annotate it as a grant and leave your rate table alone. For the general method, see reconciling estimated spend with provider invoices and why estimates drift from list price.
Where INFRO helps
INFRO records an estimated cost per request, queryable by project and key, groups it by project, key, model or end-user id, and exports usage and a FOCUS dataset so the gross line lands in your FinOps tool beside other cloud cost. Budgets cap estimated spend per organization, project, member and key, so they stay gross by construction. Custom rates take your contract rates, and a committed-spend agreement can be tracked separately from a plan grant. INFRO does not model a plan grant; that stays a ledger line you maintain. See the reconciliation docs (opens in a new tab) and the docs overview (opens in a new tab) for details.7
Checklist before you budget around a grant
- Read the vendor's own terms for the grant: eligible organization or workspace, expiry, rollover, and what happens on plan change.
- Confirm whether the provider's cost report is gross or net of the grant, using one known-usage day.
- Tag every key as grant-eligible, invoiced only, or unknown.
- Keep production keys outside grant-eligible workspaces.
- Keep estimates and budget caps gross; book the grant as a contra line.
- Never enter the grant as a negotiated rate.
- Annotate the day the grant runs out so alerts and forecasts do not read it as a spike.
- Review monthly, because the plan page says prices and plans can change at the vendor's discretion.1