The workshop

This is not a demo setup. It is what 250+ agent sessions have been run through, 100+ of them in the last ninety days, across a multi-repo platform workspace — and 16 custom skills, seven at workspace level and nine at repository level, exist because those sessions kept needing them.

Two interchangeable agent runtimes read the same instruction file, because a rule that exists for one tool disappears when you change tools. The skills and commands live in one directory and are symlinked into each tool’s location, so there is exactly one copy to keep correct — and an assertion that every copy is byte-identical, for the cases where a symlink is not an option.

Tiering, and the tripwire that makes it real

Two models, split by how the work happens rather than by what it is called:

• The primary session — the loop that reads, reasons and writes the code — runs on the strong model.
• Delegated agents run on the cheap one: the planning mode, and the exploration subagents sent off to read widely and report back. Bulk reading is triage; paying frontier rates to skim a repository is a choice, not a requirement.

The shorthand in my config says “cheap model for planning”. That is close enough to be useful and wrong enough to correct: the reasoning inside an implementation session is still on the strong model. What is actually tiered is delegation.

Both sit on a flat subscription, which is where it gets interesting. A provider that loses its credential does not error. Sessions silently fall back to another provider — and on this setup, falling back means metered billing while the flat subscription sits unused. Nothing in the tool surfaces that.

So model tiering is not configuration, it is a precondition. A script runs at session start, checks that every configured tier actually resolves under the current auth, and stops the session if it does not. It also pins the exact runtime version the permission rails were settled against, and warns loudly on drift, because rail semantics have changed between releases before.

Why not the other way round?

The common arrangement is the inverse of mine: the strong model plans, a cheap one implements. It is a serious argument, and it goes like this.

Leverage. A wrong plan wastes every token spent after it. Quality at the top of the funnel compounds; quality at the bottom does not.

Output asymmetry. Plans are short and implementations are long. Frontier rates on a few hundred output tokens cost almost nothing — spend accumulates in the long tail, which is exactly where you would want the cheap model sitting.

Transcription. If a plan specifies down to the diff, implementation is mechanical, and mechanical work is what cheap models are adequate at.

I run it the other way, and the reason is not that planning errors matter less.

Detection cost, not error cost

The deciding asymmetry is which mistakes are cheap to catch.

A thin plan reads as thin. You reject it in seconds, before anything has been spent acting on it. Plausible-but-wrong code does not read as wrong: it passes review, passes the build, passes a structural contract, and surfaces later — in production, or in the next session that reads it and assumes it was correct.

That is the whole thing. Weak models do not fail loudly, they fail plausibly, so the cost never lands on the model. It lands on human review, which is the scarcest resource in the loop and the one the tiering was supposed to protect.

Two smaller objections, both real:

• A plan precise enough for a weak model to implement correctly is very nearly the implementation. You pay the strong model to write pseudocode, then pay again to have it transcribed.
• Implementation is where the invariants live — the accumulated gotchas, the rules nobody wrote a test for. Holding many constraints at once while producing code is precisely what a weaker model drops.

What would change my mind

This is a property of the test suite, not of the model, which makes it checkable rather than a matter of taste.

My contract asserts structure: that the index and its entries agree in both directions, that entries carry dates, that symlinks are intact, that no secret or orphan file crept in. It does not assert logic. So the machine gate cannot currently backstop a weak implementer, and the review burden falls back on me.

If the tests caught semantic error — not “does it build” but “is this the behaviour” — detection moves from the human back to the machine, and a cheaper implementation model becomes affordable. Until then the strong model belongs where the weakest gate is, and that is the diff.

A third option: route by difficulty, not by phase

The split does not have to follow the phases at all. The version I have specified but not built classifies each task as trivial, standard or complex and routes per task rather than per stage.

The constraint is the more interesting half: the classifier receives the task text only, never file bodies. The thing deciding how much to spend never sees the code. That keeps a routing decision from becoming a second, quieter egress path — which is the same reasoning that keeps the triage tier opt-in and out of CI.

It is unbuilt, and it reframes the question rather than settling it.

Measuring cost without reading anyone’s prompts

Spend is reported from the session database, split between flat-subscription and metered usage. The reporting script is written so that it selects aggregate columns only — it is structurally incapable of printing a session title, a prompt, or any text payload.

That is not a policy note in a README; it is the shape of the query. The guarantee holds because the capability is absent, which is the only kind of privacy guarantee worth writing down.

Rails

The bash permissions are deliberately boring and asymmetric:

• Force-push is denied outright. Not prompted — denied.
• Push, reset, clean and restore all ask. They are recoverable or routine enough that a prompt is proportionate.
• Everything else is allowed, because a rail that fires constantly is a rail people learn to click through.

The ordering matters: the permissive default comes first and the specific rails after, since the last matching pattern wins.

What this is for

None of it makes an agent smarter. It makes the cost of running one predictable, the blast radius bounded, and the lessons durable — which is what turns a promising demo into something you can leave running on a real repository without checking on it nervously.