Anthropic Cut Their System Prompt by 80%. Does That Work for Small Models Too? | Antigma
Skip to main content<br>We just open sourced a tiny GPT-style cognitive core built in pure Rust.See our repository→
Anthropic recently removed ~80% of Claude Code's system prompt for their newest models.
It is quite intuitive that as models get smarter, they need less direction, fewer constraints, and fewer examples — past a certain capability level, the examples stop helping and start boxing the model in.
What's interesting is that we believe those changes are backed by data — but only for Anthropic's latest models. The obvious follow-up question: does the result survive going down-market? Small, fast, cheap models are exactly the ones you'd expect to depend on detailed hand-holding. Cut their prompt in half and conventional wisdom says they fall over.
We ran the experiment so you don't have to.
The setup
Our agent, Ante, ships a --short-prompt mode: a consolidated system prompt (~5.0k → ~2.3k chars) plus shortened tool descriptions, cutting the full per-request prompt roughly in half — from ~34k to ~18k characters.
We A/B tested it on terminal-bench 2.1 , the full 89-task suite, with deepseek-v4-flash — a genuinely small, fast, cheap model, about as far from frontier as agents get deployed in practice.
Everything else held constant: same agent build, same pinned dataset digest, same sandbox pool, same effort level, same flags. The two runs differ by exactly one CLI flag.
The results
Comparison of long-prompt and short-prompt benchmark resultsMeasureLong prompt~5.0k charactersShort prompt~2.3k charactersMean rewardfull 89-task suite0.5730.596Tasks passedfull 89-task suite51 / 8953 / 89Agent errorsfull 89-task suite1111Run costfull 89-task suite$4.25$4.18Input tokens69-task same-outcome subset · median509,498346,40932% lower<br>The token comparison excludes the 20 tasks whose pass/fail outcome changed, then compares the two independent medians.
Performance: parity. The short prompt actually scored +2.3 points higher, but with one attempt per task that's inside the noise floor — the honest read is "no measurable difference." Error counts were identical.
Input tokens: 32% lower in the same-outcome subset. Twenty tasks changed pass/fail outcome between runs, which also changed how long those agents worked and made their token counts poor like-for-like comparisons. We exclude those 20 tasks, leaving the 69 whose outcome stayed the same, then compare the two independent medians: 509,498 input tokens with the long prompt versus 346,409 with the short prompt. That's 32% lower. This is a deliberately selected subset, not a whole-suite cost estimate.
The aggregate input-token totals across all 89 tasks are nearly flat, and that's worth being honest about: conversation history dominates input usage, and a few tasks where the short-prompt run took a longer solution path swamp the per-request savings in the sum. Run cost likewise changed only slightly, from 4.25to4.25 to 4.25to4.18.
What we watched for and didn't find: a capability cliff. Twenty tasks flipped outcomes between the runs — 11 newly passed, 9 newly failed — but that churn is characteristic single-attempt variance on this benchmark, not a pattern. No task category collapsed. On tasks both runs solved, the short-prompt agent even used slightly fewer steps (886 vs 911).
The takeaway
So, for this model at least: yes. We cut the prompt in half, measured nothing worse, and in the 69-task same-outcome subset the short-prompt run's median input-token count was about a third lower.
That's not the result we expected. The long prompt was written on the theory that a small model needs more instruction than a frontier one. Apparently not — or at least, not this one. Prompt text like ours accumulates as patches for the failure modes of models that are two or three generations gone, and nobody goes back to delete any of it. It never shows up as a problem. It just quietly costs money on every request until someone runs the A/B.
This is one experiment: one model, one benchmark, one attempt per task. The 32% token result comes from a selected same-outcome subset, and the run-to-run task churn shows why multi-attempt validation matters. A ±5pt noise floor means a small regression could still be hiding in there, so we'd run multi-attempt before flipping any default. And what you can safely delete is generic process instruction — task-critical context is a different thing entirely.
But the direction is clear, and it matches what Anthropic found one tier up: when a new model generation lands, your first move shouldn't be adding to your prompt. It should be deleting.
The setup<br>The results<br>The takeaway