How to build a Claude Code clone in YAML

Claude Code is genuinely good. It's also a closed-source CLI that calls Anthropic's infrastructure with Anthropic's prompts and bills your account for every keystroke. If you want roughly the same experience but running on your laptop, against the model provider you choose, with the prompts all sitting in a file you can read and edit, that's what this guide is about. Around 60 lines of YAML and you're there.

The tour goes like this. We pick apart what Claude Code is actually doing under the hood. Each piece becomes a YAML primitive on the Digitorn runtime. Then we look at the full app.yaml, talk about cost (Sonnet for the writing, Haiku for the grunt work), and do the multi-agent dispatch which is where most home-rolled clones fall over. At the end there's a 5-minute install path.

By the time you're done you'll have a coding agent on your machine doing what Claude Code does, on your API keys, with the entire behaviour readable in a single config file.

#The short version

Claude Code feels magical, but the recipe is mundane. Short tool names. A coordinator that delegates. A read-before-edit rule. A plan written before any code is touched. Every one of those is reproducible declaratively if your runtime exposes the right primitives. Digitorn does, so the rest is just YAML.

About sixty lines, same loop, your keys.

#What's actually going on inside Claude Code

Strip the polish off and there are five specific things tuned in a specific way. Reproducing those gets you most of the way there.

#Short, ergonomic tool names

Tools are called Write, Read, Edit, Bash, Grep, Glob, Agent. Not filesystem.write or shell.bash_execute. The reason is partly economics (every byte the LLM emits costs money) and partly cognitive: a short, unambiguous name like Write(path, content) lets the model commit. Something like tools.filesystem.WriteFileWithOptions(...) makes it hesitate, then hallucinate options.

#Spawning sub-agents on the fly

Ask Claude Code to "find every place this function is called and refactor them" and what really happens is two passes: a search worker runs to map call sites, then a refactor worker rewrites each. You don't see the orchestration. You just see the result.

That trick is what makes a coding agent feel competent. A single 200K-context model trying to grep thirty files, read them, and rewrite them all in one prompt is a hallucination factory. Splitting the job into a coordinator plus focused workers is what production setups do.

#Refusing to edit what hasn't been read

Claude Code won't edit a file unless it has been read first. Sounds dull. It's the single difference between "the agent helped me" and "the agent silently corrupted half my codebase". Ask any LLM to edit a file it has never seen and it will happily invent the contents, guided by the filename. Every time.

#Writing a plan before doing anything

For anything non-trivial, Claude Code first emits a numbered plan, then executes it step by step. Without that, the agent wanders. With it, you get focused work, and you can read the plan to know what's about to happen.

#Clean interrupt and reload

Hit Ctrl+C and the agent stops cleanly: in-flight tool calls are cancelled, conversation state is preserved, the next prompt picks up without re-establishing anything. Edit the app's YAML and the change takes effect on the next session. Both are the kind of thing you don't notice until you use a tool that doesn't have them, then can't go back.

Five pieces, laid out side by side:

Each one becomes a primitive in the YAML below. None of them require code on your side.

#The architecture in YAML

Here's the full app.yaml for a Claude Code-equivalent agent, running on Digitorn. This exact file compiles cleanly against the current schema:

1schema_version: 223app:4  app_id: claude-code-clone5  name: "Claude Code clone"6  version: "1.0.0"7  description: "Multi-agent coding assistant."8  category: "developer-tools"910modules:11  filesystem:12    config:13      workspace: "."14      max_file_bytes: 209715215  bash: {}16  memory:17    config:18      working_memory: true19      todo_list: true20  agent_spawn: {}2122runtime:23  mode: conversation24  entry_agent: coordinator2526security:27  behavior:28    profile: coding2930agents:31  - id: coordinator32    role: coordinator33    modules: [{agent_spawn: [agent]}, {filesystem: [read, grep, glob]}, {memory: [set_goal, task_create, task_update]}]34    brain:35      provider: anthropic36      model: claude-sonnet-537      credential:38        ref: anthropic_main39        scope: per_user40        provider: anthropic41      temperature: 0.242      max_tokens: 819243    system_prompt: |44      You are a coordinator. Plan first, then execute.45      Delegate exploration to the explorer specialist via agent(agent="explorer", task="...").4647  - id: explorer48    role: specialist49    specialty: "Find files, grep symbols, sample contents"50    modules:51      - {filesystem: [read, grep, glob]}52      - {bash: [run]}53    brain:54      provider: anthropic55      model: claude-haiku-4-556      credential:57        ref: anthropic_main58        scope: per_user59        provider: anthropic60      temperature: 0.061    system_prompt: |62      You explore codebases. Return only the key findings.63      No prose. Be FAST.

That's the entire file. Here's what the runtime actually wires up at boot:

One coordinator on Sonnet, one explorer on Haiku, four modules, and one behaviour profile. Now let's walk through what each block buys you.

#Modules are the toolbox

Each module is a set of tools the agents can call. Modules are declared once at the top level, then each agent lists only the ones it needs - the coordinator gets filesystem read-only tools plus agent_spawn, the explorer gets filesystem and bash. Same workspace, same working memory, shared between both.

#security.behavior.profile: coding is where the safety rules live

This is the part that actually reproduces Claude Code's "won't edit what it hasn't read" behaviour - and it's more specific than a single guard. The coding profile bundles a whole set of rules: read_before_edit and read_before_write_existing (edit only what's been read this session), plan_before_execute (write a plan before non-trivial work), confirm_destructive (block a command like rm -rf outright), no_bash_for_files (warn when the agent reaches for cat instead of the read tool), and a cap on repeating the same tool call too many times in a row. One line, profile: coding, turns all of it on.

#Agent spawn is the dispatcher

This is what lets the coordinator hand work off to an explorer. The multi-agent surface in Digitorn is a system module, agent_spawn, exposing one real tool:

Two parameters: which specialist agent to delegate to, and what to ask it to do. The coordinator calls it, the explorer runs its own turn against its own (cheaper) brain, and its findings come back into the coordinator's context.

#Per-agent brain, where the cost story lives

The coordinator runs on Claude Sonnet, full context, 8192-token outputs. That's where the actual code gets written, so quality has to be good. The explorer runs on Haiku - noticeably cheaper and faster, perfectly capable of grepping a directory and returning a list of hits.

That single split is what turns a self-hosted coding agent from "expensive curiosity" into something you can run all day. A coordinator-only setup with Sonnet on every turn costs roughly the same as a Claude Code subscription. Offloading exploration to Haiku trims a meaningful chunk off that on realistic workloads, because exploration is most of the LLM time.

Numbers above are normalised against a Sonnet-only baseline. Your mix will vary, but the shape doesn't: the more exploration you can push to the cheap model, the better this gets.

#What it looks like in practice

Easier to make this concrete with an example. Say you ask the coordinator: "Find every place we call auth.verify_token() and add logging before each call." Here's how the turns play out across the agents.

A few things are worth pointing at in this trace. The coordinator never greps the codebase itself, it hands that off to a Haiku worker. The read_before_edit rule catches the first attempt to edit login.py before it's been read this session, so the coordinator reads it before touching it. Sonnet tokens go only to the steps that actually need Sonnet.

#What goes wrong, and how the runtime catches it

A handful of failure modes show up over and over when people roll their own coding agent. These are the ones worth knowing about up front.

The first is the agent editing a file it has never read. Without a rule against it, the LLM imagines the file contents from the filename and writes a "fix" that bulldozes the real code. It's the leading cause of "the AI deleted my work" stories. security.behavior.profile: coding's read_before_edit rule blocks an edit on anything the session hasn't read yet - the model gets a tool error, reads the file, retries.

Destructive shell commands are the next big one. confirm_destructive blocks an obviously destructive command (an rm -rf, for instance) outright rather than letting it run. no_bash_for_files separately nudges the agent away from cat/sed for routine file reads and edits, toward the filesystem module's own tools, which are easier to reason about and to review.

Then there's raw tool output eating the context window. One read of a huge log file and you've burned a chunk of your budget. filesystem.config.max_file_bytes caps what a single read can pull in.

The infinite re-edit loop is more annoying than dangerous: the agent edits, the file doesn't compile, it edits again, doesn't compile, repeats. The coding profile's max_sequential_same_tool rule catches a run of identical tool calls and interrupts it rather than letting it spiral.

The last one is goal drift. After many turns, context compaction starts shaving off the early messages and the original task fades. Calling memory's set_goal tool on the first user message keeps the goal pinned at the top of every subsequent turn, even after compaction.

#Getting it running in five minutes

If you want to try this tonight, the path is roughly:

1# Install the runtime (Mac, Linux, or Windows with Git Bash)2curl -sSL https://digitorn.ai/install | sh34# Drop your Anthropic key in5echo 'ANTHROPIC_API_KEY=sk-ant-...' >> ~/.digitorn/.env67# Save the YAML above as app.yaml in a new folder8mkdir my-coder && nano my-coder/app.yaml   # paste the YAML910# Install and open11digitorn install ./my-coder12digitorn chat claude-code-clone

You land in a terminal session with a coding agent that knows about the directory you started it in, can read and write files there, run tests, and spawn an explorer worker when it needs to. Same loop as Claude Code. Your keys. Your YAML.

If you'd rather not start from a blank file, the Digitorn Hub already ships a polished version called digitorn-code under developer tools. One install command and you're done.

#A few questions worth answering

Is this exactly Claude Code? No. Anthropic's internal prompts aren't public, and probably never will be. What this clone reproduces is the architecture: the tool surface, the read-before-edit behaviour rule, the multi-agent dispatch, the plan-first behaviour, the cost routing. The prompts are yours to write and iterate on, which is more than you get with the closed product.

Can I run it on something other than Anthropic? Yes, against any OpenAI-compatible endpoint. Swap anthropic for openai, deepseek, azure_openai, mistral, groq, together, or whatever else. Mixing per agent is fine and usually a good idea: coordinator on a strong model, explorer on a cheap one.

How is this different from LangChain or CrewAI? Different philosophy. LangChain is Python-as-config, you build agents by writing Python. Digitorn is YAML-as-config, you declare the agent and the runtime executes it. LangChain is better when you need deeply custom Python-native pipelines. Digitorn is better when you want a coding agent and you don't want to maintain framework code on top of it. The matrix is at Digitorn vs LangChain.

What about Cursor, Aider, Continue? Different shapes. Cursor is a full IDE, so a different category. Aider is the closest in spirit (self-hosted, CLI), but its configuration leans Python and is harder to extend. Continue is an editor extension. The thing specific to Digitorn is the declarative YAML plus built-in multi-agent.

Does it work fully offline? Yes, as long as your model has an OpenAI-compatible endpoint. Run Ollama or vLLM locally, point the YAML at http://localhost:11434/v1, and you have a coding agent that never phones home. Quality is the trade-off: local models still trail Sonnet-class models for production coding work, but the gap shrinks every month.

Can I share an agent with my team? Push it to the Digitorn Hub. Your teammate runs digitorn install hub://your-publisher/my-coder@1.0 and they have it. Agents travel as YAML plus small assets, so prompts get reviewed in PRs like any other code.

#A few links if you want to keep going

• 📦 Install Digitorn and try the YAML above
• 📚 The full module reference, every primitive used here is documented
• 🔄 Self-hosted coding agents compared, Digitorn next to LangChain and CrewAI
• 📂 The developer-tools agents, where digitorn-code ships ready-to-go

Built a variant worth sharing? Push it to the Hub. That's how the ecosystem grows.