Five weeks ago Anthropic shipped Opus 4.6 and OpenAI shipped GPT-5.3-Codex on the same day. Sonnet 4.6 followed twelve days later, and GPT-5.4 arrived last week. I use Claude Code and Codex side by side, and every one of those releases changed something about which model I reach for and how it behaves.

None of them cost me a weekend of re-tuning, and the reason is a little embarrassing: there is not much to re-tune. My global CLAUDE.md is a page. The project one is a single line pointing at AGENTS.md. The skills and commands I keep are mostly ones I invoke by name: commit, open a pull request, review a branch.

Keeping it that small has been deliberate, but until now it was an instinct: if I build the perfect harness for the best model this month, the next model will arrive, my harness will be tuned to habits it no longer has, and I will be steering a better driver with instructions written for a worse one. Worse, I might not notice: the harness would hide what the new model can do on its own, and I would be missing out without knowing it.

Before writing that down I wanted to check it. Most of it holds up, and some of it was wrong.

The vendors say it in writing

The strongest evidence is the model providers' own migration notes, which read like a changelog of instructions that went bad.

Anthropic's prompting guide says that Opus 4.5, and now 4.6, respond to the system prompt more strongly than earlier models. Prompts written to stop older models under-using tools now make these ones over-use them, and "CRITICAL: You MUST use this tool" should become "Use this tool when". Its migration advice for the 4.6 models is to dial back anti-laziness prompting, because instructions that were needed for previous models now over-trigger.

OpenAI said the same thing in September, when GPT-5-Codex shipped. Its prompting guide told you not to treat it as a drop-in replacement for GPT-5, to follow a "less is more" approach, and to remove prompting for upfront plans and status updates, because that could make the model stop before the task was done. Codex's own system prompt for that model was much shorter than GPT-5's.

So the people who train the models make the argument themselves. "Be thorough, and always use the tool" was good advice a year ago. On this generation it is noise that the model obeys.

The vendor's harness is also re-tuned for every model they ship: Codex carries a separate prompt per model, and Claude Code changes alongside each release. Mine is not re-tuned. Anything I layer on top was tuned against a system prompt that has since been rewritten underneath me.

Even the person who built Claude Code does not build much on top of it. In a thread in January, Boris Cherny described his own setup as "surprisingly vanilla", because the product works well out of the box.

It costs something even today

The first thing my instinct got wrong was timing. I framed the risk as a future one: the harness is perfect now and decays later. The evidence says a large harness is often not helping now.

A study from ETH Zurich published last month, Evaluating AGENTS.md, ran coding agents with and without repository context files. LLM-generated files lowered task success by about 3% on average. Files the developers had written themselves raised it by about 4%. Both kinds made the agents explore, test and reason more, and raised inference cost by more than 20%. The agents did follow the instructions, which is the problem: the authors conclude that unnecessary requirements make tasks harder, and that human-written files should describe only minimal requirements.

OpenAI's write-up on harness engineering with Codex, a day before that paper, reached the same place from the other side. Their large, encyclopedic AGENTS.md crowded out the task and turned into a pile of stale rules that might or might not still be true. The fix was about a hundred lines that work as a table of contents, pointing into a docs/ folder.

So the perfect harness for the current model is mostly hypothetical. Without measuring, I would not know whether I had built it, and the default outcome of adding more is a slower agent that does what I said instead of what I needed.

Not everything goes stale

The second correction matters more, because it stops the argument sliding into "delete everything".

Some of what goes into these files is compensation: a patch for something the model gets wrong. "Always run the tests before you finish." "Think step by step." "You MUST read the file before editing it." Compensation is exactly what the next model makes redundant, or turns into over-steering.

The rest is information: things the model cannot know however clever it is. We do not run migrations from a laptop. Commits follow Conventional Commits with no attribution trailer. This is our word for the thing, not the industry's. A better model does not infer any of that from the code, and deleting it with every release would just mean relearning it by getting it wrong.

The ETH paper's own example of a minimal requirement is exactly this kind of line: the specific tooling to use in this repository. So is Vercel's eval from January. A compressed index of the Next.js 16 docs in AGENTS.md took their pass rate from 53% to 100%. That index was documentation for APIs newer than the model's training data.

When I read my own global file with this in mind, almost every line is information: commit format, never commit or merge without asking, never run database migrations. None of it is there because a model was weak, so the next model does not change it.

Skills fail in both directions

I had also lumped skills and commands in with CLAUDE.md. They are not the same risk.

A CLAUDE.md is loaded in full on every session, so every line is paid for on every task. A skill, under the Agent Skills format Anthropic opened up in December, costs only its name and description until it is used; the body loads when the task calls for it. An idle skill is nearly free. Claude Code merged custom slash commands into skills in January, and one I invoke by name costs nothing until I type it. Anthropic's own authoring guidance starts from the right assumption: Claude is already very smart, so only add context it does not already have.

Skills have their own failure, though, and it is the mirror image of the first. In Vercel's eval the agent never invoked the skill in 56% of cases, and adding a skill changed nothing over the baseline until they added explicit instructions telling the agent to use it. That fix, loud instructions to use the skill, is precisely what Anthropic's notes say the newer models over-trigger on, so a skill tuned to be noticed by one model can fire too often on the next.

So skills are not as bad as a long CLAUDE.md, but their cost sits somewhere else: in a trigger description and a step-by-step body that were both calibrated against a model that is already gone.

The checks are not the harness

The last thing I had wrong is scope. When I said "harness" I meant everything around the model, and some of that does not rot at all.

Tests, types, linters and a formatter tell the agent the truth about the code, and they tell every model the same truth. The most important tip in Cherny's thread was to give Claude a way to verify its work, which he said improves the result two to three times. OpenAI's harness leans on linters and structural tests more than on prose. A stronger model gets more out of a fast, reliable test suite.

The distinction I now use for hooks follows from that. A hook that runs the formatter after every edit is a check. A hook that injects a paragraph reminding the model to be careful is compensation wearing a hook's clothes, and it goes the same way as the rest of the compensation.

What I actually do

The position I started with, do not build a complex harness because the next model will outgrow it, holds up. What I would change is the reason and the remedy.

The reason is future decay, but also that unmeasured instructions cost tokens and attention today, and that the vendor rewrites the layer beneath mine every release.

The remedy is a harness that is cheap to delete:

• Keep information, cull compensation. If a line tells the model something it cannot know, keep it. If it tells the model to behave better, it has an expiry date.
• Point, do not paste. AGENTS.md is a table of contents; the knowledge lives in docs that are useful to people too.
• Put the effort into checks. Tests and linters survive every model.
• Re-earn it on each model. When a new model arrives, strip the compensation, work normally for a few days, and add back only what it keeps getting wrong. With a small harness that is an afternoon. With a large one it is a project, which is why it rarely gets done.

I wrote in October that every rewrite of my AGENTS.md removed more than it added. I thought that was a lesson about writing. It applies to models too, because the reader keeps getting better.