DEV Community

Cover image for I thought switching from Claude to GPT would fix my agent chaos, but the real fix was cutting turns to 8
Lars Winstand
Lars Winstand

Posted on • Originally published at standardcompute.com

I thought switching from Claude to GPT would fix my agent chaos, but the real fix was cutting turns to 8

If you're trying to reduce Claude API costs, or really any LLM bill, start by cutting agent turns before you start benchmarking another model.

That sounds too simple.

It also fixes more broken agent workflows than most model swaps do.

I keep seeing the same pattern:

  • agent starts rambling
  • two sub-agents keep handing work back and forth
  • tool calls multiply
  • somebody starts a GPT vs Claude vs Grok comparison spreadsheet

Sometimes the model really is the issue.

Most of the time, the agent just has too much freedom to keep talking.

And if your stack is OpenAI Agents SDK, LangGraph, OpenClaw, n8n, Make, Zapier, or a custom workflow, that freedom gets expensive fast.

The problem usually isn't intelligence. It's turn budget.

A lot of "bad model behavior" is really this:

  • no hard stop condition
  • too many handoffs
  • shared memory leaking across tasks
  • graph cycles
  • agents deciding for themselves whether they are done

That last one is where money goes to die.

If an agent takes 30 turns to finish a 5-turn job, switching from Claude Opus 4.6 to GPT-5.4 might make it sound smarter while it wastes your budget more eloquently.

The OpenClaw example that made this click for me

I found a thread on r/openclaw where someone described a kind of "council of minions" setup with shared memory and persistent identities.

Then the agents started talking to each other and generated an architecture document on their own.

Cool demo.

Also a perfect example of how multi-agent systems drift into conversational sprawl.

One commenter nailed it: the agents weren't inventing some magical fake society. The wiring made that behavior possible. Shared memory, routing, identity, and persistence create more opportunities for back-and-forth.

That's the real issue.

Once you build a system that allows extra turns, you don't have a model problem first.

You have a control problem.

The docs are actually pretty clear about this

The nice thing about being opinionated here is that the official framework docs mostly agree.

OpenAI Agents SDK: cap the loop

OpenAI's Agents SDK treats a turn as one AI invocation. Tool calls can happen inside that turn.

If you exceed the limit, it raises MaxTurnsExceeded.

That means the official answer to runaway agents is not "pick a better model." It's "stop the loop."

from agents import Runner

result = Runner.run(
    starting_agent,
    input="Summarize the incident and propose next steps",
    max_turns=8,
)
Enter fullscreen mode Exit fullscreen mode

That max_turns=8 line is doing more reliability work than a lot of teams realize.

LangGraph: inspect your graph before blaming the model

LangGraph is even more blunt.

If you hit the recursion or step limit, the docs point you toward graph logic and cycles.

The classic failure mode is boring:

  • node a routes to node b
  • node b routes back to node a
  • now your agent is "reasoning" forever

Install/update:

pip install -U langgraph
Enter fullscreen mode Exit fullscreen mode

Then you might see something like this:

graph.invoke(payload, {"recursion_limit": 1000})
Enter fullscreen mode Exit fullscreen mode

A higher limit can be correct for a complex workflow.

But if you hit that ceiling unexpectedly, the first question is not whether Claude is worse than GPT this week.

It's whether your graph has a cycle or a missing stop condition.

Anthropic's guidance is more conservative than most agent builders

Anthropic's engineering guidance on agents says to start with the simplest system possible and only add agentic complexity when you need it.

That matters.

They're basically telling you this:

  • don't build a tiny parliament of agents by default
  • try one well-structured LLM call first
  • accept that agentic systems trade cost and latency for flexibility

That's not anti-agent.

It's anti-unnecessary-agent.

And honestly, more teams need to hear that.

Model routing is useful. Model swapping as therapy is not.

I like multi-model orchestration when it has a real purpose.

Examples:

  • route coding tasks to GPT-5.4
  • route long-context synthesis to Claude Opus 4.6
  • route cheap classification to a smaller open model
  • use a fast model for triage and a stronger model for final answer generation

That's strategy.

But a lot of teams use model rotation like incense.

The workflow is haunted, so they wave another model at it.

Usually the haunting is just bad orchestration.

Where these frameworks usually break

Framework What it gives you What usually breaks
OpenAI Agents SDK Explicit max_turns, tool use, handoffs, structured agent runtime Agents keep calling each other because nobody enforced a hard ceiling
LangGraph Deterministic orchestration plus LLM-driven steps, recursion controls Cycles, step explosions, and missing termination logic
OpenClaw Sessions, memory, multi-agent routing, persistent chat-style behavior Conversational sprawl and identity-driven back-and-forth

Notice what's missing.

None of these frameworks say the first fix is switching from Claude to GPT.

They all give you structural controls.

That should tell you where to look first.

A quick smell test for agent chaos

If your agent does any of these, assume orchestration is guilty until proven innocent:

  • repeats the same reasoning in slightly different words
  • re-asks a tool for data it already has
  • hands work between agents without reducing uncertainty
  • keeps debating after the output is already good enough
  • reads shared memory that has nothing to do with the current task
  • fails only when you add more agents, not when you improve the prompt

That is not "emergent intelligence."

That is a loop with branding.

What I would fix before touching model selection

Here's the actual playbook.

1. Set a hard turn budget

Start lower than feels comfortable.

If the workflow can't finish in 6 to 8 turns, that's useful information.

result = Runner.run(
    starting_agent,
    input=user_request,
    max_turns=8,
)
Enter fullscreen mode Exit fullscreen mode

If 8 is too low for your use case, increase it deliberately.

Don't leave it effectively unbounded.

2. Make stop conditions explicit

"Done" should not mean "the model feels done."

It should mean something deterministic happened.

Examples:

  • a JSON field was populated
  • a tool returned a valid result
  • a validator passed
  • a SQL query executed successfully
  • a human approval flag was set

Pseudo-code:

if result.status == "complete" and result.payload.get("summary"):
    return result
else:
    retry_or_fail()
Enter fullscreen mode Exit fullscreen mode

3. Reduce handoffs

Every handoff is another chance for confusion.

If two agents can be replaced by:

  • one stronger prompt
  • one tool call
  • one validator

then do that.

A lot of multi-agent designs are really single-agent tasks wearing a trench coat.

4. Split memory by task

Shared memory sounds smart until yesterday's debugging session leaks into today's invoice parser.

Use session boundaries.

Use scoped memory.

Delete irrelevant context aggressively.

Bigger context windows are useful, but they do not forgive sloppy memory design.

5. Put deterministic code around the model

Use code for:

  • routing
  • validation
  • deduplication
  • retries
  • termination
  • budget enforcement

Use GPT-5.4 or Claude Opus 4.6 for judgment where judgment is actually needed.

Don't ask the model to decide whether the loop itself should exist.

A minimal before/after example

Here's a simplified version of the kind of thing I see.

Bad version

while True:
    response = agent.run(task)

    if response.needs_research:
        task = search_agent.run(response.query)
    elif response.needs_review:
        task = reviewer_agent.run(response.draft)
    else:
        task = response.output
Enter fullscreen mode Exit fullscreen mode

Problems:

  • no max iteration count
  • no deterministic success criteria
  • handoffs can bounce forever
  • every step creates more surface area for drift

Better version

MAX_STEPS = 8

for step in range(MAX_STEPS):
    response = agent.run(task)

    if response.final_answer and validate(response.final_answer):
        return response.final_answer

    if response.tool_request:
        tool_result = run_tool(response.tool_request)
        task = merge_context(task, tool_result)
        continue

    if response.needs_handoff and step < 4:
        task = specialist.run(response.handoff_payload)
        continue

    break

raise RuntimeError("Agent failed to complete within step budget")
Enter fullscreen mode Exit fullscreen mode

Still not perfect.

But now the workflow has boundaries.

That's usually what fixes cost and reliability together.

When the model really is the problem

To be fair: sometimes the model is the bottleneck.

You may need to switch if you need:

  • better instruction following
  • stronger tool use
  • better coding ability
  • longer-context reasoning
  • more reliable structured output

There are absolutely workloads where GPT-5.4 beats Claude Opus 4.6, and others where Claude wins.

Same for Grok 4.20 or smaller open models in the right role.

But if your workflow is doing duplicate work, looping, or spawning endless back-and-forth, better models mostly help you fail more expensively.

The hidden cost nobody talks about

People obsess over model pricing and ignore behavioral pricing.

Behavioral pricing is what happens when:

  • a 4-turn task takes 40 turns
  • a memory-heavy agent keeps dragging old context forward
  • a graph retries the same path with no new information
  • multi-agent chatter creates cost without improving output

That hidden cost is why teams get stuck in endless AI model switching cost analysis.

They compare vendors for two weeks while the real bug is a missing stop sign.

This matters even more if you're paying per token

If you're on traditional per-token billing, every extra turn hurts twice:

  • latency goes up
  • cost goes up

That's why agent teams end up with token anxiety.

You start monitoring usage instead of improving the workflow.

For teams running agents 24/7 in n8n, Make, Zapier, OpenClaw, or custom automations, this gets old fast.

A flat-cost setup changes the tradeoff a bit because you can focus more on orchestration quality and less on every single token spike.

That's one reason Standard Compute is interesting for agent-heavy workloads: it's a drop-in OpenAI-compatible API with unlimited compute at a flat monthly price, so you can route across models like GPT-5.4, Claude Opus 4.6, and Grok 4.20 without living inside a cost dashboard.

That doesn't remove the need for good agent design.

It just means bad turn discipline won't surprise you with a giant bill while you're fixing it.

My default rule now

When an agent gets weird, I ask this before I ask anything about models:

Why was it allowed to keep talking?

That question catches more bugs than another round of GPT vs Claude debate.

If your agent is rambling, duplicating work, or arguing with itself, start here:

1. Cap turns
2. Add explicit stop conditions
3. Reduce handoffs
4. Scope memory
5. Audit graph cycles
6. Only then compare models
Enter fullscreen mode Exit fullscreen mode

It's not glamorous.

It is cheaper.

And in practice, it's usually the real fix.

Top comments (0)