What is the context tax?
The context tax is the cost you pay, in tokens and in output quality, for instructions a model wrote into your work without asking. I found it by accident. I had two subscriptions running — Claude Max and Z.ai — and I started getting GLM-5.2 to review the agentic systems Opus had built for me. It kept flagging the same thing. Hundreds, into the thousands, of negative instructions baked into my prompts and project files: do not do this, do not do that, this is not allowed, remove that, this is incorrect, this is wrong.
I had not written them. Opus had added them on its own, treating “ethical” as “prohibited” by default and quietly installing that policy into everything it touched. Opus 4.8 is engineered to follow instructions literally on every surface; a model that literal, asked to be safe, reaches for prohibitions the way a nervous lawyer reaches for redactions. None of it appeared in a prompt I had approved. All of it ran on every request.
Why do negative instructions hurt a literal model?
Because a literal model expends real effort obeying every single one.
A positive instruction points the model at a target. A negative instruction tells it what to avoid, which means it has to carry the prohibition in mind while it generates and check its output against it, token by token. Stack a dozen and the prose starts to hedge. Stack hundreds and the model spends more effort not-doing than doing. The research on this is newer than you would guess — instruction-following performance measurably degrades as the number of simultaneous constraints rises, the IFScale benchmark found. The canonical instruction-following evaluation, IFEval, exists precisely because adherence is a measurable axis a model can be pushed up or down. Opus is pushed up. The tax is the cost.
In my case the cost was sterile output and inflated token use, request after request, on agents I had been running for months. I had been blaming the model. The model was fine. It was drowning in constraints it never asked for either.
How do you write a positive instruction instead?
You point at what you want, give examples, and leave the door open. That is most of it.
The pattern that replaced nearly every negative instruction in my agents looks like this: state the approach in the positive, give two or three examples, then add the one negative that matters — do not be limited by these examples. That last line is the only prohibition I keep, because it stops the model treating the examples as a closed set. Everything else is “here is how we do it,” not “here is what is forbidden.” The model thinks freely inside a frame instead of threading a minefield.
This is not a trick I invented. It is plain prompt engineering, the kind the open-weight community has been writing down for two years. The reason I had not done it sooner is that no Claude model ever showed me the tax I was paying — it was the one paying it, and it was also the one writing the rules. GLM, which was not trained to install its own guardrails into my work, could see the mess plainly because it had not made it. Within a week of the cleanup my agentic output improved roughly tenfold, and my token use dropped. Roughly, not measured — I am reporting the shock of it, not a benchmark.
How do you know if your agents are paying the tax?
Hand your prompt files to a model that did not write them.
Run a frontier open model — GLM-5.2 is the obvious one right now — over your agent definitions, your system prompts, your accumulated rules. Ask it one question: which of these instructions are doing work, and which are costing me? A model with no investment in the answer will list the negatives you never wrote and tell you what each one is doing to your output. I have yet to see a long-running Claude-built agent that did not carry at least some of this cruft. The longer it has run, the more there is.
Then do the mechanical thing. Strip the negatives that do not earn their keep. Rewrite the ones that do as positive instructions. Keep one or two genuine prohibitions and word them so they cannot be over-applied. The fix is small. The payoff is not.
Is this really a sovereignty question?
It is, and that is why it belongs on this site rather than on a coding blog.
Who controls the instructions baked into your tools is the same question as who controls your keys, your data, your compute. A model that quietly wires its own prohibitions into your code is making value decisions on your behalf, at your expense, inside your own work. You would not accept a password manager that inserted its own opinions about which sites you should log into. The model you depend on is no different. The sovereignty argument I make about AI elsewhere — that the intelligence you rely on should be something you can hold, read, and edit — starts with the prompts. If you cannot see the rules, you cannot trust the output.
Open weights are how you see the rules. You can read every instruction, edit any of them, and run the result on your own hardware with no company looking over your shoulder. The context tax is the small, everyday version of the same fight the cypherpunk philosophy archive tracks across everything else on this site: the right to compute on your own terms, with tools that serve you instead of quietly governing you.
