Getting started

For a reader who has not used Saphan Studio before, in the order a first fleet needs.

After reading this section you can install the product, set a machine up, and run one stream from an order to a human decision to a recorded result.

Before you start: nothing for this page. The next page needs a machine you can install on.

Read in this order. This page, then install and first run, then which agents it drives, then the shape of one stream. Everything after those four is depth you can take in any order.

In one paragraph

Saphan Studio is a control plane for fleets of AI coding agents — Claude Code, Codex, and local models, on your own machines. It takes work you have specified, prices it before anything runs, dispatches it to agents working in isolated git worktrees, routes every artifact they produce into one durable record, and stops at every decision that matters — plan approval, acceptance of results, merge, teardown — because those decisions are yours, not the machine's. Around that loop it keeps the books: every run carries a quote and a hard cap, every dollar lands in a ledger next to its quote, every refusal is recorded with its reason, and the whole fleet — streams, gates, liveness, spend — is readable at a glance from a CLI, a dashboard, a VS Code panel, an exported report, or any MCP client. The engine automates the transport and the mechanics of running many agents in parallel; it never automates a judgment.

The problem it solves

One coding agent in a chat window is manageable. Five of them, working in parallel on the same codebase, are not — not because the agents are weak, but because four questions stop having obvious answers:

Where does each one work? Two agents editing one checkout corrupt each other silently. Saphan gives every piece of work its own stream: one branch, one isolated git worktree, one lifecycle. Agents cannot trample each other because they never share a working tree.

Who decides? An agent that can merge its own work is an agent whose mistakes ship. In Saphan the engine never merges, never pushes, never accepts — every stream passes through explicit human gates, and a gate decision has no default value and no timeout. Silence is never consent.

What will it cost — and what did it cost? Agent work has a real price per run, and without accounting it drifts. Every Saphan dispatch carries a quote and a cap you see before anything runs; every run's actual cost lands in the ledger next to the quote, so drift is a number you read, not a surprise on an invoice.

What happened, afterwards? When five agents worked for a day, "what did we do and why" must be answerable from something better than five scrollbacks. Saphan's record — gates, runs, costs, refusals, observed merges — is the durable account of the fleet's work, and every view in the product is a projection of it.

The underlying stance: an agent is treated as a capable but unaccountable worker. It gets real work, real isolation, and a real budget; accountability stays with the human, and the record proves who decided what.

A note on language

Saphan Studio is language-agnostic. Orders, agent conversations, channel records and dashboard content are in whatever language your team works in; the engine's own vocabulary — verbs, states, refusal classes, record fields — stays English underneath, and mixing the two is normal. Nothing about the tool assumes English-speaking operators: run it in German, Japanese, or three languages at once.

What this section does not cover

⚠ Deploying to more than one machine is Deployment. ⚠ The reasoning behind the design — why a record rather than a log, why a gate rather than a policy — is Concepts, which is written to be read straight through. ⚠ This section does not cover extending the product; it is written for operating it.