Fast First Pass in the Terminal Before Calling Opus 5.5

Letting Claude Haiku 4.5 ship the finished patch

There is a terminal pane open next to my editor on almost every task, and the first model I call is usually the cheap one. Claude Haiku 4.5 answers before my train of thought cools, which makes it ideal for orientation: which files matter, which function owns the bug, which assumption in my question is simply wrong. The mistake is letting that speed become authority, because a fast answer about architecture is still only a fast answer.

Split the work into two explicit jobs before you type anything. Job one is orientation and drafting, and job two is judgment and correctness. I label which job a call is doing and never ask a single call to do both. That one habit has saved more review time than any prompt trick I have collected.

A few ground rules keep the fast pass honest.

• Ask Claude Haiku 4.5 for a plan, a file list, and a risk note before you ask it for code.
• Keep generated patches short and read every hunk before staging anything into your branch.
• Escalate immediately when the change spans multiple services, database schemas, or concurrency boundaries.

Dumping the whole repository into the first request

Context gluttony is the second mistake, and it costs you twice. The more you paste, the more the model has to hold, and the likelier the part that actually matters is buried under configuration it never needed. I once sent a whole repository to explain a two line change and got back a confident rewrite of a module I had not asked about.

Curate instead. Send the two files that matter, the interface they satisfy, the exact error text, and the failing test name. Pin the language and framework versions so the model stops guessing, and drop earlier turns that describe a failure you already fixed.

A relay keeps the swap cheap. With Fluxo I keep one key and one base URL, https://api.fluxorelay.com, and the same call shape reaches Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more, so trading the fast pass for a heavier model is one parameter and not a new integration.

• Send the files that own the change plus the interface they implement rather than the entire tree.
• Quote the raw compiler or test output verbatim instead of paraphrasing what you think went wrong.
• Trim stale conversation turns aggressively because old context hides the failure you are currently chasing.

Asking for prose when you needed a patch

The third mistake is accepting a description when you wanted an artifact. A vague request produces a vague answer, and because a fast model returns quickly, the vague answer arrives before your skepticism does. Describe the deliverable in mechanical terms: format, file paths, constraints, and the behaviour when the plan does not fit the codebase.

I keep a short template beside my prompt so the shape of every request is identical across days, which makes the fast pass comparable and reviewable.

• Request a unified diff with full file paths so the output drops straight into a dry run.
• Ask for the three most likely failure modes alongside the patch to seed your test list.
• State the public interfaces you cannot change so the first pass respects your existing contracts.

Skipping verification before the bigger model takes over

The fourth mistake is escalating on vibes. If you hand a bigger model a first pass you never checked, you inherit every quiet hallucination in it and add a second layer of confident prose on top. Run the tests, read the diff, and mark anything the fast model invented before anyone else looks at it.

Verification is not bureaucracy here, it is the input format for the second call. A real failure trace gives the heavy model something concrete to reason about, and it usually shortens the whole exchange.

• Run the relevant test file before escalating so the next model sees real failures and not guesses.
• Compare the first pass against your acceptance criteria and flag every claim that lacks evidence.
• Delete suggestions that pass tests but violate lint rules, naming conventions, or your error handling style.

Escalating to Claude Opus 5.5 with a cold prompt

The fifth mistake is dropping the fast pass entirely and starting over with the expensive model. You pay for the same thinking twice, and the bigger model often proposes a different shape that invalidates the work you already reviewed. Hand over context that is already compressed: the accepted plan, the rejected alternatives, the current diff, and the exact question that is still open.

Choose the heavy model for judgment calls such as API design, migrations, and concurrency reasoning. Claude Opus 5.5 earns its cost when a wrong answer takes an afternoon to unwind, and it should critique the fast pass rather than reinvent it.

• Give the big model the accepted plan, the rejected ideas, and the current diff as one coherent packet.
• Ask explicitly whether the fast pass missed a case before requesting any new code from the larger model.
• Keep the failing output verbatim in the escalation prompt to avoid another round trip of context gathering.

Missing cache reads and cache writes in the cost math

The sixth mistake is believing that a cheap model is automatically a cheap pipeline. Repeated calls with large shared context move real volume, and token accounting only makes sense when you include cache reads and cache writes alongside input and output. Fluxo is billed per real token including those cache figures, with no monthly fee, which makes the loop measurable instead of mysterious.

The same relay works from the tools I already live in, including Claude Code, Codex, Gemini CLI, and any OpenAI SDK, so the routing decision stays in a shell alias or an editor command instead of a dashboard. People you invite also earn you a referral share when they pay, which is a nice side effect of telling your team about the setup.

• Count cache reads and cache writes as real spend because they show up on your token bill.
• Reuse a stable prompt prefix so repeated calls land in cache and cost less on the read side.
• Measure cost per merged change rather than cost per call when you compare two model routes.

If you want to run this two model loop yourself, creating a Fluxo account takes a minute and works from the editor and terminal you already use. If anything here does not match what you see, leave a note on the contact page after signing in.