HIP-0511: Model Families — Zen Generates, Enso Routes, Kai Decides

Abstract

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. 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.

Motivation

One name was carrying several things. "Enso" is a router, a SKU family, a diffusion fork and a browser fork. The public hanzoai/kai-1 repositories hold baseline weights, not Kai. Zen6 shipped open weights and a live API with no HIP naming it. HIP-0003 described a Jin model that was never built. 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.

Specification

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 as of 2026-09-25:

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.

1. Families

2. Zen

Open weights live under zenlm/ on Hugging Face, licence and base per model card. Hanzo Cloud serves the ids in the third column.

Hanzo Cloud also lists zen-free.

3. Enso

4. Kai

5. Other names

6. One request, in order

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 chose

A 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.

Today 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). On 2026-09-25 no program has made that move: no repository implements enso.decide.

7. Calling each family

# 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). Specified; not served yet.
curl https://api.hanzo.ai/v1/decisions \
  -H "Authorization: Bearer $HANZO_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"kai","program":"agent.preflight@4","evidence":[],"state":{}}'

8. Names that collide

• 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.
• The Enso Browser tree still carries its upstream's name, "Zen Browser", which is also the generative family's name.
• hanzoai/kai-1* carry the Kai name and Laya weights.
• Enso names both the router family and Enso Diffusion, which does not route.

Rationale

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 is what lets a request reach a generative model only when generation is the work.

References

• HIP-0039 — Zen, the open-weight generative family; HIP-0904 — Zen6
• HIP-0510 — Enso, the router family
• HIP-1211 — AI, the model API
• HIP-1332 — Kai, the decision model and the decision plane
• HIP-0002 — HLLM; HIP-0003 — Jin

Copyright

Released under CC0 1.0 Universal Public Domain Dedication.