I orchestrate LLM pipelines every day, and I have paid for both mistakes. In June, a fan-out of worker agents silently inherited my most expensive model and burned 2.1 million tokens in a single day. Three sessions died at the rate limit before I found it. The same month, a set of cheap models running precisely-scoped single tasks found four launch blockers in a subscription audit. The expensive part was never the loop. It was not knowing when the loop was needed.

Single LLM call vs agent loop, side by side

What actually separates an agent from a single LLM call?

An agent is a loop: the model picks an action, a tool runs it, the result goes back into the context, and it repeats until the goal is met. A single call is a function: input in, output out, and the control flow stays in your code.

That is the whole distinction. It is not about tools, and it is not about intelligence. Anthropic's Building Effective Agents draws the same line: "workflows" are LLMs and tools orchestrated through predefined code paths, while agents direct their own process. A surprising number of production "agents" are single calls wearing a trench coat, and they would be faster, cheaper, and easier to test if they admitted it.

# Single call: control flow lives in YOUR code
      result = llm.call(prompt, tools=[search], output_schema=Ticket)
      save(result)

      # Agent: control flow lives in the MODEL
      while not done:
          action = llm.decide(context)        # model picks the next step
          observation = run_tool(action)      # you execute it
          context.append(observation)         # context grows every loop
          done = action.is_final

The second shape is strictly more powerful. It is also slower, pricier, and harder to debug. Power you do not need is just cost.

When does a single LLM call win?

A single call wins whenever the task is a transformation with a known shape: classify, extract, summarize, rewrite, generate. If you can describe the output schema, you do not need an agent.

The test I use: can I write the steps down before runtime? "Read the support ticket, pull out product, severity, and sentiment, return JSON" is a known shape. So is "summarize this PR diff" and "turn this schema into TypeScript types". Chain three of those and you have a pipeline, not an agent. The control flow is still yours.

import json
      import anthropic

      client = anthropic.Anthropic()

      ticket_schema = {
          "type": "object",
          "properties": {
              "product": {"type": "string"},
              "severity": {"enum": ["low", "medium", "high"]},
              "sentiment": {"enum": ["angry", "neutral", "happy"]},
          },
          "required": ["product", "severity", "sentiment"],
          "additionalProperties": False,
      }

      # One request. Schema enforced by the API, not by hope.
      response = client.messages.create(
          model="claude-haiku-4-5",  # cheap and fast; extraction needs no genius
          max_tokens=256,
          messages=[{"role": "user", "content": ticket_text}],
          output_config={"format": {"type": "json_schema", "schema": ticket_schema}},
      )
      ticket = json.loads(response.content[0].text)  # guaranteed to match the schema

The tooling for this got quietly excellent. OpenAI has guaranteed schema-conforming output via Structured Outputs since August 2024. Anthropic shipped the same capability in November 2025. If your reason for wanting an agent is "the output is messy", one call already fixes that.

You get fixed cost, predictable latency, easy retries, and cacheable results. You can write a normal unit test against it. None of that survives once a loop decides its own path.

When do you actually need an agent?

You need an agent when intermediate results change the plan. Debugging a failing build, researching a question across sources you cannot enumerate up front, operating a browser, migrating a codebase. If step 3 depends on what step 2 found, that is agent territory.

The structural tell: your list of steps keeps collapsing into "it depends". A single call cannot react. An agent exists to react. This is the ground that OpenAI's Agents SDK, Anthropic's Claude Agent SDK, LangGraph, and CrewAI all compete on.

MAX_STEPS = 12  # an agent without a cap is an outage

      for step in range(MAX_STEPS):
          action = llm.decide(context, tools=[read_file, run_tests, edit_file])
          if action.is_final:
              break
          observation = run_tool(action)
          context.append(observation)
          log(step, action, observation)  # agents fail silently otherwise

Respect the compounding math before you commit. A model that gets each step right 95% of the time finishes a 10-step task correctly about 60% of the time (0.95^10 = 0.599). That is why serious agent frameworks spend most of their surface area on retries, checkpoints, and verification, not on the loop itself.

What does the cost difference look like in practice?

Agents multiply tokens, they do not add them. Every step re-sends everything before it. So a 10-step loop costs roughly 1 + 2 + ... + 10 = 55 units of the first call's tokens, not 10, before the tool outputs even land. The growth is quadratic, not linear.

My June incident is the sharp version of this. A bulk audit fanned out worker agents, and every worker silently defaulted to the top-tier model I reserve for orchestration. Nothing was broken. Every worker just cost about 5x what it should have, on growing context, in parallel. 2.1 million tokens in one day, three dead sessions at the rate limit.

There is a reliability cost hiding in the same place. Chroma's Context Rot research tested 18 frontier models and found accuracy degrades as input grows, long before the context window is full. A loop that keeps re-feeding its own transcript pays that tax on every step.

Two rules came out of that bill:

  1. Pin a model per role. The expensive model designs the questions and judges the answers. Cheap models execute the steps. My best audit result came from cheap workers running single tasks that a strong model scoped for them.
  2. Budget the loop, not the project. Cap iterations and tokens per run. An agent that cannot exceed its budget cannot surprise you on the invoice.

Anthropic's own advice to builders points the same way: find "the simplest solution possible", and only add complexity when it demonstrably pays for itself. Coming from the company selling the tokens, that is worth taking seriously.

How do you decide? A checklist

Default to the single call. Escalate to an agent on evidence, not on vibes.

Decision flowchart: single call, pipeline, or agent

  1. Write the steps down. If you can, ship a single call or a fixed pipeline of calls.
  2. Schema first. If the output has a shape, enforce it with structured output or a strict tool schema.
  3. If intermediate results must steer the plan, build the loop. Cap iterations and budget tokens on day one.
  4. Pin cheap models on workers. Keep the expensive model for planning and judging.
  5. Log every step. When an agent goes wrong, the transcript is the only debugger you have.

The question was never which one is better. A single call is a function. An agent is a process. You would not spawn a process to add two numbers, and you would not write one function to run your CI. Match the shape of the tool to the shape of the task, and most of the 2026 version of this argument disappears.

Default to the single call. Tell me in the comments where that rule breaks for you.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or [email protected].

Get the next one in your inbox → subscribe at astraedus.dev.