How your price is built, and when the number arrives
We can tell you how a price is formed — the formula, the mode that governs a fallback, and the invariant that stops us profiting from our own routing. All of that is settled and written down.
The number arrives with the first wholesale contract. There is no published rate on this page because our price is our wholesale cost times a margin, and no wholesale rate is contracted yet. Every number on this site carries a source and the date we read it; a rate published today would carry neither.
What the catalogue does publish is the vendor list price we read for each endpoint, with the URL and the date. That is a cost reference, not your price, and it is labelled as one.
There is no markup ladder here and no schedule of step-downs to read off: the spread is structural rather than a debt paid down against published volume thresholds. Margin steps with committed monthly spend, and the step is a term in your agreement.
How a price is formed
Three quantities, and the site uses the same words for them the ledger does:
- Provider cost — what the served route actually cost us, computed from the tokens we counted in the stream and the rate card those counts were priced against. Five token classes, priced separately: input, output, cache read, cache write, reasoning.
- Wholesale — our contracted cost for that route. Below list where a commitment or a substrate earns it.
- Charged — wholesale times a margin, under whichever pricing mode your account is on.
Margin is a policy object rather than a constant: it varies by vendor, substrate and model class, and steps with committed monthly spend. It is a number we will state in your agreement, not one we hide inside a blended per-token rate.
A charge must clear provider_cost × (1 + min_margin). Realised
margin below that floor for enough consecutive requests on an endpoint opens a
breaker and we stop selling that endpoint. The reason this matters to a buyer:
the failure it prevents is a vendor raising a price against a rate card we have
not refreshed, which turns every sale into a silent loss and ends with a
supplier that cannot deliver. A stale card raises rate_card_stale
and stops backing new pricing for the same reason.
Both rules are computed on every settlement and both are
published: below_margin_floor and rate_card_stale are
promise counters on the router's own /health, and the rate card
carries the max_age_days the staleness rule reads. What is not
connected is the breaker: the code that would stop selling an endpoint
after N consecutive floor breaches exists and is tested, and nothing calls it, so
today a breach is counted rather than acted on. See what is actually running.
Fallback pricing modes
When we fail over to a different substrate, something has to happen to your price. There are three coherent answers, we sell two of them, and the third is the one that would give us a reason to fail over on purpose.
| Mode | Your price on failover | Our margin rate | Our incentive | |
|---|---|---|---|---|
| price_locked | does not move, ever, however we route | falls | we lose by failing over | default |
| cost_transparent | moves by the substrate's real cost difference, at cost | unchanged | neutral | opt in |
| tiered | cost difference plus additional margin to us | rises | we gain by failing over | not offered |
The third row is what most gateways do, and it is why “do you fail over on purpose?” has no good answer there. We don't sell it.
price_locked is the default, and why
Most buyers want a per-token price they can budget against, not a price that moves with our routing. So the default is the mode where the number on your invoice does not move regardless of which substrate served you, what a vendor does to its list price mid-term, or how often we fail over. A small uplift on the base rate prices that predictability.
It also satisfies the incentive question trivially: on a failover we
absorb the cost difference, so a failover is strictly worse for us than
the route you asked for. The difference is booked to
fallback_absorption and appears on the receipt as
absorbed_usd inside the charge block — one of the 43
fields the signature covers — so what the lock was worth in a given month is
something you can total from your own chain rather than ask us for.
cost_transparent, for the buyer who wants to see the routing
Margin is a fixed percentage of provider cost, so your price moves by exactly the substrate's real price difference and our margin rate does not move. Neutral rather than negative — you can see every routing decision and pay its real cost.
"We cannot profit from our own failover" is an invariant the pricing
model is built on, and under price_locked it is arithmetic
rather than policy: absorbing a delta cannot increase a margin. You do not have
to take that on trust. The receipt records the route, the provider cost, the
absorbed delta in fallback_absorption and what you were charged,
and prism verify checks it offline — so the margin rate on either
side of a failover is something you total from your own chain. It holds for
rung-0 failover, which is the only rung that runs.
Committed use
A committed agreement buys three things that are genuinely ours to give:
- A better margin step, sized to the commitment. Margin steps with committed monthly spend, and the step is a term in your agreement rather than a public schedule — a schedule needs volume history behind it, and there is none yet.
- price_locked over a longer horizon — a unit price fixed for the contract term, not just against our routing.
- Net terms. Worth naming plainly: net-30 on a $2M annual account is roughly $170k of working capital we are providing you. It is part of what a committed agreement prices, not a free courtesy.
What a commitment does not buy is a different retention posture, a weaker receipt, or an exemption from the promise counters. Those are not negotiable line items.
We will not sign a commitment larger than we can match with vendor capacity on matched terms. An unmatched commitment turns your churn into our solvency event, which is a bad structure for both of us.
What is included at every tier
Included means never a separate line item. It does not mean shipped: this is the commercial commitment, and the build status page is where you find out which of these is running today. Where the two disagree, the status page is the one telling the truth.
Retention and residency enforcement
Posture floors and region constraints as routing filters that fail closed, across every vendor, on the free tier and the seven-figure contract alike.
Encrypted export
All three vault modes, including writing straight into your own bucket. No per-gigabyte export fee — charging you to leave is a lock-in tactic.
Signed, chained provenance
Every request, including refusals. The verifier is open source and free forever.
Substrate failover
Rung-0 failover, circuit breakers, cache affinity. Not a paid add-on.
Projects, budgets, caps
Per-project and per-key hard and soft ceilings, reservation-aware. Unlimited projects and keys.
Cache and reasoning breakdown
The two line items that explain most bill shocks, on every dashboard and every receipt.
What we never charge for
- Seats. Add your whole team. Charging per seat on an infrastructure product just taxes you for having colleagues.
- Data export. Ever. In
customer_bucketmode the data is already yours and we could not charge for it if we wanted to. - Receipt verification or retention. Your receipts are part of your record, not a feature tier.
- Failed attempts that delivered nothing. If an endpoint 429s
and produces no tokens, that is our cost of routing, booked to
fallback_waste. It appears on your receipt markedbillable: false. - Support, at any tier. A billing question is not an upsell opportunity.