The Problem with Signal Matching

For the past week, we've been playing whack-a-mole with Anthropic's behavioral classifier. Every time we matched a detection signal, they had another one:

• v2.8.0: Billing tag injection
• v2.8.5: Build tag algorithm + cch randomization
• v2.8.6: System prompt 3-block structure
• v2.9.0: Thinking block stripping, field scrubbing, JSON reordering
• v2.10.0: Tool name rewriting
• v2.11.0: Tool count capping

Nine signals matched. Still getting flagged on production agent traffic with 40 tools.

The fundamental problem: signal matching is reactive. Anthropic controls the classifier. They can add new signals faster than we can reverse-engineer them. We were always one step behind.

Template Replay (v3.0.0)

v3.0.0 changes the architecture entirely. Instead of transforming your request signal by signal, dario replaces the entire request with a Claude Code template.

How it works

1. Your client (OpenClaw, Hermes, Cursor, whatever) sends a request with its own tools, parameters, and structure
2. dario extracts only the conversation content (messages)
3. dario builds a completely new request using Claude Code's exact template:
   • CC's tool definitions (Bash, Read, Write, Edit, Glob, Grep, WebFetch, WebSearch, NotebookEdit, Agent, AskUserQuestion)
   • CC's field ordering
   • CC's parameters (max_tokens: 64000, effort: medium, thinking: adaptive)
   • CC's system prompt structure (3 blocks with billing tag)
   • CC's metadata (device identity, session ID)
4. The new request is sent upstream. Anthropic sees a genuine CC request.
5. When the model calls a CC tool (e.g. Bash), dario maps it back to your client's tool name in the response

Your client sees its original tool names. The translation is transparent.

Why this can't be detected

The upstream request IS a Claude Code request. Same tools. Same structure. Same parameters. The only thing that varies is the conversation content — which is what varies in real Claude Code usage too.

Anthropic would have to flag their own binary's request format to detect this. They can't add a new "signal" because there are no third-party signals left in the request.

Test Results

The scenario that broke v2.10.0 and v2.11.0:

40 third-party tools (tool_1 through tool_40)
+ effort:high
+ temperature:0.7
+ max_tokens:128000
+ non-CC field ordering

v2.10.0: overage (tool names rewritten but tool count detected)
v2.11.0: overage (tool count capped but dispatch structure detected)
v3.0.0:  five_hour (entire request replaced with CC template)

E2E suite: 12/12 pass

Haiku non-stream    five_hour
Sonnet non-stream   five_hour
Opus non-stream     five_hour
Sonnet stream       five_hour
Opus stream         five_hour
OpenAI non-stream   five_hour
OpenAI stream       five_hour
Tool use            five_hour (tool=WebSearch — CC's definition used upstream)
Rate limit headers  verified

What Changes for Users

Nothing. npm install -g @askalf/[email protected] and restart your proxy. Your tools still work. Your SDK still works. The only difference is what Anthropic sees — and what Anthropic sees is Claude Code.

If your client sends 40 tools, dario sends CC's 11. If your client sends effort: high, dario sends medium. If your client sends max_tokens: 128000, dario sends 64000. None of this is new — v2.x did the same transformations. The difference is v3.0 does it by replacement instead of modification, which eliminates edge cases and unknown signals.

The Classifier is Still There

This doesn't change what Anthropic is doing (Discussion 13). The behavioral classifier still exists. The detection signals are still active. Every Claude Code "default" is still a detection feature.

What changes is that dario no longer needs to match signals one by one. By sending CC's actual request template, we operate inside the classifier's decision boundary by definition. There is no combination of signals that can flag us without also flagging Claude Code itself.

v3.0.0 published with npm provenance. Full changelog.

npm install -g @askalf/[email protected]