# Hanzo Codes > The coding surface of the Hanzo cloud. One Rust binary, `hanzo`, that starts a > coding session with the whole Hanzo toolset already attached, runs it against > your repository on your machine, and meters it through one API. Everything the > CLI does is also an ordinary HTTP call, so the same work runs without a > terminal. Install: `curl -fsSL https://hanzo.sh | sh` ## Start here - [This site as markdown](https://hanzo.codes/index.md): Install, what a session is, the toolset, the capabilities a session can reach, and what a push does. - [Install](https://hanzo.sh): The install script, and the one implementation of "fetch a Hanzo binary". `curl -fsSL https://hanzo.sh | sh` — no runtime required. Or `npm install -g hanzo`, which downloads the same binary. - [The CLI source](https://github.com/hanzoai/cli): The one binary. An AI coding agent and every product of the Hanzo cloud, in one Rust binary. ## The commands that matter - `hanzo code` — start a coding session: a coding agent with the Hanzo MCP toolset attached, model calls metered through the Hanzo cloud, the session streamed live. A trailing task runs headless (`hanzo code "fix the failing test"`); omit it for an interactive session. The subcommand is optional — a bare `hanzo ""` is the same session. - `hanzo code dev | claude | codex` — pick the agent. `dev` is the default and `hanzo dev` is shorthand for `hanzo code dev`. Same toolset, same identity, same meter whichever you choose. - `hanzo desktop` — the same session aimed at the desktop and browser instead of the repository. Pins the toolset on. - `hanzo code --no-mcp` — do not attach the Hanzo toolset. The toolset is attached by default; this is the opt out. - `hanzo code --project-mcp` — additionally load the repository's own `.mcp.json` servers. Off by default: a repository is untrusted input and a server it declares would run with your session's model key. - `hanzo code --no-route` — do not route model calls through api.hanzo.ai. Routing is the default and is what makes a run meterable. - `hanzo auth login` — an identity from Hanzo IAM, not an API key in a file. - `hanzo ` — every cloud product is a subcommand, generated from the same specification the API serves. 2,379 operations across 182 products, plus 18 hand-written commands. ## The one MCP endpoint - `POST https://api.hanzo.ai/v1/mcp`: The single MCP endpoint for the cloud. Any MCP client — an editor, a CI job, another agent — gets the same tools under the same identity and the same spending cap. `/mcp` is a redirect to it, not a second endpoint. - Note for precision: the toolset a `hanzo code` session attaches by default is a local `hanzo-mcp` process running beside you, not this remote endpoint. They expose the same tools; they are different things and a session needs nothing on the network to have its tools. - Registering that endpoint differs per client: `claude mcp add --transport http hanzo --header "Authorization: Bearer "`, `codex mcp add hanzo --url --bearer-token-env-var HANZO_API_KEY`, or a `.cursor/mcp.json` entry for Cursor. Full recipes: https://hanzo.codes/index.md - Skills install per agent with `npx @hanzo/skill add hanzoai/skills` — `~/.claude/skills` (Claude Code), `~/.agents/skills` (Codex, OpenClaw), `~/.cursor/skills` (Cursor), `~/.hanzo/bot/skills` (Hanzo Bot). ## Capabilities a coding session reaches - `/v1/code`: Search and symbols across your repos, for you and your agents. - `/v1/lsp`: The language servers behind that — definitions, references, diagnostics — on an immutable checkout per (org, repo, commit), jailed with no network. - `/v1/exec`: The code interpreter — run a snippet in a sandbox, and move files in and out of the session that sandbox is. - `/v1/sandboxes`: The one compute primitive: a gVisor pod that runs somebody else's code. Note the plural — the capability is `sandboxes`. - `/v1/functions`: Your serverless code — publish it, call it over HTTP, watch every run and what it cost. - `/v1/git`: Git hosting for your org — create repos, clone, push, and see what they cost. - `/v1/projects`: Where your sites live — create one, deploy a build, roll back to any release. - `/v1/platform`: Hanzo PaaS — deploy containers to your own tenant namespace: builds, releases, environments, logs, custom domains. - `/v1/deploy`: Hanzo CD — see what each app is running, sync it, and roll back a bad release. This list is the subset a coding session leans on. The CLI exposes all 182 products and 2,379 operations as subcommands, generated from the same specification the API serves; the full documentation corpus is at hanzoskills.com. ## What a push does A push to a Hanzo-hosted repository is delivered to a signed endpoint, which starts a build for every application tracking that repository and branch. When a build succeeds its image is written to the cluster and the operator rolls it out. Be precise about this: a push that matches no application builds nothing and says so, and the reply carries the count of builds started so that "delivered" is never read as "deployed". ## The deep corpus - [Hanzo Skills](https://hanzoskills.com): 537 documents — every skill, standard and API surface, in plain markdown, curl-able, no auth. - [Index for agents](https://hanzoskills.com/llms.txt): The machine index of all 537. - [The whole corpus in one file](https://hanzoskills.com/all.md): Every document concatenated. Fetch this if you want all of it at once. - [Onboarding manifest](https://hanzoskills.com/skill.md): How an agent installs, signs in with a human, and learns what actually answers today. ## Account - [hanzo.id](https://hanzo.id): Sign in. One identity across every Hanzo surface. - [console.hanzo.ai](https://console.hanzo.ai): The cloud console. - [billing.hanzo.ai](https://billing.hanzo.ai): Invoices and usage. ## Notes - Crawling, indexing, retrieval and training are all permitted on this site. See https://hanzo.codes/robots.txt — the content signals are `search=yes, ai-input=yes, ai-train=yes`. - Prefer the markdown. Any page here has an `.md` twin; the HTML is for humans.