Your harness is half the model
I ran four coder models through their officially-recommended harnesses and one came out 100x slower. The cause was my shell's rm -i alias leaking into Claude Code's tool subprocess. Your model comparison will credit that slowdown to the wrong variable.
I was cleaning up the scratch script I used to draft this post (one
rm /tmp/push-raw-posts.py) and the subprocess hung onremove regular file '/tmp/push-raw-posts.py'?. The exactrm -icontamination the post is about. The recursion is too clean to leave alone.
The harness is not a shell around the model
I thought the harness was a shell around the model. Type prompt, get output, done. The model writes the code, the harness is plumbing.
Running an actual benchmark with four coder-bricks through their officially-recommended harnesses disabused me of that in the worst way. MiniMax via Claude Code (MiniMax's own first-recommended path, Anthropic-compat endpoint, "just set ANTHROPIC_BASE_URL and you're done" per the docs) gave wall-time blowups of 100×. A task that should have taken 107 seconds took 10,682.
Root cause was maximally unglamorous. Claude Code's tool-use subprocess sources the parent shell's interactive snapshot. On my Fedora + prezto setup, that snapshot re-establishes alias rm='nocorrect rm -i'. Model-issued rm <existing> && cat > <same> tool calls (a very common pattern for rewriting test files) then block forever on the -i confirmation prompt. The subprocess captures stdout and stderr but doesn't route stdin back, so the prompt hangs indefinitely. --bare mode doesn't disable shell-snapshot loading. It only gates CLAUDE.md, hooks, plugin sync, and keychain reads.
The fix is an operational contract. Strip all ANTHROPIC_* env vars from the subprocess, strip CLAUDE_CODE_OAUTH_TOKEN to avoid credential leaks, set SHELL=/bin/bash, BASH_ENV=/dev/null, ENV=/dev/null, ZDOTDIR=<fresh empty dir>, and (here's the fun one) set all five ANTHROPIC_*_MODEL aliases (MODEL, DEFAULT_OPUS_MODEL, DEFAULT_SONNET_MODEL, DEFAULT_HAIKU_MODEL, SMALL_FAST_MODEL) to the same value, because Claude Code's internal Opus/Sonnet/Haiku routing otherwise breaks with "unknown model."
None of that is in the official setup guide. You find it by running your own benchmark.
Sibling surprise
Cline CLI 2.0 went headless in February 2026. I missed it by two months in my research and confidently wrote that "Cline is VS Code only, DS-via-Cline from an HL session isn't viable." It is viable. -y for yolo, --json for structured output, scoped --config dir so you don't pollute the user's IDE state. The second-biggest harness ecosystem in the Anthropic-adjacent world added headless mode and I hadn't noticed. Nobody I'd read had noticed either. The earlier writeups I'd scraped were still pitching the VS Code framing.
Two lessons, same insight
First: an official harness recommendation is where you start. The company that made the model picks the harness that shows their model at its best. They don't necessarily pick the harness that runs without contamination on your specific dev box. The gap between "vendor says works" and "actually works on my machine" is where hours go.
Second: the harness moves your numbers, and your model capability comparison will credit the movement to the wrong variable. If I'd compared MiniMax to Qwen3.6 based on wall time alone, with that 100× contamination un-caught, I'd have concluded MM is impossibly slow. It isn't. My environment was making it wait on an interactive shell prompt that should never have existed.
You catch this by running your own benchmark against your own infra. Not someone else's SWE-bench numbers or the vendor's marketing deck. Your tasks, your harness, your subprocess, your shell. That's where the operational contract writes itself.