Models
Enso routes, Kai decides, Zen reasons, Policy governs — the model families, what each is for, and the live catalogue with every id you can pass.
After this page you know which family answers which kind of question, which ones you can download, and which ids the gateway serves right now.
Four roles
| Family | Role | Weights | Reach it at | Status |
|---|---|---|---|---|
| Enso | routes and orchestrates: picks the model, context and tools per request | router code open (hanzoai/engine); family SKUs hosted | model: "auto" and enso-* ids | shipped |
| Kai | decides: typed, calibrated answers to bounded questions | hosted, not published; served by API only | model: "kai" on POST /v1/decisions | live: kai-1, $0.021 per million input tokens |
| Zen | reasons: agentic coding that runs locally, marketing copy and assets; also vision, speech, embeddings | open, on Hugging Face | zen* ids on /v1/chat/completions | shipped |
| Policy | governs: deterministic allow / ask / deny | — | your rules, in every Decision Program | a part of Hanzo Decision, not a model |
The split is by the shape of the answer. An open question — write, explain, plan — needs generation, so it goes to Zen. A bounded one — which model, which tool, is this done, allow or deny — has a known answer space, so it goes to Kai, which answers it without generating text. Enso sits in front and sends each operation to the one that should answer it. Policy has the last word on any action, and a model can make a verdict stricter, never looser.
Other lines
| Name | What it is | Status |
|---|---|---|
| Zen 7 | the next Zen generation; succeeds Satori | research preview — no weights, no id to call · Request access |
| Satori | a video-generation line, never trained | retiring; replaced by Zen 7 |
| Jin | a multimodal model specified in HIP-0003 | not built; no weights |
| Enso Diffusion | a sparse mixture-of-experts diffusion transformer, forked from DiT-MoE: zenlm/enso | research code, no released weights |
| Enso Browser | a Firefox-based desktop browser | not released |
The live catalogue
Every model below answers on one address with one key. Pass the id as model
and the rest of the request is the same whichever you pick. The one exception
is kai, listed with "outputs": ["decision"]: it answers typed questions on
POST /v1/decisions, not chat.
curl https://api.hanzo.ai/v1/chat/completions \
-H "Authorization: Bearer $HANZO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"<id from below>","messages":[{"role":"user","content":"Hello"}]}'The table is fetched from /v1/models in your browser when
this page loads, so it is the catalogue the gateway is serving right now rather
than a copy written down when the page was built. The same list, by family,
needs no key:
curl -s https://api.hanzo.ai/v1/models \
| jq -r '.data[] | select(.id | test("^(zen|enso)")) | "\(.id)\t\(.owned_by)\t\(.pricing.input_per_million)/\(.pricing.output_per_million)"'What a rate means
Rates are per million tokens (pricing.input_per_million, output_per_million;
pricing.prompt and completion state the same rates per token, as OpenRouter
does), input and output priced separately, and they are
the same whether you call from the CLI, an SDK, HTTP or an MCP tool — the price
is a property of the model, not of the surface you reach it through.
Pricing explains how usage becomes a bill. Credits covers what happens when the balance runs out.
Specifications
| HIP | Subject | Status |
|---|---|---|
| HIP-0511 | Model families: every line, its HIP, its API and where it runs | Living |
| HIP-0039 | Zen model architecture | Final |
| HIP-0904 | The zenlm/zen6* repositories on Hugging Face: what each holds | Final |
| HIP-0510 | Enso: learned per-request routing | Final |
| HIP-1332 | Kai: the decision model and the decision plane | Draft |
| HIP-0003 | Jin: a multimodal model that was not built | Draft |