6 Claude Sub-Agents Cut My API Bill From $140 to $52/mo

By Lazar Milicevic · Published June 15, 2026 · 10 min read

Your Claude automation is one bad Tuesday away from collapsing, and it's not the model's fault. It's the single-session pattern every tutorial teaches you. If you've watched a long workflow slow to a crawl, hallucinate halfway through, or burn tokens like a furnace, you already know the pain — and the fix isn't a better prompt.

Why your single-agent Claude setup quietly breaks around week three

The story I keep walking into looks identical every time. A solo founder or a small ops team builds something useful on Claude — email triage, lead scoring, invoice drafting, call summaries. Week one it feels like magic. Week three it starts missing things. Week five the API bill has doubled and the assistant is forgetting instructions it followed perfectly on Monday.

People blame the model. They reach for a bigger context window. They keep adding rules to the system prompt. None of it works, because the problem isn't the prompt. It's the architecture.

Here's the math nobody shows you. A single Claude session that handles three jobs in one conversation drags every previous message into every new turn. By the end of a normal workday that session is sitting on 150,000 to 180,000 tokens of accumulated history. Every new email you throw at it gets compared against the entire novel. You're paying input tokens on the whole backlog every single turn.

What that looks like in practice:

• Latency climbs from ~3 seconds to 12–15 seconds per turn
• Accuracy drops because the model is drowning in its own history
• Contradictions appear — Monday's rule gets quietly overridden by Wednesday's stray instruction
• Cost scales linearly with conversation length, not with the work done

The fix is not a smarter prompt. The fix is splitting the job into specialists that don't know each other exist.

The orchestrator plus sub-agents pattern, in plain terms

Most tutorials teach Claude as one big chat window. One assistant, one system prompt, one running conversation. That's fine for personal use. It breaks the moment you put it in production.

What I run instead — and what I deploy for clients — is an orchestrator plus sub-agents pattern. One coordinator agent receives incoming work. It does not do the work itself. It reads the task, picks the right specialist, hands off only the relevant slice of context, and merges the result back.

Each specialist runs in its own isolated context window, usually under 8,000 tokens, focused on exactly one job. No shared memory. No carry-over from yesterday. No idea the other specialists exist.

In one of my production systems I run six of them:

• Email triage agent — classifies and routes incoming mail
• Lead scorer — knows the rubric and the CRM schema, nothing else
• Invoice drafter — knows billing rules and the client list
• Calendar coordinator — reads/writes appointments only
• Document summarizer — collapses long inputs to structured summaries
• Notification dispatcher — sends Telegram/Slack/email alerts

The orchestrator is the only piece that sees the bigger picture, and even it stays lean because it delegates instead of doing.

Real numbers from the switch

I'm not going to estimate. Here's what actually changed when I migrated a client setup from one bloated session to this pattern, measured over a full month before and after:

The cost drop isn't because Claude got cheaper. It's because the average input payload per call shrank by roughly 15x. You stop paying to re-read the novel every time.

The latency drop is the same story. Smaller payload, faster response. The invoice hallucinations vanished because the invoice drafter literally never sees email content that could bleed into a billing line. Isolation is the safety mechanism.

And debugging — this is the underrated win. When something goes wrong, I know exactly which specialist failed. Not which sentence in a 10,000-line transcript poisoned the well. I check the triage log, or the scorer log, or the drafter log, and the bad input is sitting there in 200 tokens of clean structured data.

Step-by-step: building the first three agents

You don't build all six on day one. You build them in an order that pays for itself by the second agent. Here's the path I use every time.

The build order that actually works

• Step 1 — Orchestrator definition (under 90 lines)
• Step 2 — Email triage sub-agent (the noisiest job)
• Step 3 — Lead scorer (consumes triage output)
• Step 4 — Invoice drafter (proves the isolation pattern)
• Step 5 — The handshake schema between them

Step 1 — Orchestrator. A short markdown file. Mine is 80–90 lines. It lists available sub-agents, what each is good at, and the routing rules. Its only job is to read incoming input, decide which specialist gets it, and prepare a clean handoff payload.

# orchestrator.yaml
sub_agents:
  triage:
    purpose: classify and extract fields from incoming email
    accepts: { from, subject, body, received_at }
    returns: { category, priority, extracted_fields }
  scorer:
    purpose: score sales leads against rubric
    accepts: { extracted_fields, source }
    returns: { score, tier, reasoning }
  invoicer:
    purpose: draft invoice from confirmed line items
    accepts: { client_id, line_items, currency }
    returns: { invoice_draft, warnings }

routing_rules:
  - if category == "sales_inquiry" -> scorer
  - if category == "billing_request" -> invoicer
  - if priority == "low" -> notify_only

The payload is the whole game. You do not forward the conversation. You forward only what the specialist needs.

Step 2 — Email triage sub-agent. Pick the noisiest, most repetitive job. For most solopreneurs that's email. Write a sub-agent that does one thing: classify, extract key fields, return structured output. No conversation memory. No general knowledge about the business beyond a few hundred lines of instructions and edge-case examples.

def call_triage_agent(email):
    payload = {
        "from": email.sender,
        "subject": email.subject,
        "body": email.body[:4000],   # hard cap
        "received_at": email.timestamp,
    }
    return claude_call(
        system=TRIAGE_SYSTEM_PROMPT,   # ~1,200 tokens
        user=json.dumps(payload),
        max_tokens=400,
        response_format="json",
    )

Total context window for this call: under 6,000 tokens, every single time. It doesn't grow with usage.

Step 3 — Lead scorer. Consumes triage output. The orchestrator sees category == "sales_inquiry" and routes the extracted fields to the scorer. The scorer never sees the raw email. It works on clean structured data, which is exactly why it's fast and cheap.

def call_scorer(triage_result):
    if triage_result["category"] != "sales_inquiry":
        return None
    payload = {
        "fields": triage_result["extracted_fields"],
        "source": "email",
    }
    return claude_call(
        system=SCORER_SYSTEM_PROMPT,   # ~900 tokens, includes rubric
        user=json.dumps(payload),
        max_tokens=200,
        response_format="json",
    )

Step 4 — Invoice drafter. The one that proves the pattern. Tight rules, narrow context, explicit refusal conditions when data is missing. The reason this works is that the drafter has no idea triage or scoring exist. It cannot accidentally pull a phrase from a sales conversation into a billing document. The isolation is what makes it safe to let near money.

def call_invoicer(client_id, line_items):
    payload = {
        "client_id": client_id,
        "line_items": line_items,
        "currency": "EUR",
    }
    result = claude_call(
        system=INVOICER_SYSTEM_PROMPT,  # billing rules + refusal conditions
        user=json.dumps(payload),
        max_tokens=600,
        response_format="json",
    )
    if result.get("warnings"):
        route_to_human(result)   # never auto-send incomplete invoices
    return result

The handshake — where most implementations break

Splitting agents is easy. Making them talk cleanly is where people screw it up. The handshake between orchestrator and sub-agent has to be a strict schema, not a free-form string.

Three rules I never break:

• Every sub-agent accepts JSON and returns JSON, validated against a schema. If validation fails, the orchestrator retries once with a clarifying note, then escalates to human review.
• Every sub-agent has an explicit refusal output — a structured {"status": "insufficient_data", "missing": [...]} response. Specialists don't guess; they refuse cleanly.
• The orchestrator never edits a sub-agent's output before forwarding. It either passes it on as-is or rejects it. Editing in the middle is how you reintroduce the single-agent bloat through the back door.

def orchestrate(incoming):
    triage = call_triage_agent(incoming)
    if not validate(triage, TRIAGE_SCHEMA):
        return escalate(incoming, reason="triage_invalid")

    if triage["category"] == "sales_inquiry":
        score = call_scorer(triage)
        return merge(triage, score)

    if triage["category"] == "billing_request":
        return call_invoicer(
            client_id=triage["extracted_fields"]["client_id"],
            line_items=triage["extracted_fields"]["line_items"],
        )

    return {"action": "notify_only", "data": triage}

That's the whole orchestrator loop. Fewer than 20 lines of real logic, and it scales to as many specialists as you want to bolt on later.

When this pattern is overkill (and when it isn't)

I'll be honest about the limit. If you're sending fewer than ~50 Claude calls a day and your conversations don't accumulate state, a single-agent setup is fine. The orchestrator pattern adds engineering overhead — schemas, validation, logging per specialist. It's worth it when any of these are true:

• You're spending more than $30/month on Claude API
• Any single workflow touches more than two distinct domains (email + billing, calls + CRM, etc.)
• You've seen the model contradict itself between turns
• The work touches money, customer data, or external sends — anywhere a hallucination costs you

If none of those apply yet, build the orchestrator file anyway. Keep it empty. The moment your second use case shows up, you slot it in instead of bloating the first agent.

Why bizflowai.io helps with this

This orchestrator-plus-sub-agents pattern is what runs under the hood for the small-team automations I deploy through bizflowai.io — email triage that hands off to lead scoring, lead scoring that hands off to CRM updates, billing flows that stay quarantined from everything customer-facing. Clients see the result (lower bills, faster responses, no weird hallucinations in invoices); the architecture stays out of their way. If you're already running a single bloated Claude session and the numbers in this post look familiar, the migration is usually one or two weekends of work, not a rewrite.

Frequently asked questions

What is the orchestrator plus sub-agents pattern in Claude?

It's an architecture where one coordinator agent receives incoming work and routes it to specialized sub-agents instead of doing the work itself. Each sub-agent has its own isolated context window (usually under 8,000 tokens) focused on a single job like email triage or invoice drafting. The orchestrator hands off only the relevant context and merges results, keeping every agent lean.

Why does a single Claude session get slower and more expensive over time?

A single Claude session drags every previous message into every new turn. By the end of a workday, the session can hold 150,000 to 180,000 tokens of accumulated context. Every new request is compared against that entire history, so you pay input tokens on the whole backlog each time. Latency climbs, accuracy drops, and the model starts contradicting itself because it's drowning in its own history.

How do I build a Claude orchestrator and sub-agent system?

Start by writing a short orchestrator definition (under 90 lines of markdown) that lists available sub-agents, their strengths, and routing rules. Its job is to read input, pick the right specialist, and prepare a clean handoff payload containing only what that specialist needs. Then build your first sub-agent for the noisiest task, like email triage, with no conversation memory and a single, narrow responsibility.

What results can you expect from switching to sub-agents?

In one production system, moving from a single bloated Claude session to six specialized sub-agents reduced API spend from around $140 a month to about $52. Email triage latency dropped from 14 seconds per message to 3. Invoice hallucinations basically disappeared because the drafter never sees confusing email content, and debugging became easier since failures can be traced to one specific specialist.

When should I use sub-agents instead of one Claude assistant?

Use a single Claude assistant for personal use or simple one-off chats. Switch to an orchestrator plus sub-agents pattern when running anything in production, especially workflows handling multiple distinct jobs like email triage, lead scoring, and invoice drafting. If your API bill is climbing, latency is growing, or the model is forgetting instructions it followed earlier, the architecture, not the prompt, is the problem.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.