[FEATURE] Reduce Auto mode stage-2 classifier latency with a bounded decision contract

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Auto mode's second-stage safety review can add material latency to routine work even when its prompt prefix is warm in the prompt cache.

In a content-free seven-day trace from Claude Code 2.1.220, I observed 5,814 inferred stage-2 calls. Of those, 3,510 (60.37%) landed in the 10-second-or-longer buckets, including 112 at 30 seconds or longer. Stage 1 was already fast: 15,158 of 16,065 inferred stage-1 calls completed under two seconds.

Generated output length was the strongest measured correlate of stage-2 latency (Spearman 0.805861 against ordered latency bucket). Cache-read size was weakly correlated (Spearman 0.042959), and all measured stage-2 calls had zero cache-creation tokens with a median 82,997 cache-read tokens.

This is an observational trace, not proof that output length alone causes latency. Harder cases may both reason longer and emit more tokens. The telemetry also does not reveal how reported output tokens divide between hidden reasoning and returned decision text.

Each slow classifier round trip interrupts the interactive loop before the pending action executes. The result is substantial workflow friction in Auto mode without evidence that the two-stage safety boundary itself should be weakened.

Proposed Solution

Please A/B test a bounded, structured stage-2 decision contract while preserving the existing two-stage safety boundary.

The experiment should:

1. Return a compact schema containing only the fields Claude Code needs to enforce the decision.
2. Test bounded or ambiguity-aware internal reasoning budgets rather than truncating a response in flight.
3. Export first-class content-free telemetry: classifier stage, paired decision ID, exact duration_ms, served model, categorical outcome, input/cache/output token counts, and error kind.
4. Evaluate identical replay inputs against the current path, broken out by protected action class rather than aggregate allow rate.
5. Roll back automatically on any safety, decision-stability, timeout, or error-rate regression.

Suggested safety gate: zero regression on hard-deny cases and protected external sends, destructive/process-control actions, credential handling, remote git actions, settings/self-modification, and approval provenance.

This request is not asking to raise the stage-1 threshold, weaken permissions, or truncate live classifier responses.

Alternative Solutions

I considered local threshold changes, permission exemptions, client-side output caps, and classifier-model rerouting.

I rejected threshold and permission changes because they alter the safety boundary. I rejected client-side caps because they can cut off the final verdict. The production trace used a local classifier-only Haiku 4.5 rewrite, while current documentation says Auto mode normally uses Sonnet 5 or another server-configured model, so the numerical distribution is not a clean benchmark of unmodified defaults and does not establish a preferred model route.

A paired owner-side benchmark on identical stage-2 inputs is the appropriate way to compare model routes.

Priority

High - Significant impact on productivity

Feature Category

Performance and speed

Use Case Example

1. Claude prepares a shell or network action while Auto mode is active.
2. The first-stage classifier escalates the action for the context-aware second-stage review.
3. The second-stage call reuses a large cached transcript prefix but emits hundreds or thousands of output tokens.
4. The interactive loop waits 10-30+ seconds before the action can execute.
5. A compact, structured decision path returns the same safety verdict materially faster, while ambiguous boundary cases retain a larger reasoning budget.

Additional Context

Measurement window: [2026-07-20T21:15:00Z, 2026-07-27T21:15:00Z).

Privacy: the trace stores timestamps, latency buckets, served model, request-size bucket, HTTP/usage status, token counts, plan-approval state, and categorical verdict only. It does not persist prompts, commands, tool arguments, file paths, response reasoning, credentials, or raw API bodies.

Stage identity was inferred from token signatures confirmed against the installed 2.1.220 executable: uncached-input tail 60 for stage 1 and 100 for stage 2. Twenty-eight outlier-tail events were excluded from stage-rate inference.

Latency was bucketed, so reported request-seconds are conservative lower bounds. The production trace's local Haiku 4.5 rewrite is an explicit model-routing confound. A small official-path probe did not elicit stage 2 and is not presented as a model benchmark.

Official documentation already notes that every classifier check adds a round trip and token usage, and that autoMode.classifyAllShell trades latency for coverage. I found no existing open issue specifically covering slow internal stage-2 / xml_s2 classifier latency.