Context branching: a developer's guide to isolated LLM threads
Git branches, but for AI conversations. The mental model, the mechanics, and the four patterns that make it pay for itself.
Key takeaway
Context branching is a conversation structure where each new AI thread inherits only the context of the node it branches from — never the whole history. It's the difference between git branches and one giant shared commit log.
The mental model: git for conversations
You already know this pattern. You would never build Feature A and Feature B by committing both to the same branch, in alternating commits, and hoping nothing conflicts. Yet that is exactly what linear AI chat asks you to do: one shared history where every task, tangent, and failed attempt piles onto the same log.
Context branching applies the git model to LLM conversations:
- Root — your shared foundation: the serialized codebase, your constraints, your system prompt. Every branch sees it.
- Branch — an isolated thread that inherits the root plus its own prompts. Nothing else.
- Merge — you do the merging, by copying the winning output into your actual codebase.
- Delete — a branch that goes nowhere gets pruned. Its cost and its confusion end with it.
How it works mechanically
When you send a prompt inside a branch, the model receives exactly two things: the root context, and the chain of messages along that branch — from root to the node you're on. Sibling branches, abandoned experiments, and deleted threads are simply not part of the request. There is no “ignore the above” because there is no “above” to ignore.
This also makes costs predictable. You pay for the root plus one branch — not for a ten-thousand-token history of things you no longer care about.
Four patterns that pay for themselves
1. Feature branches
Anchor your codebase at the root. Pull one branch for the auth refactor, another for webhook idempotency. Each conversation stays sharply on-topic because nothing else exists inside it. This is the fix for context pollution.
2. Model bake-offs
Branch the same prompt to ChatGPT, Claude, and Gemini simultaneously. Same context, same input — so differences in output are differences in the models, not in your setup. Full parallel-LLM method here.
3. Idea forks
Not sure whether to use queues or webhooks? Branch both approaches from the same node. Explore each properly, then prune the loser. Your main thread never sees the rejected design.
4. Deep-dive pruning
Explored a rabbit hole 14 prompts deep and it went nowhere? In linear chat, that history follows you forever. On a canvas, you delete the branch and your context is exactly as clean as before you started.
A worked example
Root: codebase_dump.txt — 214 files, serialized. Branch A: “Refactor auth to use refresh tokens.” Eleven prompts, lands cleanly. Branch B: “Add idempotent webhook retries.” Six prompts, also clean. Branch C: a CSS tangent that went nowhere — pruned.
Final state: two production-ready solutions, zero cross-contamination, and a workspace that contains exactly what worked. In a linear chat, the same session would be one 40-message history where the webhook code keeps accidentally importing auth middleware.
When branching is overkill
Quick one-offs — “what does this regex do” — don't need a canvas. Branching pays off when conversations get long, when tasks run in parallel, or when the cost of a wrong answer is high. Think of it like git: you don't branch to fix a typo; you branch when the work matters.
The checklist
- Anchor shared context (codebase, constraints) at a root
- One branch per feature, experiment, or model
- Never let a dead end survive — prune it
- Copy winning output into your real codebase yourself
- Re-anchor the root when the codebase meaningfully changes
Written by Roman Abashin
Founder of Alyph
Roman spends roughly $2,000/month building software with LLMs and built Alyph to fix the context problems he kept hitting. Why he built Alyph →
See it on the canvas
Reading about branching is one thing. Watching a dead end disappear from your context is another.
Try the Demo