Wiki · Cost
How cost is determined
What counts as AI cost, where every input comes from, and why the billed number can differ from the API-equivalent number. Push on the example below — it runs the same math the platform runs. Then keep going: the second example shows the operating model we are building, where finance approves cost pools instead of assigning rows to models.
Illustrative worked example — not customer data. Change anything.
published rates / 1M tokens: in $3 · out $15 · cached read $0.3
Billing mode
12M
3M
40M
2M
API-equivalent
$100.50
tokens × published API rates
Usage-attributed actual
$100.50
pay-per-token: equals the API-equivalent
12M in × $3 + 3M out × $15 + 40M cached reads × $0.3 + 2M cache writes × $3.75 = $100.50
1 · The operating model
You approve policies. The platform does the bookkeeping.
The question every CFO asks: “So I have to figure out the cost of everything and assign it to models?” No. Today, metered API usage never crosses your desk — the collector records model, provider, token volume, billing mode, and the fingerprinted agent on every row, and prices it automatically. The pool-policy workflow shown below is the next product step, not a live product screen. It makes the intended burden reduction concrete for everything else: flat provider plans, shared infrastructure, and implementation spend enter a small number of cost pools. Each pool takes exactly one finance decision — approve a named allocation policy over measured usage, or hold the pool unallocated for review. Finance's recurring job becomes connecting source data once, one approval per pool, and exception review; model-by-model bookkeeping never enters the loop. And every dollar reconciles: automatic + policy-allocated + unallocated equals the source invoice total, where unallocated is a valid, visible state — never a forced model assignment to reach 100%.
Illustrative worked example — not customer data. Change anything.
$8,300
captured & attributed automatically by the collector
24
attribution is automatic — this number only drives the old-way column
$3,000
by measured usage share: Support triage 55% → $1,650 · Contract drafting 30% → $900 · Research 15% → $450
$2,400
held unallocated — queued for finance review
Captured automatically
$8,300
metered usage, attributed by the collector — shipped today · 0 decisions
Policy-allocated
$3,000
one approved policy per pool — next product step
Unallocated — held for review
$2,400
a valid, visible state — never forced to a model
$8,300 automatic + $3,000 policy-allocated + $2,400 unallocated = $13,700 — matches the source invoices exactly
The old way: 3 invoices × 24 models = 72 hand assignments, every month
With Oabo: 2 pool decisions + exception review — no matter how many models
Shipped today: automatic capture and dual-lens pricing of metered usage — the calculator above runs it. The pool policies and exception queue are the next product step, shown as the intended operating model — not a live product screen.
2 · Inputs
Where every input comes from
Token counts are measured, not estimated: the collector reads your agents' session logs in place — counts and metadata only, never content — and each record names its model, provider, and billing mode at ingest. The billing mode is one of exactly three values (api, subscription, local); an unrecognized mode is rejected at the boundary, not coerced. Prices come from the platform's bundled table of published API rates. Provider invoices arrive separately as spend records over the same fingerprint channel the agent registered through, and every row carries its provenance: measured (system-observed), declared (a person entered it), or synthetic (illustrative demo data, retired the moment real data arrives).
3 · Two lenses
Usage-attributed actual vs API-equivalent
Every usage row is priced twice. Usage-attributed actual is the cash assigned to that metered row. API-equivalent is the comparable: the same tokens priced at published per-token rates. On pay-per-token API billing the two agree. On a flat subscription plan the marginal cash cost of the next token is $0, so the usage row carries $0 while the equivalent keeps showing what the work would cost at list. That does not make the subscription free: total AI cost includes the separate plan invoice, implementation spend, and any other cash recorded outside token usage. On local hardware there is no per-token invoice; the equivalent remains a workload comparator while infrastructure cash stays in the GL.
usage_actual = cash assigned to metered usage · api_equivalent = tokens × published rates · total_cost also includes separate plan, infrastructure, and implementation spend
4 · Unknown prices
Gaps are shown, never guessed
When a model has no entry in the published rate table, its rows are recorded unpriced — the API-equivalent is stored as an explicit gap, never a guessed rate, and monthly totals skip the gap rather than letting one unpriced row erase an agent's whole figure. The gap stays visible until the rate table learns the model. This is deliberate: a spend figure that silently includes invented rates cannot be defended, and this ledger would rather show you a hole than hand you a number it cannot source.
5 · Conventions
The details that keep the arithmetic honest
Money is stored as integer cents, so roll-ups never accumulate float drift. Ingestion is idempotent: re-sending a day corrects the record instead of double-counting it. Cache traffic is priced the way providers price it — cached reads at the model's listed cached-read rate (or 0.1× the input rate when none is listed), cache writes at 1.25× the input rate for the 5-minute TTL and 2.0× for the 1-hour TTL, with the 1-hour subset clamped so it can never overbill. And delegated sub-agent work is counted exactly once, attributed to the model that did it.
Related: How usage becomes a number you can defend — the pipeline these inputs travel · Method — the canonical methodology · Wiki index