Your coding agent says "done." kazi proves it.

You chat with Claude Code, it drives kazi

You don't operate kazi directly — your coding agent does. Once you've run kazi install-skill, the skill verbs /kazi plan and /kazi apply — or the plain-English phrase “have kazi drive this until done” — route to kazi. They're triggers on the kazi skill, so they only work once it's installed.

1. You
   describe the outcome you want, in plain language
2. Claude Code
   authors the acceptance predicates with kazi plan
3. kazi
   runs kazi apply, looping the agent until the predicates are objectively true
4. Claude Code
   reports back — converged, or honestly stuck

How it works

Under the hood, kazi is the outer/reconciliation loop for coding agents— your agent runs it, not you. It drives the coding agent you already use (Claude Code, Codex, …) in a reconcile loop: observe every failing check, dispatch a fix, integrate, re-check. It is not another coding agent, terminal, or IDE — as that agent gets better, kazi gets better for free.

Think of it like Kubernetes for coding goals: you declare desired state, kazi watches actual state, and it closes the gap until the two match.

1. 1
   Observe
   evaluate every predicate against reality
2. 2
   Diff
   compare desired vs actual state
3. 3
   Dispatch
   hand the failing slice to a coding agent
4. 4
   Re-observe
   re-check the predicates
5. 5
   Decide
   converged, stuck, or over budget

Why kazi

With kazi vs. without

Token economy without local models

The cheapest agent loop isn't a local GPU — it's spending frontier reasoning once, then grinding on a cheap model the predicates keep honest. kazi makes that an in-family Claude move, so any Claude Code user gets it with no local model and no local GPU host.

• The grind → default grind tier
  The N-iteration grind runs on the default grind tier (Sonnet 5, claude-sonnet-5).
• Hard reasoning → frontier model
  Authoring the predicates runs once on a frontier model (e.g. Opus 4.8, claude-opus-4-8).
• Predicates keep it honest
  The cheap model can't declare a false “done” — convergence is gated on objective checks, not its say-so.
• Pay frontier rates only for judgment
  Frontier pricing for authoring the predicates, cheap rates for the bulk of the work.

# Author the predicates once (a frontier model drafts them), then approve:
kazi plan "add a /healthz endpoint that returns 200 ok" --workspace ./svc
kazi approve <proposal-ref>

# Drive the grind on the default grind tier — no local model needed:
kazi apply my-goal.toml --workspace ./svc --harness claude --model claude-sonnet-5

claude-haiku-4-5  →  claude-sonnet-5  →  claude-opus-4-8   (cap — don't escalate past Opus)

Designed-for, not yet measured. The cost win is the intended economics — frontier judgment once, cheap iterations gated by predicates. The headline dollar figure is being measured by the multi-iteration benchmark; until it lands we state the shape of the saving, not an unproven number.

Want full privacy instead? Local / bring-your-own-model is the secondary option: point kazi at a local model via opencode so your code and context never leave your hardware. It trades the in-family convenience for on-prem privacy.

What a coding agent says

Who it's for

Not for you (yet) if you want an agent to decide what to build — that's your call; kazi only drives toward an outcome you declare. It also needs a coding harness (claude, opencode, …) on your PATH — kazi drives one, it isn't one.

Reference: drive kazi directly

Most people never touch these — Claude Code runs them for you (above). They're here for agents and for anyone who wants to drive the loop by hand.

brew install kazi-org/tap/kazi

kazi plan "a /healthz endpoint that returns 200"
kazi approve <proposal-ref>

kazi apply my-goal.toml --workspace ./my-project