How expensive are tool and agent cascades?

One user action can create a surprising number of model calls without anything going wrong. In fact, this is more and more becoming the norm;

Example:

• A user uploads a PDF and says, “Build this.”

  • One model reads it.

    • A tool extracts the PDF.

      • A planning agent decides what needs changing.

      • Coding agents write the backend, frontend and tests.

      • A reviewer checks the code, finds a problem and sends it back.

      • The code gets fixed and reviewed again.

  • The user made one request.

  • Behind it, the system may have made 20+ model calls.

  • Thats a tool/agent cascade: one request turns into tools, subagents, reviews and more calls.

Interestingly, LLM providers describe parts of this behaviour differently:

• OpenAI uses “parallel tool calls” when one model turn invokes several tools or functions.

• Anthropic uses “parallel tool use”, and for delegated work it also talks about subagents, parallel subagents and agent teams.

• Google Gemini uses “parallel function calling” when several independent functions are invoked in the same turn.

Those terms are all useful, but they describe slightly different parts of the same cost problem. For Culpa, we’re going to call the broader pattern a tool/agent cascade: one customer action that causes a branching sequence of tool calls, model calls, subagents or agent steps, each of which can create more work underneath it.

That is fundamentally different from a retry. A retry repeats work because something failed. A cascade multiplies work because the system was designed to branch. Parallel tools, subagents and agent teams are often exactly what make an agent useful. The problem starts when nobody is measuring the economics of the whole cascade.

In our example above, one customer action starts with a PDF upload, then triggers PDF extraction, planning, multiple coding subagents, testing, code review, repairs and another review. The user made one request, but the workflow can easily create 20+ model calls before we count any retries.

That's the tool/agent cascade we care about in this post: the cost of all the work sitting behind one customer action.

Now imagine the reviewer rejects the first answer and sends part of the workflow around again.

The customer still sees one result and your bill the bill sees the full cascade.

For agentic products, the more useful denominator is calls per successful customer action; if 1,000 completed jobs previously required 8,000 model calls and now require 14,000, something important changed even if the number of customers and completed jobs stayed exactly the same.

The next question is whether those extra calls are earning their keep.

A research workflow that sends subagents in parallel may produce a better answer and that can be worth paying for but only if its materially better. A reviewer that calls another frontier model three times but almost never changes the result deserves a closer look and likely isn't worth the cost bump.

This is one of the reasons Culpa tracks cost below the conversation level. A single conversation can contain several workflows, and one workflow can produce a cascade of agents, tools and dozens of model calls. If you stop at total conversation cost, you still don’t know which branch spent the money.

The goal isn’t to minimise every cascade. Instead, its to know when one request became 27 calls, why it became 27 calls, and whether those extra 26 calls were worth paying for.

If you run agents in production today, do you know your average model calls per successful customer action?