Every request you send Claude Code looks the same at the API: tokens in, tokens out. But in your project, every request is a different job. One wants a two-line answer. One wants a careful bug fix. One is a new feature that needs a spec first. One is a brainstorm that will burn an hour and leave no code at all.
Running them through the same lane is the most expensive habit I've seen teams keep. A quick question turns into a four-file refactor because nothing told the model to stop at "just answer the question." A bug fix drifts into a cleanup nobody asked for. You see it in the token bill at the end of the month.
The fix takes ninety seconds. You do it in your head before any work starts: pick the lane, pick the model, decide if this one needs a spec. Then begin.
The ten lanes
Straight from the project's CLAUDE.md — the file every session reads first:
| Class | Trigger | Action | Model |
|---|---|---|---|
| Q Quick question | "what", "explain", "how does", "why" | Answer directly | haiku |
| B Bug | "error", "crash", "doesn't work", "fix" | Diagnose → fix → verify → DEVLOG | sonnet |
| S Small feature | < 3 files, < 1h | Verify spec exists → implement → DEVLOG | sonnet |
| L Large feature | new screen/service, > 3 files | Suggest Opus → full spec+plan+tasks cycle | opus |
| R Refactor | "refactor", "clean", "extract" | Analyze → propose → implement | sonnet |
| T Testing/QA | "test", "QA", "UX", "analyze" | Run the tester skill | sonnet |
| D Discovery | "brainstorm", "design", "ideas", "how should we" | Suggest Opus → brainstorm skill | opus |
| M Memory | "what did we", "status", "where are we" | Read memory/ → answer |
haiku |
| O Observer | "optimize agents", "improve workflow" | Chain-health audit | sonnet |
| E Expert | "review", "second opinion", "pre-ship check" | Expert subagent + domain capsule | sonnet |
That table sits at the top of a protocol file every session loads before the first reply. The classifying happens quietly — what you see is just the lane's action, not its name. But the routing underneath is fixed.
Each lane does one job well. The letter on the bay tells the worker which pattern to follow — same input, ten different outcomes depending on where it lands.
Why ten and not three
Most frameworks I've read squeeze this into three lanes: question / task / big-task. That shortcut is where it falls apart.
Q and B need to stay apart. A quick question wants the shortest answer that clears up the confusion. A bug wants a repro, a root cause, a fix, a verification, and a line in the DEVLOG. Mash them together and Haiku gets handed the bug (slow and risky), while Sonnet gets handed the question (expensive and too wordy).
L and D need to stay apart. A large feature arrives with a destination — "ship the booking flow." A discovery arrives with none — "how should we approach bookings?" The feature lane runs spec → plan → tasks → build. The discovery lane runs brainstorm → spec draft → human decision → then maybe a build. Mash them and you'll get premature code for a question that was still open.
E only shows up if you built the mechanism. The expert lane loads a domain cheat-sheet for your kind of project and reviews against it. If you don't have the cheat-sheet or the subagent, this lane doesn't fire — the request falls back to R or T. If you're starting fresh you can skip E for weeks and lose nothing.
The number isn't for show. Every lane earns its row because the lanes next to it would do the job worse.
Model per lane
The model column is the second half of the pattern, and the one that most directly moves the token bill.
[MetricGrid — see full post]
Haiku on Q and M saves ninety percent on every "what does this file do" and every "where are we on sprint 14." Those are the most frequent lanes by count — pushing them to the cheapest model is the single biggest cost lever in the whole protocol.
Opus on L and D is the opposite move. A deliberate step up to a smarter model when the output will stick around for months — the spec, the plan, the brainstorm transcript. Those documents outlive the session. Paying Opus prices for them is cheaper than paying Sonnet to write a weak spec that turns into three weeks of rework.
Sonnet in the middle is the general lane. It's where most of the keyboard time happens.
The spec gate
The classification feeds one more decision: does this lane need a spec before any file gets touched?
Two lanes do: L and D. Both say it out loud in the table — "full spec+plan+tasks cycle" / "brainstorm → spec draft." Nothing in those lanes gets built until a specs/<N>-<slug>/ folder has three signed-off documents inside it.
Every other lane skips the gate. A quick question doesn't need a spec. A bug fix doesn't need a spec — it needs a diagnosis and a DEVLOG line. A refactor needs a quick proposal in chat, not a sprint folder.
The gate fires only on the heavy lanes because applying it everywhere would be deadly. Picture opening a spec folder for every "what does useEffect do" — the overhead would eat the project. The point is: the discipline matches the weight of the lane.
The lane I keep getting wrong
D (Discovery) and Q (Quick question). These two look nearly the same in the wild and want opposite things.
"How should we approach caching?" sounds like a question. It isn't. It's a discovery — the honest answer wants trade-offs, not a definition.
"What does cache invalidation mean?" sounds similar. It is a question — the honest answer is three sentences and a link.
The signs look the same from a distance. The tell is the walk — one is a short straight path with a bench at the end; the other winds for an hour.
The tell is what the right answer looks like. If the honest answer starts with "it depends on your constraints — tell me about…", you're in D. If it starts with "it's X, which does Y," you're in Q. The question I ask myself: does this want a conversation, or does it want an answer?
Get this one wrong in the D direction and you lose an hour. Get it wrong in the Q direction and you lose a day — because the model is now drafting a spec for a feature you didn't actually want to build.
What this fixes
Across the seven projects on /tools, one pattern held up:
[MetricGrid — see full post]
Roughly ten times less rework when the classifying is in place. That ten-times gap held across every project size I tried — Flutter mobile apps, Next.js SaaS, backend pipelines. The thing that moved the number wasn't the model, wasn't the stack. It was those ninety seconds before each request.
Same tools, same wood, same carpenter. The only difference between the two rooms is whether someone sorted the orders before cutting began.
Time-to-ship moved the opposite way from what it felt like. Projects that classified every incoming request shipped sooner than projects that started typing on request one. The classifying time doesn't feel like progress in the moment — nothing is being built — which is exactly why it was the first discipline to drop whenever I let it. The scorecard made that gap visible.
How to adopt
Shortest path: steal the table.
Open your project's CLAUDE.md, paste the ten lanes word for word, and run the next twenty requests through it in your head. Nothing else changes. No subagents, no spec folders, no new files. Just the one question which lane is this? before every reply. You'll start noticing which lanes you were mixing up.
Full path: install the protocol.
curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash
That installs the classifier, the five entry-point skills, the spec+plan+tasks scaffolding, and the scorecard that measures whether you're actually following the lanes you set. MIT, no sign-up, no telemetry. Repo: github.com/ruslan4427/claude-shiploop. The install script merges into your existing CLAUDE.md without overwriting what's there.
The scorecard that produced the rework-ratio numbers lives at /tools. Seven of my own projects, three tiers, five metrics each. Three of them show — in the tokens column because the data isn't there to count from. That blank is a deliberate rule — the scorecard refuses to guess at numbers it can't measure.
A full write-up of the launch, the install flow, and the "null is honest" rule sits at /blog/shipping-claude-shiploop.
The classifier itself takes ninety seconds per request to run. That's the whole ask. Everything else sits downstream of that one habit.
