Quanta

← Back to Briefings

Put a Haiku-Class Filter Before Your Flagship

Flagship modelsEN232 reads

A first-pass filter should answer one narrow question: does this request need the flagship? For sustained engineering and operations workloads, build that decision as an explicit routing stage, not an invitation for a smaller model to attempt everything. Anthropic describes routing as a useful pattern when requests fall into distinct categories that can be classified accurately.

01 · Step 1: Define What the Filter May Decide

Start with an incoming support queue, build-log stream, or document pipeline. Give the filter a bounded job: label the request, extract relevant identifiers, and select a route. Keep execution permissions outside its remit. Anthropic’s routing pattern separates classification from the specialized processing that follows.

For example, use Claude Haiku 4.5 for the first pass and configure Claude Opus 5.5 as the flagship destination. Treat this pairing as a candidate architecture to evaluate, not a guarantee of lower cost or equivalent quality.

02 · Step 2: Separate Routine Routing From Consequential Decisions

Create three routes: routine processing, flagship analysis, and human review. Allow routine processing only for explicitly approved categories, such as extracting a build identifier or matching a known error signature. Send ambiguous diagnoses to the flagship. Require human approval for production changes, access decisions, or other consequential actions.

Keep the initial taxonomy small. Anthropic specifically identifies routing easy, common requests to smaller models and difficult, unusual requests to more capable models as an application of this pattern. Your evaluation must establish where that boundary belongs for your workload.

03 · Step 3: Make the Routing Response Machine-Checkable

Request a compact structured response containing a route, category, evidence references, and escalation reason. Validate it in application code before acting. Reject unknown categories, missing fields, and references that do not exist in the input.

  • › Routine: An approved category with all required evidence present.
  • › Flagship: Ambiguity, unfamiliar patterns, conflicting evidence, or insufficient context.
  • › Human: A policy-defined approval requirement.

Do not accept a self-reported confidence score as proof of correctness. Instead, define measurable routing criteria and test them against labeled examples. On malformed output or a filter timeout, use a predetermined fallback: flagship analysis for ordinary requests, or human review where policy requires it.

04 · Step 4: Preserve Evidence Across the Handoff

Pass the flagship the original request, relevant source material, and the filter’s routing metadata. Present the filter’s summary as an intermediate interpretation, not authoritative evidence. This makes it possible to inspect what the filter omitted without reconstructing the request from logs.

Explicitly distinguish trusted instructions from untrusted documents, tickets, and tool results. Anthropic’s guidance warns that third-party content can contain adversarial instructions and recommends telling the model not to let that content override trusted instructions.

Enforce authorization in application code regardless of the selected route. Model behavior is not a security control; Anthropic’s deployment guidance recommends limiting tools and requiring approvals for risky actions.

05 · Step 5: Measure Both Calls, Including Cache Activity

Use Quanta as the metering layer while testing this architecture. Its pay-as-you-go relay gives teams one balance across supported models, with calls metered on real tokens and cache writes and reads priced separately. Keep routing logic in your application so you can revise policy independently of the relay.

Compare total filter spend plus escalated flagship spend against a flagship-only baseline on the same workload. Include retries, duplicated context, cache activity, and operational overhead. Measure end-to-end latency separately for routine and escalated requests; do not assume adding a stage makes every request faster.

06 · Step 6: Test Missed Escalations Before Going Live

Build a labeled evaluation set from representative requests, including incomplete logs, contradictory tickets, unfamiliar failures, and embedded malicious instructions. Run the filter in shadow mode while the existing workflow remains authoritative. Track missed escalations, unnecessary escalations, invalid responses, and downstream task quality.

07 · Step 7: Expand Only the Categories That Earn Trust

Enable routine handling one category at a time, retain a rollback switch, and periodically review sampled decisions. Reevaluate after prompt, model, or workload changes. Open a Quanta account to test the two-stage workflow against your own flagship-only baseline. Keep the filter only where measured savings justify its added complexity without weakening your quality or approval requirements.