Files
platform/todo/background-jobs/a-commander-picks-the-cheapest-model-that-will.md
T
pastilhasandClaude Opus 5 a6e7f64ef2 todo: a commander should suggest the cheapest model for each half of itself
Wanted 2026-08-22, for later. Before arming anything, a commander weighs how hard the job actually is and
proposes which model each half should run on.

TWO models, which is what makes it more than a generic "use something cheaper" note. A commander's own turns
are conversation plus one piece of bash; the agent its loop spawns does the real work and its difficulty is
set by the job. The deploy commander is the worked example — its own turns were unremarkable on Sonnet while
the spawned agent judged six hosts, parsed a plan, decided what to skip and wrote an honest report.

Suggested, never imposed: the failure mode of choosing too small is not a slower answer, it is a watcher
firing on the wrong condition or an agent half-finishing a deploy.

Recorded with the reason it is not urgent: nothing measures whether the choice was right. A spawned agent's
cost is not captured at all yet — the column exists and is always null — so a commander suggesting Haiku has
no way to learn it was wrong. This wants the cost work first, or at least the knowledge that until then it is
a judgement with no feedback loop.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 20:39:26 +00:00

2.3 KiB

id, title, theme, status, created, date_source, order
id title theme status created date_source order
background-jobs/a-commander-picks-the-cheapest-model-that-will A commander picks the cheapest model that will do the job — for itself and for what it spawns background-jobs open 2026-08-22 stated 2

Before it arms anything, a commander should weigh how hard the job actually is and say which model each half should run on. Wanted 2026-08-22, for later.

Two models, not one, and this is the part that makes it worth doing rather than a generic "use a cheaper model" note. A commander has two quite different workloads:

  • the commander's own turns — agreeing the job with the owner, writing a shell loop, reporting. Mostly conversation and one piece of bash.
  • the agent the loop SPAWNS when it fires — which does the actual work, and whose difficulty is set by the job rather than by the conversation.

Those can differ by a lot in the same commander. The deploy commander is the worked example: its own turns ran on Sonnet and were unremarkable, while the spawned agent judged six hosts, parsed a plan, decided what to skip and wrote an honest report. A watcher that pings a URL and echoes the status needs neither to be clever.

Inferred from the job, and SUGGESTED rather than imposed. The commander proposes ("this looks like Haiku for the watch and Sonnet for the action, because…") and the owner overrides. A model chosen silently is one nobody can argue with, and the failure mode of choosing too small is not a slower answer — it is a watcher that fires on the wrong condition, or an agent that half-finishes a deploy.

Where it goes: a section in the Commanders skill, beside the four shaping questions, since the moment to ask it is the same moment — while the job is being agreed and before anything is armed. It is one more thing to settle in the conversation the skill already describes.

What would make it honest rather than a guess, and the reason this is not urgent: nothing currently measures whether the choice was right. The cost of a spawned agent is not recorded at all yet (command_hq_spawned.total_usd exists and is always null), so a commander suggesting Haiku has no way to learn it was wrong. Worth doing after cost accounting, or at least knowing that until then this is a judgement with no feedback loop.