Routing Problems to Tools

Contents

0The front door

Ask these in order. The first one that answers yes names the surface. Stop there.

WHAT KIND OF WORK IS THIS?

1. Does it need to read the repo, run a build, or be verified?
   └─ yes ──────────────────────→ CLAUDE CODE            §1 → model §3

2. Is the thinking the product, rather than a file?
   └─ yes ──────────────────────→ CLAUDE BROWSER         §2 → model §4

3. Does the question need several genuinely different
   viewpoints held against each other?
   └─ yes ──────────────────────→ EXPERTS MEETING        §5

4. Is the output visual, and must it inherit the
   project's design vocabulary?
   └─ yes ──────────────────────→ MOCKUP LAB             §6
   └─ visual, no vocabulary ────→ browser artifact       §6

5. Is it one judgment applied to many items, where you
   need a number you can set a threshold on?
   └─ yes ──────────────────────→ JEV                    §7

6. Does Claude structurally lack the capability?
   └─ yes ──────────────────────→ CHATGPT                §8

The discriminators, stated plainly

1Claude Code

Claude Code is the only surface with your filesystem, your build, and your git history. That makes the selection rule mostly mechanical: work that ends in a changed file belongs here, and work that does not usually belongs somewhere else.

Signals that select it

• The answer is a diff. Features, fixes, refactors, migrations, test writing.
• The question is about what the code actually does. Reading across subsystem boundaries, tracing a call path, confirming that a blueprint still matches the source. The agent brief that fed this document is an example: thirty-eight agent definitions and six meeting formats counted from the files, not from memory.
• Verification is part of the deliverable. Build, run, diff, grep for remaining imports.
• The work is long and stateful. Many steps over many files, where losing context between steps would be expensive.

Signals that it is the wrong surface

• You want to be argued with. Code will engage, and it will also start implementing the thing you were still deciding about.
• The repo is irrelevant to the question. Paying for repo context you do not use is the cheapest mistake on this list, and the most frequent.
• The output is prose for a human with no file destination. Possible here, better in the browser.

2Claude browser

The browser is for work where the exchange itself is what you are after. No filesystem is a feature here, because nothing pulls the conversation toward editing.

Signals that select it

• You are deciding, not building. Product direction, whether a feature should exist, how to frame something for the husband-onboarding guides.
• You want sustained back-and-forth on one idea. Ten turns of refinement on a concept, where each turn depends on your reaction to the last.
• The artifact is standalone. A visual explainer, a one-off page, something that never needs to know Code Raven exists.
• Writing where voice matters more than structure. Corpus prose, guide narrative, anything editorial.

The handoff seams that already exist

Browser work does not have to end in the browser. Three routes back into the pipeline are already built:

• Mockup import. MockupImportSheet takes HTML from a claude.ai artifact and opens it as a Mockup Lab session or appends it as a revision.
• Corpus context. CopyPromptPreviewSheet is the single seam that carries project context out to a browser conversation.
• Off-site meetings. The .offsite meeting format exists specifically for a conversation held on Claude or ChatGPT elsewhere and pasted back through Code Raven Mobile. It arrives already concluded, so it costs no CLI turns and still lands in the Chronicle.

3Model choice — Claude Code

This question has two separate answers, because two separate things pick the model and only one of them is under your control at the moment.

A. Your interactive sessions

Your global default is opus[1m]. For this codebase that is the right resting position, and the 1M context is doing real work: Code Raven is large enough that cross-subsystem questions routinely pull in a dozen files.

Relative costs are first-party API per-token rates normalized to Opus 5 input ($5/MTok in, $25/MTok out). On a subscription the currency is rate-limit consumption rather than dollars, and the ratios move together closely enough to use the same ordering. I do not know your plan's specific limits and have not guessed at them.

/fast is orthogonal to all of this. It runs Opus with faster output and does not substitute a smaller model, so it costs more per token and buys wall-clock.

B. Code Raven's own subsystem calls

Three call sites do choose, and they are the exceptions that prove it:

• ResponseRestructureService — Haiku preferred, Sonnet fallback, on its own 90-second timeout
• IntelligentPlanParser — Haiku
• SmartCheckpointParser — Haiku

The practical consequence: today, per-subsystem model choice is not a decision you can make. Changing the global default moves all of it at once, including a nine-seat Rookery sitting and every mockup revision. That is a design question worth having separately, and it is in section 11.

4Model choice — Claude browser

The browser picker matters less than the Code picker, because browser work is usually one conversation rather than forty tool-driven turns, so the cost spread is smaller in absolute terms.

Turn extended thinking on for anything where you would be annoyed by a confidently wrong answer, and off when you are drafting and want the turns to come back quickly.

5When to hold an Experts Meeting

An Experts Meeting is the most expensive thing on this list by a wide margin, and the criterion that justifies it is narrow.

What it costs

A standup runs a default 18-turn budget. Each expert turn is a CLI invocation with maxTurns: 2, on that expert's own resumed session. Mira intervenes every fourth expert turn up to four times, and her turns do not consume the budget. Conclusion adds a summary and a handoff generation. That lands at roughly forty to fifty model turns for one meeting, each carrying its own accumulated session. Wall-clock is not recorded anywhere in the codebase, so I have not estimated it; the scripted pacing alone adds three to eight seconds per turn before any model latency.

Signals that select it

• The question maps onto one of the five intents. How does this feel to use; what should we build and how well; are we staying true to what this product is; are we on track; how does this stand in the landscape.
• You expect the room to split. Scoping against ambition, accessibility against density, ship-now against get-it-right.
• You want the living document. Mira is the sole editor of docs/meetings/<date> - <topic>.md, and that file is a real deliverable.
• You want the handoff. The conclusion routes into the Note to Plan pipeline with action items and dissents preserved.

Signals that it is the wrong call

• You already know what you think and want confirmation. The room will supply it, expensively.
• The question is factual. Experts do not read your code. Claude Code does.
• One expert would do. Run a consultation at 10 turns, or take it to the browser and record it as an off-site.

6Mockup Lab vs Claude browser

These produce the same artifact type, a self-contained HTML page. They differ in what the page already knows.

What Mockup Lab injects

MockupFoundationBridge passes three of the nine Foundation layers into every generation:

• Visual Design — a :root block of CSS custom properties, the full palette with usage notes, the type scale, spacing base unit and scale, border-radius and shadow treatment, and the named visual anti-patterns to avoid
• UI/UX — interaction principles and what to measure
• Character — experience philosophy, traits, voice principles

Mission, personas, code, features, cognitive, and presence are not injected. A mockup therefore knows how the product should look and feel, and does not know who it is for. That gap is worth remembering when a Lab mockup comes back beautifully consistent and slightly beside the point.

Choosing between them

Mockup Lab is also the one caller in the whole app that streams (streamJSON: true), so it is the only subsystem where you watch the work arrive rather than waiting for a blob.

7When to use Jev over Claude

Jev (jev-1.13.0, TypeSafe) is a System One model. It takes a state and a map of typed questions, evaluates every question in parallel in a single request, and returns typed answers with calibrated probabilities. It generates no text.

The three question types

Signals that select it

• Volume with a fixed rubric. The Peregrine pass covers 439 items at about 237 tokens of state each. It costs roughly four cents and runs in under two minutes.
• You want to re-run after every rubric edit. At $0.042 per million input tokens with output free, iteration is effectively unbilled. That is what converts calibration from an intention into a practice.
• The output feeds a gate. A confident failure routes onward automatically; an uncertain read routes to a human.

Where it does not apply

• Anything arithmetic. TypeSafe's own limitations page says it is not a calculator and does not count reliably. It cannot check that x = 10 follows from (x + 6) / 2 = 8. The 130 math items in the Peregrine bank are scoped out for exactly this reason.
• Anything generative. No rewrite, no explanation, no suggestion. It answers questions you wrote; it does not tell you which questions to write.
• Small n. Below roughly fifty items the state-builder and rubric setup cost more of your time than the judgments are worth, and one Claude pass is simpler.
• Dimensions with no ground truth. A Score threshold you cannot calibrate against anything is a number with a decimal point and no meaning. Engagement in the Peregrine plan is marked advisory for this reason.

8When to use ChatGPT over Claude

You named three uses: factual questions, second opinions, and visual creation. They have different strengths as criteria, and it is worth separating them.

Image generation — a capability gap

clear rule Claude does not generate images on any surface. This is not a quality comparison. When the deliverable is a generated image, ChatGPT is the tool, and there is nothing to weigh.

Second opinion — a real mechanism, with a condition

clear rule A different model has uncorrelated failure modes, so a second read catches errors that a second Claude turn would reproduce. The value is real and it depends on one condition: ask cold. Pasting Claude's answer and asking whether it is right anchors the response and converts an independent check into an agreement check. Ask the original question, then compare.

Factual lookup — a habit worth testing

softer Both models search the web and both cite. The split you describe, ChatGPT for facts and Claude for opinions and collaboration, may be tracking a genuine difference in how each presents a sourced answer, or it may be tracking interface familiarity. I cannot tell from here, and I would rather say so than manufacture a criterion.

A way to find out, if it interests you: next time you reach for ChatGPT on a factual question, ask both, and note which one you actually acted on. Three or four instances will settle it. Until then, treat it as a working preference that is cheap to honor.

9Cost shape

Two rankings, because they disagree. The first ignores budget entirely. The second assumes you are three weeks into a cycle and watching limits.

Per-token reference

First-party API rates. Your Claude Code and browser usage bills against a subscription rather than per token, so read these as relative expense and as the shape that rate-limit consumption follows.

10Where the criteria collide

Four places where two rules in this document point in different directions. Judgment has to resolve these, and naming them is more useful than pretending the flowchart handles everything.

Repo access against thinking quality

A decision that depends on what the code actually does needs both. The resolution is sequence rather than choice: use Claude Code to establish the facts, carry the findings to the browser to decide, come back to Code to implement. The brief behind this document followed exactly that shape.

Foundation vocabulary against genuine exploration

When you want a new direction that still has to fit the product, both section 6 rules fire. Start in the browser without tokens, then import the result into the Lab and let a revision pass pull it toward the vocabulary. The order matters: Lab first anchors you to what exists.

Meeting cost against meeting value

The sharpest tension in the framework. Forty-five model turns is a lot to spend on a question you might resolve in one browser thread, and the meeting's distinctive output, preserved dissent and a living document, is genuinely unavailable elsewhere. A usable tie-breaker: if you can predict what each expert will say, you do not need the meeting.

Jev's calibration against its blind spots

Jev gives you a number, and a number invites a threshold whether or not the dimension supports one. Score confidence is derived from distribution concentration, which is a statement about the model's certainty rather than about correctness. On dimensions with no ground truth to calibrate against, treat the number as advisory and say so in the artifact, the way the Peregrine plan marks engagement.

11Two findings, separable from this framework

Both surfaced while confirming section 3. Neither depends on anything in this document, and both are worth handling on their own.

12Integration, deferred

You asked for this as a review document first, so this section is a sketch of where it could attach rather than a proposal. Nothing here is decided.

• As a guide. docs/guides/ already holds the onboarding drip and syncs to the mobile workbench. Lowest-effort home, reference-only, no code.
• As a Quick Task field. A routing hint on task creation, suggesting a surface from the task text. Useful and small, and wrong suggestions would be annoying in proportion to how confident they look.
• As a Foundation layer. A tenth layer describing working practice rather than product. This would let other subsystems consult it, and it is the largest of the three.

The question that decides between them is whether you want the framework to be something you read or something the app acts on.

13Final review

What this solution does well

• The triage sequence orders questions by how decisive they are. The filesystem boundary is mechanical and resolves most work immediately, so the harder judgment calls only come up when they have to.
• The criteria are grounded in what the code actually does rather than in how the subsystems are described. Turn budgets, the three injected Foundation layers, the missing --model flag, and the [silent] ambiguity are all read from source.
• Splitting cost-blind from cost-aware rankings exposes the four places they disagree, which is where a routing document usually hides its assumptions.
• Section 2's handoff seams give the framework an escape valve. Browser work reaching the pipeline through off-site meetings and mockup import means routing to the browser is rarely a dead end.

Where it is weak

• The meeting cost figure is a turn count, not a measured cost. Forty to forty-five model turns is derived from budgets and maxTurns ceilings. No wall-clock or token measurement exists in the codebase, and maxTurns is a ceiling rather than a typical value. The real number could be meaningfully lower.
• The subscription cost model is an inference. I used per-token API rates as a proxy for rate-limit consumption. The ordering is almost certainly right; the ratios may not be exact for your plan.
• Section 8's factual-lookup criterion is unresolved, and I left it unresolved rather than inventing a rule. That is honest and it is also the least useful section in the document.
• The five-item threshold for Jev is my estimate. "Roughly fifty items" is reasoning about setup cost, not a measured break-even.

Edge cases this framework handles poorly

• Work that changes category mid-stream. A question that starts as a decision and turns into a refactor. The sequence in section 10 covers it, and the flowchart does not.
• Press Raven corpus authoring. Editorial work with a repo underneath it sits between sections 1 and 2, and the three-tier guide-to-project ladder has routing considerations this document does not address.
• Personal workspace work. The Rookery's nineteen seats and inverted conclusion semantics are mentioned but not given their own branch. Non-code decisions have a different shape than the five intent groups assume.
• VentureRaven. The hard fork means every rule here applies twice, and the two apps' Spark dispositions are already inverted. Divergence between them is a live risk this document does not track.
• Mobile. Capture from the phone has its own constraints, and "which surface" has a different answer when you are not at the keyboard.

Adjustments worth considering

• Measure a meeting once. Time one standup end to end and record the token count from TokenUsageStore. That converts the most uncertain number in this document into a real one, and it is a single afternoon.
• Run the ChatGPT test in section 8. Three or four paired factual questions would either confirm the criterion or let you drop the section.
• Fix the UsageAggregator default before trusting any in-app cost number for routing decisions. Right now the app's own numbers would argue for the wrong routes.
• Consider whether the Rookery deserves its own branch in a v2, given how much of your thinking happens in the personal workspace.