Module 5: Cost Control + Multi-Agent Workflow

Opus for a one-line copy change is like hiring a lawyer to order lunch. Most AI spend is waste from picking the wrong model for the task. This module teaches you to match the model to the job, track what you actually spend, and run multiple agents at once without them stepping on each other.

Key idea

Match the model to the risk. Cheap models for safe work, strong models for risky changes.

This module includes

Time: about 1.5 hours of focused work
You finish with: a cost tracker with real data and a model-selection reference you use for every task
Start by logging every AI cost for a day of building, then optimise from there

Route each task to the right model, then verify the output.

Outcome

Your AI bill drops dramatically. The output quality stays the same.

Deliverable

A cost tracker with real session data and a model-selection config you can reference per task type.

Lessons

·How token pricing actually works: input vs. output, per provider
·Haiku for boilerplate, Sonnet for features, Opus for architecture
·What to put in the context window and what to leave out
·Batch execution vs. chatting back and forth and the real cost difference
·Caching work you’ve already paid for so you don’t pay again
·Budgeting per feature so the bill is never a surprise
·Prompt compression: fewer tokens, same result
·When Opus is worth the money and when Haiku does the job
·A dead-simple per-session cost log that takes 30 seconds
·Better specs mean fewer rework loops, which means lower cost
·Running agents in parallel vs. in sequence: cost tradeoffs
·Setting a monthly AI budget and actually holding it

Exercises

·Build the same feature with Opus, then with Sonnet. Compare the output and the bill.
·Log every AI cost for one full day of building. See where the money actually goes.
·Take your longest execution prompt and cut 40% of the tokens without losing anything useful.

What good looks like

You know cost control is working when your bill drops but your output quality stays the same.

Three sessions logged with model, task type, and cost per task.

Proof Checklist

Proof

☐Cost tracker committed with real data from 3+ sessions
☐Model-selection config documented, one line per task type
☐npm run build exits clean
☐git show --stat HEAD shows only intended changes
☐git show --name-only HEAD lines up with your targets

The cost rule that changes everything

Most people pick the strongest model for every task and wonder why the bill is high. The fix is simple: match the model to the risk.

·Cheap model for low-risk work. Scanning files, summarising context, rewriting copy, generating boilerplate. Haiku or equivalent. It costs almost nothing and the output is fine.
·Strong model for risky code changes. New features, refactors that touch many files, anything where a mistake means rework. Sonnet or Opus. The cost is higher but the output is worth it because you skip the debug loop.
·Strong model for debugging, but only with a repro. Do not throw a vague error at Opus and hope it figures it out. Isolate the problem first, write a minimal reproduction, then ask the expensive model. You will get the fix on the first try instead of the fifth.

This is not about being cheap. It is about spending on the tasks where quality actually matters and not wasting money where it does not.

3-agent playbook

Running multiple agents at once is how you get a lot done in a short session. But if two agents touch the same file, you get merge conflicts and wasted work. The fix is a strict hotspot registry.

Hotspot registry example

Agent A: copy templates and toolkit content only
Agent B: module page content only
Agent C: one specific page (e.g. landing, pricing, or a single component)

Each agent gets a non-overlapping set of files. If two agents need the same file, you serialize: one finishes and commits before the other starts.

Concurrency guardrails

One issue per agent. No side quests.
No agent edits files outside its assigned hotspot.
Every agent produces a HANDOFF with git show proofs.
If git status shows files outside your hotspot, stop immediately.
No silent conflicts. No overlapping diffs. No hidden edits.

Three agents with clear boundaries will outperform one agent trying to do everything. The discipline is in the file assignments, not the prompting.

3-agent kickoff script

Paste this into ChatGPT. It will generate three separate Claude task scripts with file boundaries already assigned. Fill in the bracketed values and you are ready to run all three in parallel.

Generate 3 Claude task scripts for parallel execution.

Project repo: [your repo path]
Branch: main
Project type: [e.g. Next.js + Tailwind + Clerk]

The 3 tasks:

Task A: [describe task A]
  Allowed files: [list files agent A may edit]

Task B: [describe task B]
  Allowed files: [list files agent B may edit]

Task C: [describe task C]
  Allowed files: [list files agent C may edit]

Rules for all 3 scripts:
  Each script must start with repo confirmation (pwd, branch, clean tree)
  Each agent may ONLY edit its listed files
  One commit per agent
  Each commit must pass: npx tsc --noEmit && npm run build
  Each agent must return a HANDOFF PACKET with:
    git show --stat HEAD
    git show --name-only HEAD
  No file may appear in more than one agent's hotspot
  If an agent sees changes outside its hotspot in git status, it must stop

Output format:
  3 separate code blocks, each a complete Claude task script
  Label them SCRIPT 1 (Agent A), SCRIPT 2 (Agent B), SCRIPT 3 (Agent C)
  Each script should be copy-paste ready for Claude

You will refine the file boundaries as your project grows. Start broad, tighten after the first session.

All modules Next: Shipping to Production