Introducing Enso — one API, routed to the best frontier intelligence

No single frontier model leads every benchmark. On the same public tables, one model wins hard software engineering, another wins competitive coding, another wins graduate-level reasoning, and a fourth wins the million-token long-context work. They trade the lead back and forth, column by column. A monolithic deployment picks one of them and quietly eats its losses on every column it does not lead.

Enso is Hanzo's answer: stop shipping a model, ship a policy over models. Enso routes each request to the model most likely to serve it best, across any provider you enable and any model you host — and it gets better as you use it. You send messages to one /v1 endpoint and get an answer. You never pick a provider, and you never hold a third-party key.

Routing is effectively free

The decision Enso makes on every request is a keyword classification plus a small learned matrix–vector product. We measured it: ~300 nanoseconds for the rule router, ~12 microseconds for the learned policy — the actual learned decision (xᵀWp) is 229 nanoseconds. That is six orders of magnitude below the model call it precedes. You never need a GPU to route — only the model Enso picks needs one. Training the router is CPU work too (a closed-form fit plus an online update), which means an org can train its own router on ordinary hardware.

The family: two ways to use it

• enso — the learned router. It featurizes each request, scores every model in the pool by a learned utility, and returns the single model that maximizes quality under your cost and latency budget.
• enso-ultra — the ceiling. It reuses the same policy to select the top N models, runs them in parallel, and fuses their answers with a training-free synthesizer. You spend more compute to buy the upper envelope of the whole pool on your hardest requests.

Both are one product: one identity (whichever model serves you, the answer comes back as Enso, with provenance — never a leaked upstream), one meter (every request is priced to the model that actually served it), and one 1M-context ladder (long context is just another model the router reaches for when your prompt needs it).

curl https://api.hanzo.ai/v1/chat/completions \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -d '{
    "model": "auto",
    "messages": [{"role": "user", "content": "Refactor this module and explain the tradeoffs."}]
  }'

Send "model": "auto" to route across your whole pool, or "enso" / "enso-ultra" for the managed family. That is the whole API surface — and it works from any OpenAI-compatible client: your CLI, your IDE assistant, your agent harness.

How enso routes

Each model is one row in a registry — a profile carrying an eval-measured quality vector across tasks, plus latency, cost, and context reach. A request becomes a feature vector x in sub-microsecond time, and every model profile p is scored by a bilinear utility xᵀWp. The selector returns the SLO-feasible pick that maximizes:

utility(x, p)  −  λ · cost(p)  −  μ · latency(p)

Hard ceilings (max latency, max cost, min quality) gate the candidate set; the soft weights λ, μ trade cost and latency against quality. Offline, the weights W are a closed-form ridge fit over eval data; online, each user carries a bandit whose weights drift toward their taste from one observe(...) call per served request.

The property that matters for a pool that keeps changing: the policy is a function of data. Adding a new frontier model is adding a row. Its ranking falls out of the same weights, with no retrain and no code change. And there is no cold-start cliff — a transparent rule router serves from request one and the learned policy takes over per-task as eval data accrues, falling back to the rules whenever it is unsure.

It learns from your traffic

Enso improves itself from ordinary use. In-app feedback and an automatic LLM-as-judge quality score become rewards, keyed to each request. The ledger is content-free — features and a score, never your prompt text — and your policy updates online. Every org trains its own router on its own workloads; the shared base only learns from orgs that opt in. Before any new weights ship, they are gated: a candidate is promoted only if it beats the incumbent on a held-out measure, otherwise the router keeps the old weights and keeps training. A regression cannot reach production.

Every routed request also produces a labeled tuple — which model won, and how good the answer was. That is not just router training data; it is a preference dataset for training the next model. A better model becomes a better routing target, which generates more preference data, which trains the next model. The router is the data flywheel for the model.

enso-ultra: training-free fan-out

Ultra is for the requests where being wrong is expensive and the single best model is genuinely uncertain. It takes the top N of the same ranked, SLO-feasible candidate list, dispatches them in parallel, and fuses their answers with a training-free synthesizer. All learning in Enso lives at the routing layer; none at the orchestration layer — so when a new frontier model ships, Ultra includes it in fan-out the moment the router has a profile row for it, nothing to re-train.

Benchmarks: measured, or clearly pending

We evaluate on seven public benchmarks — SWE-Bench Pro, Terminal-Bench, LiveCodeBench, LiveCodeBench Pro, Humanity's Last Exam, CharXiv Reasoning, and GPQA Diamond — via our open enso-bench harness. Every Enso figure is our own executed measurement; where a run is not yet complete we mark it TKTK rather than print a number we did not measure. Arm baselines are provider-reported.

Benchmark	Best single arm (provider-reported)	Enso	Enso Ultra
LiveCodeBench	88.5	91.4	81.1
GPQA Diamond	94.3	87.9	89.9
SWE-Bench Pro	69.2	TKTK	TKTK
Terminal-Bench	78.2	TKTK	TKTK
LiveCodeBench Pro	88.4	TKTK	TKTK
HLE	49.8	TKTK	TKTK
CharXiv Reasoning	84.2	TKTK	TKTK

The headline is already visible: on LiveCodeBench, enso scores 91.4 — matching the best single arm, at roughly one-seventh the cost of routing everything to the most expensive model. That is the whole thesis in one row: best-arm quality at best-arm cost, because the router picked correctly. We read the table per benchmark, never as an aggregate that could hide a regression. Full methodology and the honest-reporting caveats are in the Enso paper.

The cost angle a monolith can't offer

A monolith charges its one price on every token, whether or not your request needed it. A router prices each answer to the model that actually served it — so cost becomes a first-class, transparent axis:

• You pay per request for the model that served it, not a blended premium. Cheap requests route to cheap models; you see it on the meter.
• Enso Ultra's fan-out is transparent — an Ultra answer carries which models contributed and at what cost.
• One meter, one bill. No stack of per-provider invoices, no per-seat assistant subscriptions, one usage plane in the console.

For teams that route their own pool, Enso Router is 1% of the LLM spend it routes — bounded above by the value it creates (routing away from over-provisioned models typically saves far more than 1%) and above what it costs to run (a microsecond CPU decision plus a sampled judge call). The fee grows only as your routed spend grows, and you keep the savings minus the fee. We win when you save.

Try it

Enso is live on the Hanzo AI gateway, and it runs the routing for Hanzo Cloud itself.

• API: api.hanzo.ai — one /v1 endpoint, "model": "auto", "enso", or "enso-ultra".
• Console: console.hanzo.ai — enable Enso Router, pick your pool, set a cost ceiling, watch the per-request meter.
• Research paper: github.com/hanzoai/papers/enso — the architecture, the routing-latency measurements, and the economics.

Send every request to the best frontier intelligence available for it — and only pay for the one that served it.