pastilhasandClaude Opus 5
a6e7f64ef2
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>
40 lines
2.3 KiB
Markdown
40 lines
2.3 KiB
Markdown
---
|
|
id: background-jobs/a-commander-picks-the-cheapest-model-that-will
|
|
title: 'A commander picks the cheapest model that will do the job — for itself and for what it spawns'
|
|
theme: background-jobs
|
|
status: open
|
|
created: 2026-08-22
|
|
date_source: stated
|
|
order: 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.
|