HIP-511: Model Families — Zen Generates, Enso Routes, Kai Decides. Status Living. Hanzo architectural specification.
Hanzo's models fall into families by the job each does. Zen generates: the open-weight generative family. Enso routes: the router family that picks what serves each request. Kai decides: the typed decision model. Policy governs: deterministic authority, not a model. Sekai models local world beliefs and predicts consequences (HIP-0007); its experimental world runtime is in progress. This HIP maps every family and model line to its HIP, its API and where it runs, and states the order of one request: Enso asks Kai before it asks Zen.
It is Living: amended when a model ships, moves or retires.
One name carries several things: "Enso" is a router, a SKU family, a diffusion fork and a browser fork, and the public hanzoai/kai-1 repositories hold baseline weights, not Kai. A reader who wants to call a model, run one or cite one needs one table that says what a name is, where its spec is, and whether it exists.
This HIP requires nothing; it describes. Status words: shipped (served, or downloadable, now), in progress (code exists, nothing served), upcoming (named, not built), retiring, baseline (not ours; used for comparison). Every fact is checked with:
curl -s https://api.hanzo.ai/v1/models # Hanzo Cloud: what serves
curl -s 'https://huggingface.co/api/models?author=zenlm&limit=500' # open weights (public)
curl -s 'https://huggingface.co/api/models?author=hanzoai'zenlm holds 85 repositories, 4 of them private; hanzoai holds 3.
| Family | Job | Output | HIP | API | |---|---|---|---|---| | Zen | generates | text, code, embeddings, images, audio, video | HIP-0039 | /v1/chat/completions, /v1/responses, /v1/messages, /v1/embeddings, /v1/rerank, /v1/images/, /v1/audio/, /v1/videos/ | | Enso | routes | a model per request | HIP-0510 | model=auto and the enso ids on the wire above; /v1/ai/router, /v1/ai/feedback | | Kai | decides | typed state: choice, score, predicate, defer | HIP-1332 | POST /v1/decisions | | Sekai | models and predicts | local beliefs, rollouts and candidate-plan terms | HIP-0007 | /v1/worlds; experimental profile, not a generally served cloud family | | Policy | governs | allow, ask, deny | HIP-1332 §10 | none of its own |
Open weights live under zenlm/ on Hugging Face, licence and base per model card. Hanzo Cloud serves the ids in the third column.
| Line | Open weights | Hanzo Cloud | Status | |---|---|---|---| | Zen6 | zenlm/zen6, zenlm/zen6-coder, zenlm/zen6-flash | zen6, zen6-coder | shipped; HIP-0904 | | Zen5.8 | none | zen5.8, zen5.8-coder, zen5.8-spark, zen5.8-evo | shipped, cloud only | | Zen5 | GGUF: zenlm/zen5-gguf, zen5-coder-gguf, zen5-mini-gguf, zen5-pro-gguf, zen5-max-gguf, zen5-nano-9B-gguf; zen5-flash-gguf and three zen5-nano sizes private | zen5, zen5-mini, zen5-flash, zen5-coder, zen5-pro, zen5-spark, zen5-evo | shipped | | Zen7 | none | none | upcoming; the successor to Satori; no repository, weights or spec | | Satori | none (zenlm/satori is a video-generation scaffold on Open-Sora, never trained) | none | retiring; replaced by Zen7 | | Vision-language | zenlm/zen-vl-{4b,8b,30b}-{instruct,agent}, zenlm/zen3-vl | zen-vl | shipped | | Embedding | zenlm/zen-embedding, zen-embedding-{0.6B,4B,8B}, GGUF for 0.6B and 8B | zen-embedding | shipped | | Guard | zenlm/zen-guard, zen-guard-gen, zen-guard-gen-8b, zen-guard-stream, zen-guard-stream-4b, zen3-guard | zen-guard | shipped | | Reranker | zenlm/zen-reranker, zen-reranker-{0.6B,4B,8B} and their GGUF | not listed | open weights only | | Speech | zenlm/zen3-asr, zen3-asr-0.6B, zen3-asr-aligner, zen3-tts, zen3-tts-0.6B, zen3-tts-custom-voice, zen3-tts-voice-design, zen-dub-live | not listed | open weights only | | Image | zenlm/zen3-image, zen3-image-fast, zen3-image-ssd, zen-image-edit | not listed | open weights only | | Video | zenlm/zen-director, zen-world, zen-video-i2v | not listed | open weights only | | 3D, music | zenlm/zen-3d, zen-musician | not listed | open weights only | | Earlier lines | zenlm/zen-nano*, zen-eco*, zen-omni*, zen-pro, zen-agent-4b, zen-designer*, zen3-nano, zen3-omni, zen-finance, zen-legal, zen-medical, zen-sql, zen-multilingual, zen-translate, zen-translator, zen-blog, zen-scribe, zen-family | not listed | open weights; not served |
Hanzo Cloud also lists zen-free.
| Member | HIP | API | Runs | Status | |---|---|---|---|---| | Router | HIP-0510 §1–§4 | model=auto (alias zen-router); the response header X-Routed-Model names what served | Hanzo Cloud (hanzoai/ai); the xᵀWp engine (hanzoai/engine) is built, not wired | shipped | | SKUs | HIP-0510 §5 | enso, enso-auto, enso-flash, enso-free, enso-pro, enso-ultra | Hanzo Cloud only | shipped | | Router model | HIP-0510 §8 | none | open weights (zenlm/zen-router); on no serving path | experimental | | Enso Diffusion | HIP-0510 §8 | none | code only (zenlm/enso) | research code; no weights | | Enso Browser | HIP-0510 §8 | none | none | unreleased private fork |
| Item | HIP | API | Runs | Status | |---|---|---|---|---| | Kai, one line (hanzoai/kai) | HIP-1332 | POST /v1/decisions (§17); enso.decide in process (§13) | Hanzo Cloud only (§20) | shipped: kai-1 on POST /v1/decisions on api.hanzo.ai; code private; no checkpoint published | | hanzoai/kai-1, kai-1-multilingual, kai-1-agent | HIP-1332 §18 | none | private on Hugging Face | baseline: Laya weights, byte-identical to upstream; the cards are titled Laya; not a Kai version, and not the served kai-1 | | Laya, Jev | HIP-1332 §18 | none | upstream | baseline; not ours |
| Name | HIP | Status | |---|---|---| | Jin | HIP-0003 | not built: hanzoai/jin is archived and holds a copy of LumenPallidium/jepa (MIT), not Hanzo model code; no weights | | HLLM | HIP-0002 | a specification; no model or weights exist |
HIP-1332 §13 makes Kai native to Enso. Enso splits every operation into a bounded decision or generation:
request ─▶ Enso
├─ bounded decision: model, context depth, tools, reasoning budget,
│ stop, retry, escalate
│ └─▶ Kai ─▶ typed answer ─▶ Policy (allow < ask < deny) ─▶ act
│ └─ defer ─▶ Zen
└─ generation ─▶ Zen, on the model Enso choseA Decision Program (HIP-1332 §5) is the graph form of the same split. Its nodes are deterministic, Kai, Zen, solver, simulation or human, and only the Zen nodes generate, so an agent workflow spends generative compute only where generation is the work.
The routing decision is the router's own policy (HIP-0510 §1): per-org overrides, ε = 0.1 exploration, then the prefer table that the reward-mean trainer rewrites every 15m. The xᵀWp engine is built (hanzoai/engine) but not wired (router.endpoint is empty). Kai takes a decision over one program at a time, shadow, then advisory, then enforced (HIP-1332 §13.1). No program has made that move: no repository implements enso.decide.
# Enso picks the model; X-Routed-Model says which one served.
curl https://api.hanzo.ai/v1/chat/completions \
-H "Authorization: Bearer $HANZO_API_KEY" -H 'Content-Type: application/json' \
-d '{"model":"auto","messages":[{"role":"user","content":"Summarize this diff."}]}'
# A Zen model by name.
curl https://api.hanzo.ai/v1/responses \
-H "Authorization: Bearer $HANZO_API_KEY" -H 'Content-Type: application/json' \
-d '{"model":"zen6","input":"Write a failing test for this bug."}'
# Tell the router how it did (HIP-0510 §2).
curl https://api.hanzo.ai/v1/ai/feedback \
-H "Authorization: Bearer $HANZO_API_KEY" -H 'Content-Type: application/json' \
-d '{"request_id":"<id from the response>","reward":1}'
# Kai (HIP-1332 §17).
curl https://api.hanzo.ai/v1/decisions \
-H "Authorization: Bearer $HANZO_API_KEY" -H 'Content-Type: application/json' \
-d '{"model":"kai","state":{"subject":"Charged twice this month"},
"questions":{"team":{"type":"choice","instructions":"Which team handles this ticket?",
"criteria":{"billing":"charges, refunds","technical":"errors, outages","account":"sign-in, access"}}}}'zen-router is both the gateway's alias for auto (HIP-0510 §1) and the router model zenlm/zen-router. The alias never calls the model.
also the generative family's name.
hanzoai/kai-1* carry the Kai name and Laya weights.Families are split by job, not by architecture or vendor, because the job decides the API and the cost. A generation spends tokens; a decision has a known answer space and generates none. Putting routing and decisions in their own families lets a request reach a generative model only when generation is the work.
Released under CC0 1.0 Universal Public Domain Dedication.