POST /v1/explain
{"text": "can this retry double-charge the customer?", "critical": true}
{
"concept": "moneypath.verify",
"confidence": 1.0,
"classifier_rung": "embedding",
"classify_ms": 4,
"authored_candidates": ["infra-large", "vendor-frontier"],
"eliminated": {"vendor-frontier": "residency"},
"chain": ["infra-large"],
"chosen": "infra-large",
"refused": null
}
No model was called. No tokens were spent. The router classified the request, filtered the pool, ranked the survivors and stopped at the point where it would have dispatched.
The structural reason it is possible
Routing is a pure function of the request and four config artifacts. Everything in that response is decided before anything leaves the process, so there is a natural seam between deciding and doing.
Router.plan() produces a RoutePlan — concept, policy row, selection,
classification. /v1/chat/completions takes the plan and executes it.
/v1/explain returns it.
That is one function boundary, not a parallel implementation. The explanation cannot drift from the behaviour because it is the behaviour, up to the point where a socket would open. Which is worth stating plainly: the failure mode of most "explain" features is that they are a second code path describing what the first one is believed to do.
The four things it turned out to be
A debugging tool. fiferouter explain "<text>" answers "why did my request go
there" without spending anything, and answers it in terms of the concept and the
eliminations rather than a score.
A demo. The argument for routing by concept is hard to make in prose and obvious in one response — watch the frontier model get eliminated on residency for a money-path request. That is the product, and anyone can run it against production without an account.
A monitor. The uptime workflow asserts on it every fifteen minutes:
assert concept == "moneypath.verify"
assert "vendor-frontier" in d["eliminated"]
Not "is the service up" but "does the routing decision still hold". A config edit that quietly stopped the residency pin binding would turn that red, and nothing else in the monitoring would notice — the site would be up and every container healthy.
A deploy check. apply-env calls it after every credential push, because it
proves the router is deciding without spending anything on proving it.
The economics are the point
None of those four uses would exist if explaining cost a model call. A monitor that runs every fifteen minutes and calls a provider is a monitor with a monthly bill; a demo that spends money is one you rate-limit and eventually hide behind a signup.
Because explanation is free, it can be public, unauthenticated, and run constantly. The playground on the site calls it, which is why the site runs with no provider keys at all — the whole public surface exercises the interesting half of the product without touching the expensive half.
What it does not tell you
Whether the answer would have been any good. /v1/explain says which model
would have been asked and why, not whether that model would have got it right.
It is a routing explanation, and the routing is the part we are claiming to have
opinions about.
It also stops at the plan, so it will not tell you that the chosen model is currently timing out. That belongs to the decision log, which records what actually happened, including the attempts that did not work.