Leodegario Magsino Jr.
Agentic engineering · Essay

Choosing the model, and how hard it thinks

Every seat on my factory line gets two settings: which model sits in it, and how much thinking that model is allowed per task. The model sets the price. The thinking is almost free. Here’s how I choose both for every kind of work — and why the seats that judge never get cheaped out.

2
Settings per seat: model & effort
1
Seat below high effort
0
Judging seats cheaped out
The idea

One setting costs money. The other is almost free.

When people ask how I keep a line of agents inside a weekly budget, they expect a story about smaller models. It’s the opposite. On my line — the same one behind AI Light Factory — which model you pick sets the cost per token, while how much reasoning you let it spend on a task barely moves the bill. In the factory docs I put it as “model is the expensive dial and effort is the cheap one” — but you don’t need the metaphor. Two choices: the model is the price, the thinking is nearly free. Most teams get them backwards.

The failure mode I see everywhere: keep the frontier model “because quality”, then quietly lower its reasoning effort to save tokens. Now you’re paying premium rates for a judge that doesn’t think. Savings come from giving the simple work to smaller models — never from making the work that needs judgement think less.

how much thinking — almost free low high which model — sets the price none frontier false economy an expensive judge that doesn’t think Me · decide & plan frontier · max effort Developer Verifier Claude Code · high Reviewer Codex · high other vendor Guardian high · batched ×5 Orchestrator medium · follows procedure board · change map · shims no model at all — deterministic the only seat below high effort
Where each seat sits: which model, and how much thinking. The outlined box is me; dashed boxes are agents; the dashed zone top-left is the trap — frontier pricing with the thinking turned off. Judgement moves up and right; procedure moves down and left, all the way to no model at all.
Seat by seat

What each seat gets, and why

Every seat on the line is pinned in config — model and effort both — so lowering my session default to save tokens can’t silently downgrade a seat that judges. These are the assignments I actually run:

SeatModelEffortWhy
Decide & planFrontier, my own sessionMaxNothing re-examines these until the Verifier. A guess here gets built, reviewed and merged exactly as written
OrchestratorMid-tier is fineMediumThe only medium seat. It follows procedure — owns the queue, dispatches, reads one-line results. It never judges
DeveloperClaude Code, frontierHighWrites the code test-first. Its output is reviewed, but a sloppy build burns the Reviewer’s rounds
ReviewerCodex — a different vendorHighFresh context is its product, so it’s never batched. A reviewer sharing the builder’s blind spots fails silently
GuardianClaude Code, frontierHighJudges review threads with the severity ladder — but batched in fives, because most of a short session is startup cost
VerifierClaude Code, frontierHighThe only stage whose job is to prove the plan wrong. The worst place to economise
Board, change map, shimsNo model—Anything that can be deterministic, is. The review’s change map is computed from the diff with no model, so it’s exact

Notice the pattern: the two seats at the extremes are mine and the scripts’. Full judgement gets the frontier at max effort; pure procedure gets no model at all. Every agent seat lives between those poles, placed by how much judging it does — not by how much code it touches.

The economics

Pay at creation, not at inspection

Why so generous with effort? Because the alternative is more expensive. A defect that survives to a human costs a review, a fix, a re-review and a round trip — three or four agent sessions, plus the scarcest resource on the line: my attention. Preventing it costs one extra effort step on one session.

Caught at creation build session + one extra effort step draft PR merge ≈ 1 session Leaks to a human build session my review finds the defect fix session re-review round trip ≈ 3–4 sessions, plus my attention — the scarcest thing on the line
The same defect, two bills. One extra effort step at creation is the cheapest insurance an agent line can buy.

This is also why the review side of my setup, Three-Pass Review, scales effort by risk instead of spending uniformly: a copy fix gets Copilot and a light pass; a payments migration gets three independent checks and a reviewer brief before two humans even open the diff.

The ceiling

Degrade loudly, never overspend silently

Generous effort still needs a hard ceiling, or one bad week eats the month. The deep-review engine prices every call before making it — the API’s own token counter, assuming maximum output — and when the estimate crosses the budget, it degrades in a fixed order rather than quietly billing more:

price every call before it’s made over? shrink context step 1 still? drop a check step 2 still? drop the brief step 3 still over budget? refuse never overspend the real cost, from the API’s usage report, is printed in the review comment
The cost ceiling as a ladder. Retries are off for billed calls, so one call can never be billed twice — and a refusal is a visible event, not a quietly thinner review.

The rest of the weekly allowance is kept by habits rather than heroics: two lanes as a hard ceiling; workers that report one status line and a file path instead of their full output; waiting in a background shell rather than in turns; test output written to files; the Guardian batched in fives. And one deliberate exception — the Developer and the Reviewer are never batched, because fresh context is the Reviewer’s product. Some spend you protect.

The payoff

Where roughly half the spend goes away

Add it up, and this setup pays for its own generosity. Against the naive setup — every seat on the frontier model at high effort, nothing batched, nothing deterministic — a typical milestone on my line lands at a bit under half the usage. And the single biggest saving isn’t a model choice at all: it’s the defect round trips that never happen, because the judging seats were never turned down.

naive: all frontier, all high, no batching 100% defect round trips that never happen −22 Orchestrator on mid-tier · medium −12 Guardian batched ×5 −7 status lines & files, not full transcripts −9 no-model scripts board, change map −6 the line as I run it ≈ 44%
A worked example from the shape of my own milestones — illustrative shares, not a benchmark. Your mix will differ; the point is the ranking: the biggest saving comes from quality, the rest from putting procedure on cheaper models. Run the numbers on your own line before quoting mine.

Read the ranking, not the digits. Avoided rework beats every clever model choice, which is exactly why the judging seats stay expensive. Everything below it is the same move repeated: find procedure, make it cheap — a mid-tier Orchestrator, a batched Guardian, one-line reports, and scripts where no model is needed at all.

Measured

The settings get checked against reality

Settings you never measure drift into superstition. At the end of a milestone I run alf-stats, and the two numbers I read first are sessions per ticket and cost per merged ticket — because merging is the measurement. A draft nobody merges isn’t a cheap success; it’s an expensive failure.

$ alf-stats m2-billing-exports
------------------------------------------------------------
tickets drafted            6
tickets merged             5      merging is the measurement
sessions / ticket          3.2    target ≤ 4
cost / drafted ticket      $4.85
cost / merged ticket       $5.82
reviewer rounds (avg/max)  1.3 / 2
------------------------------------------------------------
leak check: clean — no stage sending extra work downstream

When sessions per ticket climbs well above four, I don’t lower anyone’s effort — that treats the symptom. The loop’s retro mode traces which stage is leaking work downstream: vague tickets leak into extra review rounds, a weak plan leaks into parked lanes. The fix is always upstream, and it’s almost always more effort at deciding time, not less effort everywhere else.

The heuristic

Three questions, for any task

You don’t need my factory to use this. For any piece of AI-assisted work, I ask three questions:

  1. Is it judgement or procedure? Judgement — deciding, reviewing, verifying, anything where being subtly wrong is possible — gets high effort, always. Procedure — dispatching, formatting, sweeping, anything a checklist could do — gets a smaller model, and ideally no model at all.
  2. Does anything re-examine it later? Work with a reviewer behind it can afford a cheaper first pass. Work nothing re-checks — a decision, a plan, a verification verdict — gets the frontier at max effort, because its mistakes compound silently.
  3. What does a miss cost downstream? Price the defect’s full journey — the sessions, the round trips, your attention — not the call in front of you. If the miss costs four sessions, one extra effort step is the bargain of the week.
Let the work that needs judgement think as much as it wants. Give the work that’s just procedure the cheapest model that can do it. Never mix the two up.

The full defaults — pinned seats, budgets, the ceiling — live in the open ai-light-factory and three-pass-review repos. Steal them, then measure your own.