Paste the usage rows you already have, choose whether this is a chargeback or a showback, and get the table finance will accept: per team totals, share of spend, the trend against last period, and a Markdown version formatted for the email you are about to send. Everything is computed in this tab and nothing is uploaded.
Usage rows name teams and often name people. They are parsed in memory here: the script has no network call, and the CSV and the clipboard Markdown are both generated in the page.
Header row plus one row per line item. A team column is best; failing that it will allocate by user or email.
Only used when the rows carry tokens and no money. Tokens have no price until you supply one, so the tool asks rather than guessing a rate.
Paste usage rows above or load the sample. The report is built here in the page and stays here.
Prepaid subscription capacity and metered API spend do not add up. If both are in this file, keep them in separate reports: one blended figure is true and useless, because it cannot tell you which half is at risk.
Nothing was uploaded. The parse, the arithmetic, the CSV and the Markdown all happen in this tab.
Both are legitimate. The sequencing is what people get wrong, and getting it wrong costs a quarter. Full detail in AI cost allocation.
The FinOps Foundation draws the line cleanly: chargeback sends the expense to a product or department profit and loss statement, while showback shows the same charges and keeps them on a central budget. The distinction is about where the money sits, not about how detailed the report is.
The row that actually decides which one you should be running is the prerequisite. Showback needs an allocation everyone believes. Chargeback needs something stronger: a lever the receiving team can pull. If the model is chosen centrally, the seat price is fixed, and the team has no way to move the number you are billing them, chargeback produces a quarter of arguments about the number and no change in behaviour. The team is right to argue, and you have spent the credibility you needed for the next allocation.
Early attribution is imperfect and everyone can tell. A shared key, a gateway that fronts several teams, a batch job nobody claimed: each of those puts a wobble in the numbers that a showback survives and a chargeback does not, because nobody disputes a report they are not being invoiced from. Run it for a quarter, let people find the errors, fix them, and move the workloads that have a real lever onto chargeback one at a time. Mature programs typically run both in parallel for different workloads rather than migrating wholesale from one to the other.
Every real allocation has a residue: the shared key, the platform gateway, the evaluation harness that runs nightly. Three defensible answers, which is why the tool above offers exactly three modes. Leave it central and show it as its own line, which is honest and puts the cost of poor attribution somewhere visible. Spread it in proportion to measured share, which assumes heavier users drive more of the shared cost, often true and worth stating out loud. Split it evenly, which is right only when every team benefits equally and is otherwise a tax on the small teams. Move the slider and watch how much the choice moves each team's number; if it moves a lot, the answer is to shrink the pool rather than to argue about how to divide it.
A subscription seat is capacity you have already bought, where one more turn costs nothing and unused capacity is waste rather than a refund. An API key is a meter, where every token is charged and a single unattended run moves the monthly number. Adding $2,000 of seats to $340 of metered spend gives you $2,340 of AI cost, which is true and useless, because it cannot tell you which half is at risk. Keep the two columns apart all the way to the report, and if you only have room for one number, send the metered one, because it is the half that can surprise you.
Five ways an allocation stops being believed. The first one has no fix after the fact, which is why it is first.
| Trap | What it looks like | The fix |
|---|---|---|
| A shared key | One large unattributable line that grows every month | One key per project, minted at project start. Keys are free and no tool can split this retrospectively. See the guide. |
| Automation on a person's seat | One engineer with implausible spend and a very regular pattern | Give CI and cron their own scoped keys. A seat is priced monthly for a human; automation runs in bursts and destroys the attribution. |
| Per seat plans read as allocation | Every team costs exactly headcount times the seat price | That is cost distribution, not cost allocation. A seat price hides usage skew by design, which is what it is for. |
| Estimates reconciled to the cent | A pipeline distrusted because it misses the invoice by 3% | Vendor per user cost figures are labelled estimates by the vendors. Use them for allocation, not for reconciliation. |
| Real-time expectations | A dashboard nobody trusts because it lags | Usage data appears within minutes; per user analytics deliberately withholds the most recent hour for stable pagination. Fine monthly, useless for live control. |
The repository dimension is the one no provider can give you, because the provider never learns what directory you were working in. It exists only in the transcript each agent CLI writes to local disk.
The four attribution keys and what each vendor exposes are in AI cost allocation.
Chargeback moves the expense onto the receiving team's profit and loss statement. Showback presents the same allocation while the budget stays central. The FinOps Foundation defines both, and the practical rule is to run showback until the receiving team has a lever it can actually pull. Charging a team for spend it cannot influence, because the model choice is set centrally or the seat price is fixed, produces a quarter of arguments about the number instead of any change to it.
One column to allocate on and one number. The allocation column is any of team, group, department, squad, business unit or cost centre, and if none of those exist it falls back to a per person column such as user, member or email. The number is any of spend, cost, amount or usd; a column ending in cents is divided by 100, which is how Anthropic reports estimated cost; and a tokens column allocates a pool you enter rather than inventing a rate. A period1 and period2 pair switches on the trend column, with period2 being the money allocated.
Decide first whether allocating them helps anyone. Direct chargeback leaves the shared pool central as its own line, which is the honest default when the pool is a shared key or a gateway nobody controls. Proportional showback spreads it in proportion to measured share, which is defensible when heavier users genuinely drive more of the shared cost. An even split is right only when every team benefits from the pool equally, which is rarer than it sounds. This tool does all three so you can see how much the choice moves each team's number.
Because the key is the tag. A token carries no metadata you chose, so the provider records the credential and nothing else, and spend that arrived under one shared organization key is a single number no downstream tool can split apart afterwards. There is no retrospective fix. Mint one key per project before you need the data, give automation and CI their own keys so a runaway job is distinguishable from a busy engineer, and the allocation stops being an estimate.
"The payments migration cost $1,400 in agent tokens" starts the right one. That dimension is not available from any provider, because the provider never learns what directory you were in. Continuum reads the JSONL each agent CLI already writes, canonicalizes every working directory back to a repository through worktrees and nested checkouts, prices each event at its own model's rate, and rolls it up per repo with a per provider split inside each one.
nothing uploaded · no signup · free