Agents Priced in Credits

Step 1Three things a vendor can mean by "credit", and only one of them is a price.

The word is doing very different work in different products. Sort any credit-metered offer into one of these before you try to budget against it.

• A pegged credit is a currency unit with a different name. One credit equals a stated amount of money, the vendor publishes per-model rates in credits, and the arithmetic is the same arithmetic you already do for tokens. The credit exists for packaging — it lets the vendor bundle an allowance into a seat and sell top-ups — and it adds no forecasting risk.
• A metered credit is denominated in something you can count: tokens, requests, minutes of audio, pages parsed. You can convert it to work if, and only if, the conversion table is published and versioned. Without a version, the table is a snapshot of today.
• An opaque credit is denominated in nothing you can observe. The vendor says a task costs "some credits", the amount depends on routing and effort decisions made inside the product, and the only way to learn the rate is to spend and watch the balance fall. This is the common case in seat-priced agent products, and it is the one this page is about.

The distinction matters because a budget has two terms, and a credit with no peg hides one of them. Spend is price times quantity. On a token bill you negotiate the price and you control the quantity, which is what makes forecasting agent spend tractable at all. On an opaque credit bill the vendor sets the price of the allowance and decides how much of it each task consumes. Nothing in the rate card has to move for your effective cost per task to double.

Step 2The two live examples, stated precisely.

Both of these shipped in 2026, and they are useful because they moved in opposite directions from roughly the same starting point.

Notion, 19 October 2026. Per the company's own announcement and help centre, Business and Enterprise seats each receive 1,500 Standard credits for work where Notion's router picks the model, plus 500 Select credits for work where the user picks a model or runs a custom agent. Credits reset monthly, do not roll over, and cannot be pooled or transferred between members; admins can buy more. New customers moved on announcement day and existing customers on 2 November. No credit-to-token or credit-to-task rate is published. In the same release, agents gained the ability to work a single task for more than 24 hours, up from five minutes.

GitHub, 1 June 2026. Copilot retired the "premium request" as a billing unit and replaced it with GitHub AI Credits, where one credit is one US cent and usage is metered by input, output and cached tokens at each model's published rate. Subscribers on annual Pro and Pro+ terms stay on the old request-based meter until their plan expires, which leaves the legacy multipliers — code review billed at 13 requests, for instance — running alongside the new system.

Read those two paragraphs as one finding. GitHub's old premium request was an opaque credit with a multiplier table bolted on, and the direction of travel was toward a peg. Notion's new credit is opaque by construction, and the direction of travel is away from one. There is no industry convergence to wait for here; you have to ask each vendor which kind you are buying.

Step 3An automatic router makes the vendor the counterparty on both terms.

The feature that sells a credit system is usually the same feature that makes it unforecastable. Notion's pitch for Auto is that it produced results comparable to Opus 5.5 and Astra at about 90% lower average cost across more than 20 common use cases — a figure the company's help centre states as 87% lower than Opus 5.5. Both numbers are the vendor's own testing, and the gap between them is instructive: if the supplier's two public statements of its own saving differ by three points, your reconstruction of it from a falling credit balance is not going to be tighter.

Routing is a good idea and this is not an argument against it — model routing is how most of the cost reduction in agent products is actually achieved. The problem is purely who holds the dial. A router that moves your median task from a small model to a large one has raised your cost per task without any price change, any announcement, or any line item. On a token bill you would see it immediately in the per-model breakdown. On a credit bill you see a balance that empties sooner, and the vendor's explanation is that your usage grew.

So the question to put to a credit-metered vendor is not "how much does a task cost?" It is: what changes the number of credits a given task consumes, and will you tell me before it changes? Three things usually can — the routing policy, the per-model credit weights, and the reasoning-effort default. All three are vendor-side. Unpinned vendor defaults is the general form of the risk.

Step 4Measure the one invariant: credits per completed task, on your own workload.

You cannot audit a rate you were never given. You can measure your own consumption, and that measurement is both the forecasting input and the evidence you take into a renewal. Run it per task type, because the blended figure hides exactly the task you are about to scale.

# Measure on YOUR traffic. The vendor's unit is the only thing you
# cannot define, so define everything else: the task, and "done".

# 1. Read the balance, run N real tasks of ONE type, read it again.
before = admin_api.credit_balance(pool="standard")
results = [run_task(t) for t in sample_of(task_type, n=50)]
after  = admin_api.credit_balance(pool="standard")

# 2. Divide by SUCCESSES, not attempts. A retried task spent twice.
done = [r for r in results if r.accepted_by_reviewer]
credits_per_completed_task = (before - after) / len(done)

# 3. Re-measure monthly, and after any vendor release note.
#    The series is the deliverable; a single number is not.

Three details decide whether the number is honest. Divide by completed tasks rather than attempts, or a quality regression will read as a price cut — the same discipline cost per task argues for on token bills. Keep the pools separate: a product with a routed pool and a user-choice pool has two prices, and moving work between them is a cost decision disguised as a model preference. And record the date beside every figure, because the series is what detects a silent reweighting; one sample cannot.

Now the capacity arithmetic, which is where no-rollover and no-pooling do their damage. Take a seat with a 1,500-credit monthly allowance and a measured burn of 12 credits per completed task.

One seat, 1,500 routed credits per month, no rollover, no pooling.

Measured burn    Tasks/seat/month   Team of 20, capacity
---------------  -----------------   --------------------
12 credits/task              125              2,500 tasks
20 credits/task               75              1,500 tasks   (-40%)

Same seat price. Same rate card. Nothing announced.

Pooling arithmetic, 20 seats, 1,500 each:
  pooled      30,000 credits against TEAM peak
  per-seat    20 x 1,500 against EACH SEAT's peak
  if 4 power users need 3,000 and 16 need 400:
    pooled need  = 4x3,000 + 16x400 = 18,400  (fits)
    per-seat     = 4 seats throttled at 1,500; 17,600 unused

The top half is the routing exposure: a reweighting you never see costs 40% of your throughput at an unchanged price. The bottom half is the structural one. Without pooling, an allowance sized at the team's average is wrong for everybody — your heavy users hit a wall while the balance of your light users expires unused at the end of the month. Size each seat against its peak, which usually means buying a higher tier for a small group rather than a uniform allowance for all, and treat the unused remainder as a fixed cost rather than an accident. Fixed versus variable costs is the frame; unit economics is where the resulting per-task figure belongs.

Step 5What to ask for in the contract, in priority order.

Procurement has more leverage here than engineering does, and the asks are small enough that a vendor who refuses all of them is telling you something. Take them in this order.

• A peg, or a published weight table with a version. One credit equals a stated amount of money, or one credit equals a stated amount of a countable thing per model, with a version string you can cite. This single clause converts an opaque credit into a metered one and makes everything below it unnecessary.
• Notice before a reweighting. If the credits consumed by a given operation can change, you want the change announced with a stated lead time, the same way a price change is. Absent a peg, this is the most valuable clause in the agreement.
• A usage export you can reconcile. Per-request credit consumption, with the model that served it and a timestamp, retrievable through an API. Without the model attribution you cannot distinguish "we used more" from "the router moved", and that distinction is the whole dispute.
• A capped overage price. Top-up credits bought mid-term at a rate fixed for the term. An uncapped overage converts a seat deal into usage pricing at the vendor's discretion — see pricing models for who ends up carrying the variance.
• Pooling, or a tier mix. If pooling is unavailable, negotiate the right to move seats between tiers monthly instead. That recovers some of the variance that pooling would have absorbed.
• An exit that does not need the credits. Any commitment denominated in credits is a commitment denominated in a unit the counterparty defines, so prefer a shorter term at a worse rate over a long term at a good one. Provisioned throughput and commitments covers the token-denominated version of the same trap.

One asymmetry worth naming: the vendor can see your credits-per-task and you cannot. That is not a conspiracy, it is just where the telemetry lives, and it means a renewal conversation in which you bring a measured series from step 4 is a different conversation from one in which you bring an invoice.

Step 6Where credit metering is genuinely the better deal.

The argument above is about observability, not about credits being bad. There are cases where an opaque credit is the right thing to buy, and refusing it on principle costs you money.

• When the allowance is comfortably larger than your demand. If your measured burn uses a third of the seat allowance, the exchange rate can move substantially before it reaches you, and you have bought a cap you will not hit. The risk is real but it is not yours this year. Re-measure before you grow.
• When the credit is the vendor absorbing a cost you cannot. A routed pool means the vendor eats the cost of a task that turns out expensive. That is the variance transfer pricing models describes, and on a long-tailed workload it can be worth more than the transparency you gave up.
• When you are evaluating, not deploying. During a trial, a fixed credit allowance is a hard spend ceiling that needs no engineering — which is exactly the guard rail a token bill makes you build. Free tiers and trial economics covers the trap on the other side: trial-period burn rates rarely survive production traffic.

What you should not do is run a credit-metered product as a production dependency without a measured series, because the failure is quiet. A token bill fails loudly, with a spike you can alert on. A credit bill fails as throughput: tasks start getting refused near the end of the month, the people affected are your heaviest users, and the incident arrives as a complaint about the product rather than a page about the budget. Wire the balance into the same place as your spend alerts — cost control in the loop is where it goes — and alert on burn rate against days remaining, not on the balance.