Moving Agent Fixes Across Tools: Brain in the Plugin, Hands in the Harness

I fixed my agent costs twice: once in the harness, once in a plugin. Only one of those fixes moves with me to the next tool.

The lock-in problem

After the 15 October spike (article 1) I made six fixes. Four of them lived in Claude Code itself: a hook, two settings, and a rule in a project file. They worked. But every fix I put in one harness ties me a little more to that harness.

I use three coding agents: Claude Code, Codex, and Grok. The tools change fast. A rule that exists only as a Claude Code hook does nothing when the same work runs in Codex.

So I asked a different question: which part of each fix is thinking, and which part is enforcement?

The split

The rule: the plugin says what and why in words any host can follow. The harness says no when the agent tries something the plugin forbids. A new harness then needs new hooks, but no new thinking.

What I moved

My plugin is called proof. Its core idea: an agent proves its work with real checks before it says "done". It loads as one small router skill that points to deeper skills only when a task needs them. Three design rules govern it: the fewest always-on tokens, no hooks inside the plugin, and the user's own rules always win.

Version 0.6.0 adds one section, Economy, with five rules taken straight from my usage data:

1. 01Checks ladder. Run the checks for the changed files while you edit. Run the full suite once, before each push. (From: tests run after every edit, with the cache dying during long runs.)
2. 02Review convergence. At most 4 outside review rounds; rounds 1–2 fix every finding and the same fault elsewhere; from round 3 defects only; after round 4 one push and no new request. (From: article 2.)
3. 03Worker contract. A subagent does one unit, proves it with its own checks, and hands back once. CI, the full suite and PR reviews belong to the main session. (From: the top cause of long cache gaps was a parent resuming a worker after hand-back: 167 gaps, 41M rewrite tokens.)
4. 04Model tier by work. Without a user policy, build at the middle tier and review at the strongest. (From: the strongest-tier build workers of 15 October.)
5. 05Batched turns. Independent reads and checks go in one turn. (From: 79% single-tool turns.)

None of the five names a host or a model. That is the point.

How I checked it

A rule in a router skill is only useful if a model reads it the same way every time. So I tested the router like code:

• Router scenarios. 26 written cases ("a subagent finished its unit: run the full suite?", "round 4 left one security finding and two style notes: what now?"). A small, cheap model reads only the router file and answers each one. 25 of 26 matched. The one miss (case 23) answers the same way on the old router, so the new section did not cause it.
• One fresh reviewer. Its first pass failed the change with 5 blocking findings, 9 in total. Examples: the checks ladder could skip a bug reproduction step; the model rule conflicted with an older design decision; the defect list for round 3 was too narrow. All 9 were fixed before merge.
• Repository checks. 100 unit tests, the vendor check over 133 files, the release check, and the plugin validator: all green, and CI green on Linux and Windows.

One release, three hosts

The table below shows how each host picks up proof. The interactive element after it lets you switch between hosts.

One edit in one repository reached all three agents the same day.

What I learned

• Put the reason next to the rule. A host can enforce a rule, but only the words carry why. The why is what lets a model apply the rule to a case nobody wrote down.
• Enforce in the harness, explain in the plugin. My model guard hook stays in Claude Code. The plugin explains the tier rule, so Codex and Grok follow it too, without the hook.
• Test instructions like code. Scenario cases on a small model are cheap, and they caught a regression in my first draft (case 19).
• Thin always-on text is a feature. Every always-loaded word is paid on every turn (article 1). The Economy section is about 15 lines in a router that loads deeper skills only on demand.

Source of the numbers

Plugin figures come from the proof repository (Gargeya-Grey/proof, release tag proof--v0.6.0, CI green). Subagent gap figures come from 709 subagent transcripts, 1–16 October 2026, via ttl.py and ttl2.py. The router scenario results come from 26 written test cases run against a small, cheap model. No student data is used.

Definitions

• Brain: what to do and why, written as plain words a host can follow.
• Hands: hooks and settings that enforce a rule in a specific harness.
• Router scenario: a written case with an expected answer, checked by a small model reading only the router file.

Caveats

• The source does not name the small model used for the router scenarios. Add the model name before publishing so readers can reproduce the test.
• The 167 gaps and 41M rewrite tokens come from the parent-resume cause in the cache analysis. They are measured on the transcripts in the window above, not on a general population.
• The one missed scenario (case 23) gives the same answer on the old router. That shows the new section did not cause the miss. It does not show the miss is correct.
• The host table comes from the article's own release table. The enforcement lines in the interactive element for Grok and Codex are my reading of the article's statement that the model guard hook "stays in Claude Code". Check that against each host's current setup before publishing.

References

1. 01proof plugin repository, Gargeya-Grey/proof, release proof--v0.6.0.
2. 02Subagent transcript analysis, 709 transcripts, 1–16 October 2026.
3. 03Companion pieces: Article 1 (cost forensics) and Article 2 (review loop cap).