Why I still don’t use Claude (and why a “cheap model” is enough for me)

In most discussions today, it feels like using advanced AI models has become a status signal:

higher usage, bigger bills, “Claude maxed out again”, etc.

But my experience has been a bit different.

I still primarily use a cheap model setup, and it has been enough for my workflow.

Here’s why.

1. I still consider myself the engineer

The core principle for me is simple:

The model is a tool, not the engineer.

As long as the model can:

• follow instructions
• generate decent code
• respect constraints

then it’s usable.

At the beginning, I mainly used ChatGPT web for coding because it was the most consistent option for instruction-following at the time.

Other tools existed, but they weren’t reliable enough in structured tasks.

2. Claude is good — but the limits are real

Claude is genuinely strong in many cases:

• good reasoning
• clean code generation
• strong long-context understanding

But in practice, there’s a constraint that matters a lot:

usage limits.

And once you hit that limit mid-flow, your workflow gets interrupted.

That alone changes how I evaluate tools.

3. Other models improved, but instruction-following is still inconsistent

Over time, more models started appearing — including some cheaper or open alternatives.

Some are fast. Some are cheap. Some are surprisingly capable.

But I consistently noticed a pattern:

• They say they will follow instructions
• But the actual output drifts
• They modify things I explicitly told them not to touch
• Tool usage is often simulated, not executed properly

That mismatch makes them harder to trust in structured engineering work.

4. The real requirement: predictable behavior

For my workflow, I don’t need the “smartest” model.

I need the most predictable one.

Because I usually work with:

• well-defined architecture
• strict boundaries on what should change
• clearly scoped tasks
• explicit instructions on where NOT to modify anything

In that setup, consistency matters more than raw intelligence.

Right now, tools like DeepSeek V4 / Flash via OpenCode are “good enough” for that.

They follow structure, respect context, and don’t overcomplicate changes.

5. Why I never “had to switch to Claude”

I often see developers talking about:

• hitting Claude limits
• paying high monthly bills
• relying heavily on Claude for everything

But in my case, I never reached that point.

Not because Claude is bad — it’s not.

But because:

my workflow is constrained enough that a cheaper model already satisfies the requirements.

And when the problem is well-defined, you don’t always need the most powerful tool — just the most reliable one.

6. The trade-off people miss

Yes, Claude can be better in many scenarios.

But the trade-off is simple:

• Better reasoning → higher cost + limits
• Good enough reasoning → stable + cheap + continuous usage

And for engineering work, continuity often wins.

Final thought

I don’t avoid Claude because it’s bad.

I avoid it because:

it is not the most cost-effective tool for the way I structure my work.

At the end of the day, I still believe this:

The best AI tool is the one that reliably follows your instructions — not the one that sounds the smartest.

And so far, for my use case, a cheaper model has been more than enough.