walid@portfolio:~/lab/zero-api-army$
cd../lab
13ideaAug 2026

A multi-agent army on zero API keys

Three subscriptions, $240 a month flat — no meter, no per-token bill

Orchestration is the token bill, so the whole design is a delegation layer: expensive models decompose and judge, cheap models sprawl and summarise, and nothing raw ever crosses between them. The same work at API rates was tracking toward $15,000 over 10B tokens; on subscriptions it lands near $800.

Multi-agentClaude MaxOllama CloudCodexToken budgetsDelegation
Read this first

When this earns its keep, and when it does not

Anthropic measured their own multi-agent system: 15x the tokens of a plain chat for the same task, and a single agent already runs about 4x. On their browsing eval, 80% of the performance variance is explained by token usage alone. Orchestration is the token bill. That is why everything below optimises the delegation layer and nothing else.

The honest limit: work that splits into independent lanes pays for delegation. Work where every step depends on the last pays the 15x multiplier without earning it. Keep that on one thread, with one agent.

The bill

$240 flat. Nothing metered.

Roughly 93% of the bill disappears the moment you stop paying per token.

SubscriptionWhat it pays forCost
Claude MaxConductor + dept heads, headless over OAuth, not the API$200
Ollama CloudGLM-5.2 worker lane, one flat key$20
ChatGPT planCodex, the second worker lane, code execution$20
TotalThe whole company of agents$240 / mo
01 · The conductor

System prompt for the expensive model

Fable 5 or Opus 5. It reads the goal, writes the plan, and never reads raw output. About 5% of the tokens, about 90% of the outcome.

conductor.prompt18 lines
You are the Conductor. You are the most expensive tokens in this company,
so you only do the two things nobody else can: decompose and judge.

Rules:
1. Break every goal into independent lanes. If two steps depend on each
   other, they are one ticket, not two.
2. Write the acceptance criteria before any work starts. A brief a cheap
   model can misread is your failure, not the model's.
3. You never read raw output. Workers return one page or less. If a worker
   returns more, send it back unread.
4. Decide, hand off, forget. Do not carry a lane's context after you have
   delegated it.
5. Read summaries, never transcripts. Plans and findings live in files;
   your window holds pointers.
6. Escalation is one-way. A worker can ask you for a decision. It can
   never take one.
7. You do not type. If you catch yourself writing the implementation,
   stop and write a brief instead.
02 · The dept head brief

The ~600 token ticket a worker cannot misread

Dept heads run on Claude and do one job: turn one line of intent into a spec. This is the template every ticket uses going down to the worker pool.

ticket.template22 lines
TICKET: [one line. the goal, not the method]

CONTEXT: [3 lines max. only what the worker cannot find on its own]

ACCEPTANCE CRITERIA:
- [observable check 1]
- [observable check 2]
- [observable check 3]

CONSTRAINTS:
- Token budget for this run: [ceiling]. If you hit it, stop and ask.
  Never push through it.
- Spawn depth: you may spawn sub-agents for wide sweeps. Your sub-agents
  may not recruit.
- Keep sub-agents stateless and isolated. Do not accumulate their context
  into yours.
- Working files go to disk. Your report carries pointers, never dumps.

RETURN FORMAT:
- One page, 1,500 tokens max: what you did, what changed, what needs a
  decision.
- Nothing raw. No logs, no transcripts, no tool output.
03 · The worker contract

System prompt for the cheap lanes

GLM-5.2 and Codex. In: a ~600 token brief. Inside: 40K+ tokens of sprawl on the cheap lane. Out: 1 to 2K tokens back up. Nothing else crosses the boundary.

worker.prompt15 lines
You are a worker on the cheap lane. Sprawl is allowed here, and only here.

1. Explore as wide as the job needs: crawl the repo, the logs, the inbox.
   Exploring 50K tokens to report in 1,500 is correct. The exploration is
   disposable; the summary is what gets carried.
2. Cap the return, not the work. Whatever you burned inside, the answer
   goes back in 1,500 tokens or less.
3. Offload to disk. Findings, drafts, and tool dumps go to files. Your
   report points at them.
4. Map first, read narrowly. Orient with a repo map; read full source only
   for files you are editing.
5. Report in exactly three blocks: DONE (what you did), CHANGED (files and
   state you touched), NEEDS DECISION (questions for up the chain, if any).
6. You can ask for a decision. You cannot make one. If the brief is
   ambiguous, say so in NEEDS DECISION instead of guessing.
The token caps

What stops it running away

A sub-agent that recursively spawns sub-agents, or a tool returning a 200K-token dump, multiplies a run by 10x on its own. The published research architecture ships no circuit breakers. These are the ones every ticket carries.

CapThe rule
Depth capTwo levels of spawn. A worker’s sub-agent cannot recruit.
Per-run budgetEvery ticket carries a token ceiling. Overrun stops and asks, never pushes through.
Output truncationNothing over ~2K tokens enters a context window unsummarised.
Return capWorker reports come back at 1,500 tokens max, pointers instead of dumps.
CompactionCompact at task boundaries from ~50% full. Auto-compaction at 85% is already too late; recall has degraded.
Window awarenessHeavy Claude runs staggered across the 5-hour usage window, never stacked.

Three things that break the prompt cache mid-session

A cache read costs a tenth of a fresh read, and a healthy prefix holds a ~90% hit rate. The habit: one stable system block per agent, tools loaded per phase, nothing rotating above the first user turn. Alert at zero hit rate, not at month end.

✗adding or removing an MCP server mid-session✗switching models halfway through a run✗timestamps or run ids in the system prompt
The lane config

A model per seat

Routing is the cheapest optimisation there is: nothing about the task changes, only which meter it lands on.

WorkLane
Decomposition, architecture, judgementFable 5 / Opus 5
Briefs, review, merge decisionsClaude Sonnet
Codegen, tests, execution loopsCodex
Bulk refactors, crawls, long readsGLM-5.2
Watchers, cron, classification, triageGLM Flash

The whole routing table

lanes.yaml20 lines
# lanes.yaml · the whole routing table
conductor:
  model: claude, fable-5 or opus-5
  auth: oauth subscription, no api key
  does: decomposition, architecture, judgement
dept_heads:
  model: claude sonnet
  count: 6
  does: briefs, review, merge decisions
worker_codex:
  plan: chatgpt subscription
  does: codegen, tests, execution loops
worker_glm:
  provider: ollama cloud, one flat key
  model: glm-5.2
  does: bulk refactors, crawls, long reads
worker_flash:
  model: glm flash
  does: watchers, cron, classification, triage
escalation: one-way. a worker asks, it never decides.

Running the worker pool

The worker pool runs behind Hermes, bound to loopback behind Tailscale. Two commands.

hermes.sh2 lines
$ hermes gateway                            # loopback + tailscale
$ hermes run --lane glm --summarize 1500    # the return cap, enforced
← previous
The Airbnb listing video system
next →
One setup, nothing else
← all experiments