One API across every major model · a signed receipt on every request
Every model, one API, and a bill you can check yourself.
Prismux routes your requests across the frontier and open-weight models through one API that speaks both the OpenAI and Anthropic wire formats — one bill, one settlement path, and policy you set per key. The difference is what comes back with the response: a signed, hash-chained, content-free receipt for every request, so the bill is something you verify, not something you trust.
A synthetic three-record chain, really hashed with SHA-256 in your browser. Verify recomputes every hash and walks the links. Tamper changes what you were charged — then verify again and watch the chain break. Nothing is sent anywhere. The chain arithmetic is exactly what prism verify does today. A real receipt also carries an Ed25519 signature over that hash; this demo cannot show it, because your browser holds none of our keys, and prism verify --keys is what checks that half. The format is open: the Prismux Receipt Format.
00 — What you get
Every major model, one integration, and a bill you can check yourself.
Every major model, one API
Frontier and open-weight models through a single endpoint that speaks both the OpenAI and Anthropic formats. Change model without changing your code.
Every request returns a receipt
Signed, tamper-evident, and containing none of your content. Check the whole invoice yourself, offline, without asking us to confirm it.
You set the limits, per key
Where a request may be served and what may be kept afterwards. Enforced while the request is routed, not promised in a policy document.
Leave in one line
One line of configuration in, one line out. Your history exports in an open format, and we never charge you to take it.
A model on your laptop is just another endpoint
Ollama, llama.cpp, LM Studio and vLLM sit in the same catalogue as everything else, carded at zero, with the same receipt per request. The base URL has to be a numeric loopback address — even localhost is refused, because a name is resolved by the host and we will not attest to a destination we cannot check.
The official SDKs, unmodified
Change the base URL and the Anthropic Python, TypeScript and agent SDKs keep working — measured, all three, against the shipped router. A non-streaming response hands back the signed record itself in a header, so the evidence arrives with the answer rather than on request.
How we are set up, and what is actually running today: the company page.
01 — What happens to your data
We cannot read your prompts. Where that depends on someone else, we say so.
Three parties can hold your content: the model vendor, us, and you. Most gateways answer for one and let you assume the rest. Here is each, with what is actually running today.
Does the vendor keep it?
Depends on the endpoint. The floor you set is a filter that removes options, not a preference the router weighs, and that filter is built and fails closed — if nothing at or above your floor can serve the request, nothing is sent. What is not in place is the evidence behind each posture: we hold no DPA clause reference or verified org setting for any endpoint yet, so the catalogue publishes prices and their sources but no posture per row.
Enforced · evidence pendingDo we keep it?
No, and not as a policy. The receipt schema has no field that can hold a prompt: only counts, identifiers, hashes, enums and timestamps. A guard walks the schema on every change and fails the build on any unconstrained text field; a second guard walks the database columns. We see your request in memory while we proxy it — every gateway does — and no code path writes it anywhere, including the error paths where this normally leaks.
Tiered by contract · floor not yet enforcedCan you keep it yourself, completely?
That is the design, and it runs today. Started with a vault key, content is sealed at stream close and the receipt for that request reads vault: written rather than vault: off. The cryptography is AES-256-GCM under a fresh key, wrapped per holder, with a real 2-of-3 split. Today the seal is wrapped to our key alone — the KMS integration, the customer bucket and the escrow agent are the remaining holders, and the escrow and customer-held tiers open when they exist.
The part our competitors cannot say
Observability platforms give you dashboards by storing your prompts and completions somewhere they can read them. That is not a criticism of their engineering — it is the only way to build what they built.
We produce the same dashboards from counts and metadata, and the content only ever exists sealed. Same visibility. One fewer party holding your customers’ data.
The honest cost of that, stated up front: there is no server-side search over your vaulted content, and there never will be. It is not on a roadmap. Search happens in our CLI, on your machine, against the copy you decrypted. Anyone offering semantic search over “your private logs” is holding a readable copy of them.
| Tier | What we hold | Who can open it | How you know | Gating |
|---|---|---|---|---|
| open default | 30 days, encrypted under our key | us, break-glass, two-person | unseal receipt in your chain | self-serve |
| mdr | 7 days, encrypted under our key | us, break-glass, two-person | unseal receipt in your chain | verified business |
| zdr_escrow | 72 hours, sealed 2-of-3 | nobody alone — we hold one share of three | unseal receipt, and the absence of one is provable | contract + KYC |
| zdr_absolute | nothing — your bucket only | only you | there is nothing to open | contract + indemnity + commitment |
Why there is a floor at all: reselling model access carries a contractual duty to be able to investigate an abuse report. A gateway that can never see anything cannot discharge it — so we would rather tier it honestly than claim an absolute we would have to break the first time a vendor forwards us a complaint. The full mechanism, including the 2-of-3 seal.
02 — When a model is unavailable
If we have to route you elsewhere, it is the same model — and the move can never earn us more.
One model is served by several endpoints — different prices, rate limits and contractual terms behind the same name. When one is unavailable we move you to another that serves the same model, and the receipt records which one and why.
Real failover for Claude is not fall back to a lesser model. It is fall back to the same model on another substrate: zero semantic change, invisible in your output, and separately rate-limited so it actually has capacity when the first one doesn’t.
Default: on
Your price: the substrate’s real cost
Default: off — per-key opt-in
Receipt: flagged
Default: off — per-key opt-in, cost-transparent pricing only
Receipt: loud
Rung 0 is what runs for everyone. Rungs 1 and 2 now exist and are off unless your key turns them on — the tables they needed are written down, 2 rows for version adjacency and 6 for cross-vendor equivalence, each carrying the capability basis it is claimed on. A table like that is a judgement about which model is an acceptable substitute for which; we still will not make it on your behalf, so no request header can climb the ladder — only your key policy can, and only with cost-transparent pricing, so that we cannot profit from having failed you over. What is actually running.
Refuse rather than degrade
A candidate is eligible only if its capabilities are a superset of what your request demands — tools, vision, structured output, context length, cached prefix, prior reasoning state. A 200 that quietly dropped your tool definitions is worse than a 503, so you get the 503, and it names the constraint that bound.
A fallback never lowers your retention floor
Posture is part of eligibility, not a preference. If no endpoint at or above your floor can serve the request, it fails closed and your prompt never leaves our network. Opting out of that is per-key, explicit, and every instance is counted where you can see it.
We cannot profit from our own failover
A failover can never earn us more than the route you chose. Ask for a fixed price and we carry the difference ourselves, so re-routing you is worse for us than serving you as asked. Ask for cost transparency and your price moves by exactly what the substrate really costs, with our rate unchanged. You do not have to take that on trust: the receipt records the route, the price and the margin basis, and prism verify checks it offline.
Reasoning state binds the route, and nobody tells you
Extended thinking blocks are opaque, provider-specific and signed. A conversation carrying them cannot be failed over across vendors mid-conversation, and often not across substrates. Dropping that state silently gives you a subtly worse answer at full price, and you would never know.
So reasoning_state_bound is a first-class reason code here, and a request carrying prior reasoning has its candidate set narrowed before routing starts. When that constrains us into a slower endpoint, the receipt says so. Every reason code is documented.
03 — Why your bill moved
Two line items explain most bill shocks. We show you both.
Cached input and reasoning tokens are priced differently from ordinary input and output, and most dashboards fold them away. Both appear on every receipt, separately, so a month you did not expect is a number you can read rather than a mystery.
A team spending seriously on models can usually say what the total was and almost never say what drove it — which model, which workload, which agent, how much went to reasoning nobody read, how much was charged for output that was truncated or thrown away when a request failed over. That is not a reporting failure. The information was never written down at the moment it existed, and no amount of analysis recovers a number nobody recorded.
So it is recorded first, per request, in a signed record that holds none of your content: the endpoint that actually served, the five token classes counted separately, the rate card the price came from with the date it was read, and every routing attempt as its own line — including the ones that failed, with their own tokens, their own cost, and a flag saying whether you were charged for them. In the sample chain published on this site, 22 of 287 requests took more than one attempt, and 28 attempts are marked unbillable. You can count that yourself in the file.
Each attempt also carries its own timing — time to first byte and total, in microseconds, off a monotonic clock, labelled as one so nobody mistakes it for a wall-clock stamp to be compared across machines.
What does not exist yet is the tool that does the decomposition for you. The record is what makes the analysis possible; it is not the analysis. Today you get the receipts, an offline verifier, and a totalling command. Anything more than that is being built and is not on this page, because a roadmap printed as a feature is the same lie as a price with no source behind it.
One honest gap in the sample: the chain published here was generated before per-attempt latency was added, so none of its 308 attempts carry the timing block. The shipped router emits it — that is measured against the binary, not against this file.
Affinity is a routing input, weighted by money
A request whose prefix is warm on one endpoint prefers that endpoint, and cache state is tracked per substrate — so a failover to another substrate is correctly priced as a cold prefix rather than quietly billed as a warm one. The prefix is identified by a keyed fingerprint that never touches your text. We do not attempt the harder optimisation — letting a mildly degraded warm endpoint win on computed break-even — because it needs a health signal nobody has, and a tuned constant standing in for one would put a guess into your bill.
Reasoning tokens bill at output rates
They are the most common source of “why is my bill three times what I modelled”, and most dashboards fold them into output or omit them. Here reasoning is its own token class in the rate card, on the receipt, and in every chart — so a model that thinks expensively is visible before you build a product on it, not after.
The numbers we publish about ourselves
Every one of these counts a moment where something we promised did not hold, or where our own measurement disagreed with a vendor’s. A platform that only reports its successes is indistinguishable from one that is lying, so these are on the router’s own health endpoint and on our public status page, not in an internal admin panel. They are all zero today because nothing has been served — and three of them would read zero even under load, which the status page names one by one.
04 — What this costs
A margin you can read, and a count you can check.
Your price is our cost times a margin agreed in your contract. We publish no rate here because no wholesale cost is contracted yet — so instead we show you the whole calculation, and every input to it lands on a receipt you can check.
Your price is our wholesale cost times a margin. The margin is a term in your agreement, stepped by committed volume — not a number blended into a per-token rate where you cannot see it. What is not negotiable is the count: the tokens we bill are the tokens we counted in the stream, priced against a named rate card, on a receipt you can check.
No rate is published on this site. Our price is our wholesale cost times a margin, and no wholesale rate is contracted yet, so the one input it is built from does not exist. Every number we do publish carries a source and a date; a headline rate today would carry neither.
What we can show you instead: all of the arithmetic
One model, one ordinary request, every step. The list prices are real — read from the vendor's own page on the date in the catalogue. The only invented number is the margin, and it is marked.
| claude-sonnet-5 · 8,000 tokens in · 2,000 out | cold prefix | warm prefix |
|---|---|---|
| input — $2.00 / $0.20 cached, per 1M | $0.016000 | $0.001600 |
| output — $10.00 per 1M | $0.020000 | $0.020000 |
| substrate cost | $0.036000 | $0.021600 |
| × margin — illustrative 12%, yours is a term in your agreement | $0.040320 | $0.024192 |
The same request costs $0.016128 less warm than cold, and that difference is yours: the margin rate is identical in both columns. A gateway that bills a warm prefix at the cold rate keeps it, and you cannot see that it did. Ours is on the receipt — token counts, cache state, the endpoint that served it, the rate card the price came from — and prism verify checks all of it offline.
price_locked
Your per-token price does not move, however we route. On a failover we absorb the cost difference, which makes a failover strictly worse for us than the route you asked for.
cost_transparent
Margin is a fixed percentage of provider cost, so your price moves by the substrate's real difference and our margin rate does not move. For the buyer who would rather see the routing than be insulated from it.
tiered
Cost difference plus extra margin to us — the mode where a failover earns more than the route you asked for. Most gateways run it. We do not sell it.
There is no published markup ladder here: the spread is structural, not a debt paid down against volume thresholds, so there is no schedule of step-downs to read off. There is no spend calculator, because a calculator needs a contracted wholesale rate and there is not one yet. And BYOK is not a product here at all — it hands the vendor relationship to the customer, and holding those agreements ourselves is what pays for committed capacity, one settlement path and a receipt that covers the whole route. The full pricing model →
05 — Compared with the alternatives
Everyone here has a feature grid. Only one row cannot be copied.
| Aggregators and platform gateways | Observability layer on top | Prismux | |
|---|---|---|---|
| Who holds your prompts | the vendor, on their terms | the vendor and the observability provider, in plaintext | us, briefly, sealed — under a key split three ways at the escrow tier, or none at all at zdr_absolute |
| Retention guarantee | per vendor, read the DPA | inherited, plus theirs | a contracted tier over a minimum-retention floor, and a floor you set that binds the routing filter |
| Failover | same model, another vendor — or you build it | you build it | same model, another substrate: no semantic change and separately quota'd |
| Cost attribution | one dashboard per vendor | good, if you accept the retention cost | per project, key and client — cache and reasoning broken out as their own priced classes |
| Can you audit the bill | you take their word | you take two parties' word | a hash-chained receipt per request, verifiable offline |
| Leaving | change one base URL back | export, migrate, rebuild | change one base URL back |
We speak the OpenAI and Anthropic wire protocols natively, so there is no SDK to adopt and no framework to buy into. That means switching to us costs one line — and it means switching away costs one line too. We would rather compete on that basis than on a migration you can’t reverse.
06 — Questions
Including the ones we would rather you did not ask.
Can you read my prompts?
While we are proxying a request it is in our process memory. That is true of any gateway, load balancer or TLS-terminating proxy, and anyone claiming otherwise is describing something that cannot exist.
After that it depends on your tier, and we will not blur it. On open and mdr we hold an encrypted copy for a short window so an abuse report can be investigated — opening it requires two of our people and it writes an unseal receipt into your chain. On zdr_escrow we would hold one share of a 2-of-3 key, so we could not open it alone; on zdr_absolute we would hold nothing.
Those last two tiers are not on sale yet. The seal runs today — content really is encrypted at stream close and the receipt says so — but it is wrapped to our key alone, because no customer KMS, customer bucket or escrow agent is configured. So on the software as it stands we can open a sealed record: with two people and an unseal record, but as a company, alone. zdr_escrow and zdr_absolute open for sale when the other holders exist.
What never varies at any tier: the receipt log has no field that could hold a prompt, and no code path writes request content anywhere outside the sealed envelope — including the error paths, where this normally leaks.
Do you profit when you fail over?
No — a failover can never earn us more than the route you chose. Every failover lands on a receipt carrying the reason code, the endpoint, the provider cost and what you were charged, so you total it from your own chain with prism verify rather than asking us to confirm it.
Every failover lands on a receipt carrying the reason code, the endpoint, the provider cost and what you were charged, so the margin rate on either side of it is something you total from your own chain with prism verify rather than something you ask us to confirm. If you would rather your price simply never moved, price_locked does that and we absorb the difference.
What will this actually cost me?
Your price is our wholesale cost times a margin. Pre-launch we hold no contracted wholesale rate, so that input does not exist yet and any figure printed here would have nothing behind it. The margin is a term in your agreement, not a number blended into a per-token rate where you cannot see it.
There is no markup ladder and no BYOK line. The spread is structural rather than a schedule of step-downs, and the vendor agreements stay with us — which is what a single settlement path and a receipt covering the whole route are built on. The pricing model, in full.
What happens if I lose my vault key?
Your history is unrecoverable ciphertext. Permanently. That is the guarantee working exactly as specified, and we would rather you read it here than discover it later.
Mitigations that don't break the guarantee: use customer_bucket with your own cloud KMS, so your existing key-management discipline and recovery tooling apply. Or enable escrow — a second wrapped copy under a key held by a party you nominate, never us. It's off by default, and if you turn it on it appears on every receipt, because a privacy posture with a silent exception is worse than none.
What if a provider is down everywhere?
Then so are we, for that model, and we will say so on the status page in those words. Our uptime cannot exceed the union of our upstreams' for a model you have pinned.
This is why we publish two availability numbers instead of one flattering blend, and why the dashboard shows what your current policy buys you — a policy allowing rung-1 fallback has a materially higher effective availability than one pinned to a single endpoint, and you should be able to see that number before you choose.
Are you actually allowed to resell this?
A fair question, and one most gateways don't invite. Vendor terms vary on onward resale — some paths are explicitly designed for it, others require a named agreement. Our position per vendor is stated in Trust → resale standing rather than gestured at.
BYOK is not the answer here, because BYOK is not a product we sell: it would hand you the vendor relationship, and holding those agreements is the basis of this business. We hold none of them today, so there is no launched managed-billing product either.
How do I verify a receipt myself?
The receipt format and the verifier are open source under a permissive licence, and the verifier is a single static binary in a different language from our data plane, with no dependency on our infrastructure. That is deliberate: verification that requires our SDK is not verification.
prism verify works today, offline, with no network call: it recomputes every hash and walks every link, and tampering, reordering or deletion each fail the exit code. The canonical form it hashes is re-derived independently in the CLI and in the router and checked against a fixed reference, so the two agree by specification rather than by sharing a library.
Receipts are now signed too: an Ed25519 signature over each record's own hash, checked by prism verify --keys against the key the router prints at boot for you to pin. One limit, which the verifier reports the same way: the two checks are independent. An edited record still carries a valid signature over the hash it was signed with, so "signatures 4 of 4 verified" is not a claim that the records are intact — the hash comparison is what catches an edit. There is still no published key endpoint and no rotation history. Signing status.
Why isn't zero retention simply the default for everyone?
Because it would be a promise we could not keep. Vendor platform terms make the reseller responsible for downstream abuse: we must be able to investigate a report, identify the customer and act. "We are structurally unable to look" is not a defence to that, it is a disqualification — and some obligations, CSAM reporting among them, have no privacy-architecture exemption at all.
So the floor is minimum retention and zero retention is something you contract for. At zdr_escrow the duty survives without giving us unilateral access: the key is split three ways, two holders are needed to open it, and every attempt lands in your receipt chain. At zdr_absolute you take the duty on yourself, in writing, and we hold nothing.
A gateway offering unconditional zero retention on a resold endpoint has either not read the vendor terms or has not thought about what happens when an abuse report arrives.
Can you give me full request logs and zero retention at the same time?
Yes, and it's the single idea this whole product is built around. Those are two different questions about two different parties, and collapsing them is what makes them look contradictory.
We retain nothing readable. You retain everything, sealed under a key we don't have — or written straight into your own bucket, where we hold nothing at all. The only thing you give up is server-side search over that content, which is not on our roadmap and never will be, because it would require us to hold a readable copy.
How do you detect abuse without reading my prompts?
Four signals, none of which needs a readable copy of anything you sent.
Blind matching — a perceptual hash of content checked against known-bad fingerprint sets; the system learns matched: true, never what the text said, on the same principle image platforms have used for over a decade. Vendor filter signals — the model vendor's own filters still run, and a key accumulating refusals is actionable on its own. Traffic shape — request distributions, token ratios, refusal rates, concurrency curves. Payment and identity — prepaid first, spend velocity earned rather than granted, business verification above a threshold.
Metadata catches fraud and industrialised abuse well, and a low-volume, well-funded bad actor poorly. That is why a minimum-retention window sits below the zero-retention tiers, and why those tiers are contracted rather than a checkbox — at zdr_absolute the enforcement duty moves to you, in writing, because it has to live somewhere. Full policy: acceptable use.
The English text is the authoritative version of this document. Translations are provided for convenience and, in the event of any conflict, the English text governs.
Change one line. Verify the first receipt yourself.
If the numbers don’t reconcile, change it back. That’s the entire commitment.