all routes nominal · api v1 · schema runbook/v3
You point your software at GhostRouter instead of directly at an AI provider — usually one line of config — and we take over the question of which model answers each request. Cheap work goes to cheap models. Hard work goes to expensive ones. The difference between those two facts is your bill.
Nothing about your product changes. The same calls go out, the same answers come back, in the same shape, on the same code path. What changes is that a policy now stands between the request and the invoice, and that policy is written for your traffic rather than assumed from a dropdown.
Typical clients cut model spend 40–60% in the first billing period. The ones who save the most are usually the ones who were sending everything to a frontier model because it was the safest default — which it is, right up until you look at the statement.
WHAT THE ENGAGEMENT INCLUDES
Everything above happens because of three small things the router does to every single call, in the order below, before your software ever notices.
Classification produces a score, the runbook maps the score to a tier, and the tier resolves to a live target chosen on health and observed p50 — not on a preference list someone wrote in March. A request that needs 400 output tokens of structured extraction does not get a frontier model because a config file forgot to say otherwise.
Output is verified against the shape the caller asked for — schema, then an optional judge pass at the same tier. Failures retry in place until escalate_after, then the request climbs one rung. It never leaps to the top, and it never silently returns something wrong because the cheap path was cheap.
Every tier holds targets from more than one provider, and every route carries a fallback chain that is exercised continuously rather than discovered during an incident. When a provider degrades, traffic shifts mid-flight and the event lands in the audit log with the policy clause that authorised it.
180µs · median policy evaluation no network hop of its own · evaluated in the router process
The router does not assume the cheapest tier is correct. It assumes the cheapest tier is worth trying, and then it checks. Verification is part of the route, not a thing you bolt on later.
Two attempts is a number in a runbook, not a hard-coded constant. Set it to 1 for anything customer-facing, 3 for bulk transforms nobody is waiting on. The ladder is yours to tune.
The bill records two small attempts and one mid attempt. It does not record a frontier call, because none happened. This is the entire economic argument, and it is boring on purpose.
Roughly 7% of traffic climbs past MID in a mature policy. The other 93% never touches a frontier model at all — and never did need to. Paying frontier prices for everything is not a strategy. It is the default you were living with.
accrued: 1 × small
Most routing products give you a settings page. Someone changes a value on a Tuesday, spend moves 14%, and there is no artefact anywhere that says who, when or why. That is not a policy. That is a rumour with a save button.
GhostRouter runbooks are files. They live in your repository, they go through your review process, they are versioned with your application, and they are executed — not interpreted as hints. A routing change is a pull request with an approver's name on it.
Every clause below is evaluated on every request, in the router process, with no network call of its own. Median evaluation time is 180µs.
This is not a video. The classifier below is the same shape as the one in production — eight scored dimensions, a policy that maps score to tier, a fallback chain that exists before it is needed. Different tasks genuinely produce different tiers. Try to make it escalate.
No request leaves your browser. The classifier, the weights and the policy are all in the page — open the source and read them. In production the same evaluation happens in the router process, next to your traffic, with no network hop of its own.
Send us the shape of your traffic and we will tell you what a policy for it looks like, what it would save, and how long onboarding takes. Most first calls are half an hour.