How to build your own Claude Code, no code

Claude Code is genuinely good. It's also a closed product 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 against the model provider you choose, with the whole agent readable and editable, that's what this guide is about. You build it in Studio, no code.

The tour goes like this. We pick apart what Claude Code is actually doing under the hood. Each piece becomes something you assemble in Digitorn Studio. Then we look at how the agent is wired, talk about cost (a strong model for the writing, a cheap one for the grunt work), and cover the multi-agent dispatch, which is where most home-rolled clones fall over. At the end there's a 5-minute path to a working agent.

By the time you're done you'll have a coding agent doing what Claude Code does, on the models you pick, with the entire behaviour readable in one place.

#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 if your runtime exposes the right primitives. Digitorn does, and Studio wires them up for you, so you never touch a config file.

#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 long and nested 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 maps the 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

Stop the agent and it stops cleanly: in-flight tool calls are cancelled, conversation state is preserved, the next prompt picks up without re-establishing anything. Change the agent and it takes effect on the next turn. 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 is a switch you flip in Studio. None of them require code on your side.

#The architecture

Here's how a Claude Code-equivalent agent is wired on Digitorn: one coordinator on a strong model, one explorer worker on a cheap model, a small set of capabilities (files, shell, working memory, and the ability to spawn workers), and a coding safety profile turned on. You assemble all of that visually in Studio, or you describe it to the builder assistant and it lays it out for you.

Now let's walk through what each part buys you.

#Capabilities are the toolbox

Each capability is a set of tools the agents can call. You give the coordinator read-only file tools plus the ability to spawn workers, and you give the explorer file and shell access. Same workspace, same working memory, shared between both. You pick these with checkboxes, not code.

#The coding safety profile is where the guardrails live

This is the part that actually reproduces Claude Code's "won't edit what it hasn't read" behaviour, and it's more than a single guard. The coding profile bundles a whole set of rules: edit only what's been read this session, write a plan before non-trivial work, block an obviously destructive command like rm -rf outright, nudge the agent toward the real file tools instead of raw shell, and cap repeating the same tool call too many times in a row. One switch turns all of it on.

#Spawning workers is the dispatcher

This is what lets the coordinator hand work off to the explorer. The coordinator asks a worker to do a focused job ("find all callers of foo()"), the worker runs its own turn against its own cheaper model, and its findings come back into the coordinator's context. That is the whole multi-agent trick, and it is a built-in capability, not something you wire by hand.

#A model per agent, where the cost story lives

The coordinator runs on a strong model, full context, long outputs. That's where the actual code gets written, so quality has to be good. The explorer runs on a cheap, fast model, 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. Running the strong model on every turn costs roughly the same as a Claude Code subscription. Offloading exploration to a cheap model trims a meaningful chunk off that on realistic workloads, because exploration is most of the LLM time.

Numbers above are normalised against a strong-model-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 the cheap 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. Strong-model tokens go only to the steps that actually need them.

#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. The coding profile 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. The profile blocks an obviously destructive command (an rm -rf, for instance) outright rather than letting it run, and separately nudges the agent away from raw shell for routine file reads and edits, toward the real file 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. A per-read size cap keeps that in check.

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 profile 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. Pinning the goal on the first message keeps it at the top of every subsequent turn, even after compaction.

#Getting it running in five minutes

1. Open Studio in your browser, nothing to install.
2. Ask the builder assistant for a multi-agent coding assistant with a coordinator and an explorer worker, or install the ready-made digitorn-code from the Hub.
3. Pick a strong model for the coordinator and a cheap one for the explorer, or bring your own key.
4. Point it at a project and start working.

You get a coding agent that knows about your project, can read and write files, run tests, and spawn an explorer worker when it needs to. Same loop as Claude Code. Your models. No code.

If you'd rather not start from scratch, the Digitorn Hub already ships a polished version called digitorn-code under developer tools. One click 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 you reproduce 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. Pick any supported model in Studio, or bring your own key. 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 code-as-config, you build agents by writing Python. On Digitorn the builder assistant assembles 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 but leans on hand-written config. Continue is an editor extension. The thing specific to Digitorn is the visual, no-code build plus built-in multi-agent.

Does it work with local models? Yes, as long as your model has an OpenAI-compatible endpoint. Point the agent at a local Ollama or vLLM server and it runs against your own model. 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? Publish it to the Digitorn Hub. Your teammate installs it in one click and they have it, ready to run in their own workspace.

#A few links if you want to keep going

• 🚀 Open Studio and build the agent above
• 📚 The docs, where every capability 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? Publish it to the Hub. That's how the ecosystem grows.