11.3 The Economics: Costs, Models, Budgets

You've been checking /usage since Chapter 6 — time to turn usage evidence into an operating model. What agentic work can cost, how model choice changes consumption, and how to compare cost with outcomes without pretending an estimate is a bill.

What you will learn

• Read your real cost structure: tokens, sessions, and what drives each.
• Match model tiers to task types — the biggest single lever on the bill.
• Choose between subscription and API pricing for your actual usage.
• Frame costs the professional way: unit economics per shipped thing.

Builder principle

Track usage, time, and outcomes together. Your own repeated measurements beat borrowed price claims.

What you're actually paying for

Costs can include a subscription, API tokens, tool and hosting fees, labor, review, support, and incident risk. Context length and repeated turns can affect API usage or plan allowance, but they are not the whole cost structure.

• Bloated always-on context (a rambling CLAUDE.md) is a tax on every session — trim it and the savings recur (5.2's "every token earns its slot," now denominated in money).
• Marathon unscoped sessions re-send their swollen history every turn — 5.5's session shapes are directly cheaper.
• Exploration debris in the main window is paid-for noise — subagents (10.1) quarantine the spend and return only conclusions.
• Failed approaches retried in a polluted window burn tokens on confusion — the 6.3 clean-restart move is a cost control too.

You optimized all of this for quality chapters ago. For API users it can reduce billed tokens too; for subscribers it can preserve plan allowance and shorten feedback loops.

The model tier lever

Available models can differ in capability, latency, plan eligibility, and API price. Names, limits, and relative pricing change, so use this as an experiment plan rather than a claim about a current product lineup:

Task type	Tier	Why
Routine, well-harnessed: formatting, summaries, log triage, homogeneous fan-out chunks (10.1)	Lower-cost candidate	Test whether the harness catches relevant misses
Daily building	Default candidate	Validate quality, latency, retries, and usage on your tasks
Architecture, hard debugging, split-planning (10.3), or costly errors	Higher-capability candidate	Test whether capability reduces enough rework to justify cost

If your current tool supports model selection, verify its current documentation. Compare quality, retries, latency, and usage on representative tasks before setting defaults.

Subscription vs. API

Two ways to pay, and the right one is usage-math, not ideology:

• Subscription (Claude plan tiers): included usage with plan limits. In /usage, subscribers see plan bars and activity; the local session dollar estimate is not a billable charge.
• API pricing: usage billed per token, useful when you need programmatic automation or project attribution. /usage computes local estimates from token counts; the Claude Console is authoritative for actual billing.
• Mixed setups: may fit hands-on subscription work plus API automation, but compare current terms, limits, and your measured workload before choosing.

Unit economics: the framing that matters

A per-result view can be more actionable than a monthly total:

Per shipped thing:
  compute usage and cost estimate  (plan usage or authoritative API billing)
+ your hours × your rate
= cost of goods
vs. what it returned  (fee, hours saved × rate, career value)

Run it on your 6.2 recipe using your own evidence: plan tier or API bill, hosting and tool fees, hours, support commitment, taxes, and risk reserve. Then compare with the value delivered and prices in your actual market. One project is a data point, not a pricing law; repeated projects make the estimate more useful.

🌱 No-code lane⚙️ Engineer lane

Keep it simple: /usage, your plan or authoritative API bill, other tool fees, and honest hours per project. Start with a workhorse model, then adjust from evidence. Compute is one input to cost of goods, not a substitute for valuing your labor or planning support.

At team scale, measure per-subagent model choice, retries, latency, and accepted output. Separate credentials or workspaces can improve attribution, subject to provider policy. Carry pilot data into planning rather than assuming compute is negligible beside salaries.

Try it now

1. Pull your real evidence: /usage, your subscription line or Console API bill, and other tool fees. Record what the month cost or consumed, and what shipped.
2. Tier audit: list your five most common task types → assign tiers → set your default and your exceptions. Update subagent roles accordingly.
3. Unit-economics one real project retroactively: compute + hours vs. what it returned (money, time saved, or portfolio value — pick honest numbers).
4. Standing rule, in your user CLAUDE.md: journal usage + tool fees + hours per shipped thing. After several comparable projects, revise your estimate instead of treating it as certainty.

Check your understanding

• Why do Chapter 5 skills double as cost controls — two concrete examples?
• Match tiers: log triage · architecture decision · daily feature work. What's the mispricing anti-pattern called in each direction?
• What evidence would make API pricing a better fit than subscription for your workload?
• Compute the unit economics of your last shipped project — out loud, right now.