全​新​推出!​Jouzu — ​我们​为​日本​打造​的​ C​LI 智​能​体​编程​框架。​60 ​秒即​可​连接。了解​更​多

Shisa AI's terminal coding agent.

A coding harness and model router. One curated, eval'd catalogue of open models, served on Shisa's own platform, with local content scanning before anything reaches a model.

What it is

A terminal agent built on the Pi coding agent, wired directly into Shisa's serving platform.

Jouzu is where three parts of the Shisa stack meet in one product: the Shisa API serves every model in its catalogue, Shisa realtime transcription powers voice dictation, and TextGuard — Shisa's own Go scanner — checks skills and fetched web content locally before the model ever sees them.

It is a command-line tool first, but ships with a desktop launcher as well. It is explicitly alpha: the README states "v0.1.x is alpha software. Expect frequent updates and changes."

Jouzu terminal coding harness · built on the Pi coding agent Shisa API serves every model in the catalogue served Realtime transcription powers voice dictation /voice · Ctrl+\ served TextGuard scans skills and fetched web content on your machine
Three pieces of the Shisa stack in one product. Two are reached over the network; TextGuard is a Go binary that runs locally and never sends content anywhere.

Install

npm install -g jouzu
jz doctor        # non-mutating diagnostics
jz               # start a session in the current directory

jz is an alias for jouzu. It can be run without installing via npx --yes jouzu, and there is a signed Windows x64 installer, the Jouzu Launcher, that bundles every requirement — including its own Node runtime, so the system Node version does not matter.

Requirements: Node.js 22.19+, Git, and Bash (Git Bash on Windows). First launch asks whether to enable the Japanese profile, then offers to connect a Shisa account. New Shisa accounts receive USD 10 in credits.

Models

One catalogue, one API, every model served by Shisa.

The model picker (/model or Ctrl+L) searches providers and models, keeps favourites, and saves per-project defaults. Shisa's catalogue is built in and activates on sign-in. Catalogues are pluggable and publishable — see /catalogs.

Jouzu one picker Shisa API one endpoint shisa/qwen3.7-max shisa/qwen3.8-max shisa/qwen3.8-flash shisa/qwen3.8-27b shisa/qwen38-flash-next-nvfp4 shisa/qwen3.7-flash shisa/qwen3.7-plus shisa/glm-5.2 shisa/kimi-k3 your catalogues pluggable Akamai Anthropic OpenAI
The catalogue as read from a signed-in session on 2026‑10‑06. Third-party catalogues reach their provider directly rather than through the Shisa API — same picker, different path, which is why that branch is drawn separately.
The Jouzu model picker showing nine models, each served via Shisa API
The model picker, All view. Every row resolves to Shisa API — this is the "served on our own platform" claim, demonstrated.
ModelNotes
shisa/qwen3.7-maxcontext 1M · max output 131.1K · project default in the captured session
shisa/qwen3.8-max
shisa/qwen3.8-flash
shisa/qwen3.8-27b
shisa/qwen38-flash-next-nvfp4NVFP4 quantised
shisa/qwen3.7-flash
shisa/qwen3.7-plus
shisa/glm-5.2
shisa/kimi-k3
Accuracy note. This is the live catalogue as read from a signed-in session on 2026‑10‑06. It is not the list used on the Shisa one-pager slide, which names "GLM 5.3", "DeepSeek v4 Pro" and "Shisa V2.1 70B". GLM is at 5.2 and DeepSeek does not appear at all. Shisa V2.1 does exist — shisa-ai/shisa-v2.1-llama3.3-70b and shisa-ai/shisa-v2.1-unphi4-14b are both in the catalogue — but neither declares tool_calling, and both cap at 32K context, so they cannot drive a coding session and do not belong in a tree of models Jouzu routes code through. Correct the slide before circulating it.

The picker lists these nine because they are the ones that declare tool_calling. The account catalogue actually holds fourteen offerings: the five others are shisa-ai/ domain models — two Shisa V2.1 variants, two Chotto models and shisa-de-1 — which declare no capabilities and report maxOutputTokens: 0. They are served, but they cannot be an agent role.

Jouzu is not open-models-only. docs/astra.md documents model-specific handling for GPT-6 Astra against api.openai.com, including thinking levels and prompt-cache options. The router adapts to proprietary frontier models too.

Capabilities

Rather more than a chat loop in a terminal.

Goals, loops, scheduled work

Objectives with token caps, measured loops in independent lanes, and prompts that fire later. See below.

Background jobs

Run shell jobs while you keep working; completions arrive as batched summaries.

Child agents

Each agent gets its own model, tools, instructions and workspace.

TextGuard

Local scanning of skills and web results before they reach the model.

Voice dictation

Speak into the prompt using Shisa realtime transcription. /voice or Ctrl+\.

Japanese text support

Correct layout for Japanese, Chinese, Korean and emoji widths, plus an optional Japanese profile.

Compaction with searchable history

VCC compacts the transcript without a model call; vcc_recall searches what was removed.

Web search and fetch

Fetch pages directly or through a browser that installs on first use.

Model catalogs

Pluggable catalogue sources. Shisa's is built in; others can be added and published.

Flow control

Coordinates jobs, goals, loops and tasks — and explains why automatic work stopped.

Task management

Jouzu keeps a punchlist, runs jobs beside it, and decides for itself when a turn needs a reply.

Given multi-step work, Jouzu creates a numbered task list and works it, marking each item complete as it goes. Background jobs run alongside, and the Session Line carries both — so the state of the work is visible without asking for it.

The Jouzu session line showing one background job running and a task list part-complete
Mid-run. Jobs · 1 running with elapsed time, Tasks · 1 running · 2 open · 2 done, and the item currently in hand. The file write above it is the task being executed.

The list is addressable at any time with /tasks, which offers View all tasks, Create task, an auto-mode toggle (cascade by default), and bulk clear.

The Jouzu task list with five completed items
The punchlist after a run: five numbered items, each marked [completed].

Background jobs and flow control

Jobs report back as notifications rather than interrupting. Flow control then decides whether the turn needs a response at all — here the job landed after the work was already finished, so the agent closed the turn with agent_no_reply instead of padding out a reply.

A background job completing as a notification, with the agent ending the turn without replying
bg-1 completing with exit code 0, delivered as "notification only — no reply owed".

Goals, loops and scheduled work

Four containers for work, widening in scope — and one layer underneath that keeps them honest.

Each container holds state the conversation itself cannot be trusted to keep, and each has its own way of stopping. Tasks are the shared punchlist, covered above. Above them sit goals (one objective, worked until done), loops (repeated, measured iteration) and scheduled prompts (work that fires later). Flow control sits under all four — it is what makes autonomous work safe to leave running.

01 Tasks

the shared punchlist

agent A agent B whoever is free takes the next

So nothing is forgotten — and so any agent can take the next item off the list. It also keeps context small: the list carries the mission, so no single turn has to.

02 Goals

one objective, until done

sprint 1 sprint 2 sprint 3 sprint 4 sprint 5 Goal sprints fade · objective does not token cap → pause, not overspend

The objective is held outside the conversation, so the work cannot drift — however long the sprint runs. A token cap pauses it rather than spending past the budget.

03 Loops

measured iteration, in a lane

metric iterations i1 i2 i3 every pass scored · kept or reverted

One agent works the same problem again and again and measurably gets better at it — every pass scored against a metric and a verify command, then kept or reverted.

04 Schedules

work that fires later

now t1 t2 t3 t4 fires the other three Tasks Goals Loops one-time, or on a cadence

Fires any of the other three later, or on a cadence — a loop overnight, a goal on Monday, a check after the deploy. Each stored job keeps its own run count and last outcome.

Flow control

Every automatic hand-off passes through it — a job finishing, a loop iterating, a schedule firing, a child agent reporting back. It is the layer underneath all four.

  • Batches. Background results land after the current reply instead of cutting into it.
  • Waits. A task can block on your input, or on another job finishing first.
  • Holds. Input it cannot prove was delivered is held for you to settle — never replayed blind.
  • Declines. A turn that owes no reply ends, rather than padding one out.
  • Explains. Why automatic work stopped, and how to pick it up. /flow
Running a team of agents on top of this? A fan-out is driven by the same layer, and three of these four are how you keep a long one coherent — including the launch orders the write lock makes pointless. See Flow control, tasks and loops →

Goals

A goal is a persistent objective. Lane, mode and scope are derived for you; you can cap what it is allowed to spend.

The /goal command surface
The full /goal surface, read from a live session.
CommandEffect
/goal <objective>Start working now. Lane, mode and scope are derived for you.
/goal --tokens 50k <obj>Same, with a token cap that pauses the run when reached.
/goalShow the active goal and what it has cost.
/goal pause|stop|resumeControl the attached goal, or select a saved one by lane/run-tag.
/goal listRunning and paused goals, with command hints.
/goal clearDetach the goal. Its history stays in .multiloop/.
/goal tokens <N|off>Change or remove the token cap.
/goal allow-open-tasks <on|off>Allow completion while tasks are still open.
A goal is an ordinary multiloop run. /multiloop ls, status, resume and archive all operate on it. The difference is intent: use /goal for an objective, /multiloop when the work has a metric and a verify command.

Loops

Loops run autonomous, repeated work. The bundled pi-multiloop skill describes four modes — and this is where the word punchlist actually lives:

The multiloop skill description listing optimization, punchlist, research and development loops
"Quick goals through /goal, and measured optimization, punchlist, research, and development loops through /multiloop."
  • Each loop owns a lane with independent state. Running several at once means naming the lane in every tool call.
  • Loop state is carried by explicit start and resume prompts, tool results, /multiloop status, and compaction-aware resume prompts — so a loop survives the transcript being compacted mid-run.
  • Runs are recorded as <lane>/run-<timestamp> and keep a tally of iterations, keeps, reverts, logs, crashes and blocks.
multiloop status showing a completed run with its iteration tally
A real completed run: docs/run-20261006-072417 — dev mode, 3 iterations, 3 logs, zero reverts, zero crashes, zero blocks.

Scheduled work

The schedule_prompt tool registers one-time and recurring prompts. Each stored job carries an id, creation time, an optional session binding, an enabled flag, a run count, and the status and timestamp of its last run — running, success or error. Schedules are a flow wait source: what flow control waits on is the schedule's first trigger, not the completion of the prompt it fires.

Flow control

Flow control is the layer underneath all of the above. It batches background results after the current reply, lets tasks wait on input or on another job, and — importantly — holds input it cannot prove was delivered rather than silently replaying it.

/flow showing held input that may not have reached the model
/flow showing held input: "Sent, but whether the model received it is not known." Nothing is re-sent automatically.
CommandEffect
/flowWhy automatic work stopped, and how to resume it
/flow pause · resumePause or allow automatic replies. Background jobs keep running either way.
/flow off · on · resetDisable, enable, or reset queued and held delivery. Sessions and running jobs survive.
/flow clearRelease a stuck turn. Run while idle.
/flow resolve <attempt> retry|discardSettle a model request with an unknown outcome. retry may repeat a request the model already answered.
/flow runtimeStartup package paths and hashes

Interrupting a reply also pauses automatic work until your next message. JOUZU_FLOW_CONTROL=0 disables it for a process.

Branching is not symmetric. Returning to a branch you recently left resumes its unfinished work, including tasks waiting on background jobs. Rewinding to an earlier point starts a new branch and does not resume — and in neither case are file changes undone. If a branch is missing a tool result, Jouzu tells the model the outcome is unknown; it will not rerun the tool or borrow a result from another branch.

Agents and runs

Running a team of them? Two companion pages: the orchestration model — worked example, delegation API and the five traps that stop roles loading — and eight orchestration patterns, a catalogue of agent-graph shapes with the failure each one guards against.

Roles are declarative, and concurrency is governed.

Definitions live in agents.json (schemaVersion: 1) alongside maxConcurrent and a roles array. Each role carries:

FieldMeaning
id, descriptionUnique lowercase ID and display description.
model, thinkingExact model selector and thinking setting — per role, not per session.
instructionsInline instructions, up to 32,000 characters.
placementmain, child, or both.
judgingFresh review context with read-only built-in tools. Requires child.
toolsread grep find ls write edit bash powershell
timeoutSecondsDefault 7,200 (2 hours). Runtime accepts 10–2,147,483 seconds, about 24 days.
maxTurnsDefault 500.

Concurrency. maxConcurrent defaults to 2 and accepts 1–8; the queue holds up to 32 waiting tasks. Roles with write, edit or shell tools run one at a time per workspace, and separate Jouzu parent sessions serialise child writers through a workspace lock — so two agents cannot clobber each other's edits. Main-session edits and external programs do not participate in that lock.

Don't overclaim this one. The documentation is explicit that review-only is an assignment policy, not an OS security boundary. It restricts built-in tools to read, grep, find and ls; it is not a sandbox.

TextGuard

Content is scanned locally before a model sees it.

TextGuard scans skills and web content on the machine by default. Flagged web results reach the model labelled as untrusted data; flagged skills are withheld entirely until approved. Review findings with /textguard; change scanning for a session with /textguard on|strict|off, or start with --jouzu-textguard-strict / --jouzu-textguard-off.

skill fetched web page TextGuard local Go scanner clean flagged web flagged skill untrusted data the model withheld until approved
One scanner, two different verdicts. Flagged web content is downgraded but still delivered; a flagged skill never reaches the model at all. Both decisions are made on the machine, before anything is sent.
A Jouzu session showing TextGuard withholding a skill with two error-level findings
Unprompted, on a first run: TextGuard withheld a local skill with two error-level findings — the rule that fired was yara:command_injection. Path redacted. This is the data-safety claim demonstrating itself rather than being asserted.

Japanese support

Two profiles ship: core (default) and ja. The ja profile adds Japanese responses while leaving code, commands and paths unchanged — a distinction that matters for a coding tool. Beyond the profile, Jouzu renders Japanese, Chinese, Korean and emoji at correct character widths, which most terminal agents get wrong.

jz profile apply --profile ja
jz profile apply --profile core
Jouzu first run, offering the Japanese profile and a Shisa account
First run is bilingual by default: 日本語サポートを有効にしますか? — then the Shisa account offer.

The session

The status line carries the working context: provider and model with thinking level, the workspace and git branch with dirty-state flags, context consumed against the window, and tokens up and down.

A live Jouzu session with its status bar
A real session: Shisa qwen3.7-max (high) · ShisaBusiness · main · 3%/1m context · ↑33k ↓1.6k tokens.
The Jouzu desktop launcher asking which folder to work in
Jouzu also ships a desktop launcher — a workspace picker, not just a CLI.

Command reference

Command / keyAction
/login shisaConnect a Shisa account (/login for other providers)
/model · Ctrl+LChoose a model
Ctrl+PCycle favourite models
Ctrl+FToggle the selected model's favourite status
/workflowConfigure agents and inspect child runs
/goal · /multiloopManage goals and measured-improvement loops
/tasksView, create and clear tracked tasks; toggle auto-mode
/bgManage background jobs
/flowShow why automatic work stopped, and how to resume
/voice · Ctrl+\Start or stop dictation
/textguardReview flagged content
/statusSession, model and context usage
/catalogsManage model catalogue sources
/bugDraft a bug report
Ctrl+/ · /hotkeysHelp and shortcuts
Ctrl+EnterQueue editor text as a follow-up while the agent works
Ctrl+UpRestore queued messages to the editor

Built-in tools

ToolPurpose
schedule_promptOne-time and recurring prompts
bg_taskRun and monitor shell processes without blocking
web_fetch, batch_web_fetchFetch readable HTTP content
tff-fetch_url, tff-search_webBrowser-rendered fetch and search
TaskCreate et al.Track finite work
get_goal, update_goalWork toward a goal set with /goal
multiloop_*Record approved measured-improvement loops
subagentRun child agents
vcc_recallSearch earlier history, including compacted entries

Provenance

Everything above is drawn from two places, and it is worth keeping them apart.

Verified against a live install on 2026-10-06 (Windows x64, bundled Node 24.19.0): the version strings, the nine-model catalogue, the status line, the TextGuard withholding, the bilingual first run, the desktop launcher, and the jz doctor output.

From the repository at github.com/shisa-ai/jouzu (main, pushed 2026-10-03): the feature list, agent role schema, flow-control commands, tool list, profiles and keybindings.

Exercised live: task management, background jobs, goals, loops and flow control were driven end to end in a throwaway workspace on 2026-10-06 — a five-item task list created and completed, a 120s background job run to completion, the agent_no_reply path observed, a multiloop run started and stopped, and /flow holding undelivered input. Jouzu built a 13-file documentation skeleton in the process.

Not verified: the subagent surfaces (child agents, the subagent dashboard, review-only roles) were read from documentation, not exercised. The agent role schema above is quoted from docs/subagents.md.