Cheap models are not always cheap once workflow debugging is counted

fgghyyfk

I run a small cross-border import business. My background is a bit mixed: I did frontend work years ago, then product/UED, and since 2014 I have mostly been dealing with operations, process, people and cost.

AI pulled me back into building internal tools this year.

The first thing I tried to build was not a toy chatbot. I wanted an internal workflow for operations: different product categories, different compliance rules, different memories, and several agents handing work to each other.

My early assumption was simple: use cheaper models wherever possible, and only pay for expensive models when absolutely necessary. In practice, that was too naive.

For small tasks, cheaper models worked well: category classification, forbidden-word checks, simple extraction, narrow input and narrow output. Those are easy to test and easy to roll back.

But when I used cheaper models for multi-agent workflows with external memory, things became expensive in a different way. Context from category A would leak into category B, handoffs between agents became messy, and I spent hours trying to debug whether the problem was the prompt, the memory layer, tool calls, retries, or the model itself.

One small GLM experiment also surprised me on cost. The lesson was not “GLM is expensive”; it was that uncontrolled context, retries and tool calls can make even a supposedly cheap setup painful.

My current rule is:

• cheap models or relay providers for narrow, verifiable, low-risk tasks;
• Claude/Codex-style tools for long-context, multi-agent, business-critical workflows;
• never put core workflows on a provider path I cannot inspect, log, or replace.

The question I am still testing: where do you draw the line? At what point is saving tokens more expensive than just paying for the model that saves debugging time?

plumberg

Start saving by not wasting tokens to write this