Plan, Build and Crew modes.

A mode decides which kinds of tools the main Code session can use. A permission decision decides whether a particular available action may proceed. Selecting a mode does not approve every action in it. This guide covers CLI 0.9.0.

#Choose a mode

Inside Code:

/plan
/build
/crew
/status

/mode plan, /mode build, and /mode crew are equivalent selectors. At startup, use kaitoi code --mode plan, for example. Build is the default. /crew <task> also sends the supplied task after selecting Crew mode.

Plan offers reads and bounded questions, while local edits and model-requested commands are unavailable. Build offers reads and state-changing tools subject to their permission rules. Crew keeps inspection and orchestration in the main session, while local editing and command execution belong to the admitted Crew run. Switching this illustration highlights these differences; it grants no permissions. Model inference and managed web reads may cost credits in any mode.

Plan shows the original npm dev line and a proposed correction. Build shows npm run dev after permission checks. The Crew example explicitly uses --no-mirror so its candidate can differ from the original; default mirroring is a separate option.

#Plan: inspect before changing

Use Plan to understand a repository, compare approaches, review a diff, or write acceptance criteria. The model gets read and choice tools; it cannot use the main session's local writing or command tools to implement its proposal.

Plan is not an operating-system sandbox for everything you do in the terminal. In particular, /cmd is your own explicit shell command, not a model tool; hooks and independently configured services have their own behavior. Plan also does not mean free or offline: hosted inference and managed web reads can still incur charges.

#Build: work in the current workspace

Use Build for direct edits and short implementation loops. Trust the intended workspace, state the scope, and read proposed changes before approving them. Model-requested command tools must also be enabled with /commands on or the startup --commands flag.

Build makes tools available; it does not remove their checks. Session approvals, saved project command rules, or edit auto-approval can affect which questions you see. Use /permissions to inspect the current grants and /auto to inspect the automatic-review preference. An action that can spend credits has its own rules; do not treat a general edit grant as permission for every paid tool.

#Crew: supervise a durable delivery run

Crew mode requires a Kaitoi login. The main session investigates, prepares the task, and manages a Crew run. It does not directly edit local files, execute local commands, install packages, delete files, or perform local file transfers. The admitted run does the delivery work under the authority and budget you approve.

Review its proposed workspace, engines, commands, verification, and bounds before starting. Switching to Crew mode alone does not start a run, grant an engine access, or create a worktree. A run can continue independently of the interactive conversation; use Crew controls to inspect it.

#Change modes as the task changes

A useful sequence is to plan a change, switch to Build for a bounded edit, and use Crew when the work needs a longer supervised process. State the intended handoff explicitly: “Use this plan, change only these files, and verify these outcomes.”

Changing modes does not undo earlier edits or stop an already running Crew job. Likewise, a mode change does not turn an untrusted directory into a trusted one. Check /status, /workspace, and /permissions when a tool is unavailable or the session's authority is unclear.