Budget vs premium models on real PHP/TypeScript tasks

Update, July 2026 — The setup described here (Kilo Gateway, MiniMax 2.5) dates from that period and isn’t my daily driver anymore — I’ve gone back to Claude Code (Max subscription, see Anthropic, the Apple of AI). The principle of routing by task type still holds.

Since migrating to Kilo Code CLI (a fork of OpenCode) with Kilo Gateway, I’ve been using MiniMax 2.5 and Claude Sonnet in parallel on the same Symfony/TypeScript project, routing sessions based on the nature of the task. Here’s what this real-world comparison produces as data — not HumanEval benchmarks, but deliverables that colleagues reviewed without knowing which model generated them.

The comparison context

Project: Symfony 7 + API Platform 3 application on the backend, TypeScript React 18 on the frontend. Roughly 80k lines of existing code, PHPUnit + Vitest test suite. Sessions run via Kilo Code CLI with Kilo Gateway for free models and the Anthropic API for Sonnet.

Empirical methodology: we observe whether PR reviews flag unusual issues depending on the model used.

Where budget models are indistinguishable from Sonnet

PHPUnit unit tests

This is the task where the difference is most insignificant. MiniMax 2.5 understands PHPUnit patterns, generates correct data providers, mocks dependencies consistently with the project’s MockObject pattern. The correction rate in review is comparable to Sonnet.

// Example test generated by a budget model — indistinguishable from a Sonnet test
// on this type of structured task
public function testCalculateDiscountWithExpiredCoupon(): void
{
    $coupon = $this->createMock(Coupon::class);
    $coupon->method('isExpired')->willReturn(true);

    $this->expectException(ExpiredCouponException::class);
    $this->calculator->calculate(100.0, $coupon);
}

Doctrine fixtures

Generating test fixtures for entities with relationships — the budget model follows project conventions as well as Sonnet. Same result, zero cost via Kilo Gateway.

DTOs and Value Objects

Typed structures without complex logic. MiniMax produces clean PHP 8.3 (readonly, named arguments, union types), respects existing Symfony serialization annotations.

Mechanical refactoring migrations

Mass method renames, adding types to existing signatures, extracting interfaces from concrete classes when the pattern is obvious.

Frontend TypeScript

Types, interfaces, standard React hooks, components without complex business logic. Budget models know modern TypeScript and React patterns well — the output is clean.

Where Claude Sonnet maintains a real edge

Debugging unexpected behaviors

This is the category where the difference is most pronounced. When a service produces inconsistent results depending on context — a race condition, a Doctrine cache issue, an API Platform behavior that depends on the active serialization group — Sonnet finds it faster and with more precision.

Budget models often identify the problem area but propose solutions that fix symptoms rather than the cause. It’s frequent enough that we established a rule: non-trivial debugging → Sonnet directly.

Refactoring with interface constraints

When you need to refactor a service while preserving multiple, sometimes contradictory constraints — unchanged public interface, compatibility with 3 existing consumers, no regression on integration tests — Sonnet handles the complexity of simultaneous constraints better. Budget models tend to optimize for one constraint at the expense of another.

Architecture and design

“Propose an architecture to decouple the payment module from the notification module without breaking the existing interface” — Sonnet produces a more nuanced proposal that better integrates implicit constraints you didn’t formulate.

Complex legacy code

On aged code with mixed conventions and undocumented couplings, Sonnet better understands the implicit context.

The concrete impact

Over a typical dev week, the session ratio by type:

Mechanical tasks (tests, DTOs, migrations)  : ~65% of sessions → MiniMax 2.5 (free via Kilo Gateway)
Long-context tasks (full modules)           : ~20% of sessions → Gemini Flash
Reasoning tasks (debugging, architecture)   : ~15% of sessions → Claude Sonnet

With Kilo Gateway, the 65% of mechanical tasks cost nothing. The bill comes down to Sonnet and Gemini Flash sessions.

What this is not

This isn’t an argument for always using the cheapest model possible. Intelligent routing is the opposite of blind frugality — it’s spending exactly what the task justifies, no more, no less.

It’s also not a definitive benchmark. Models evolve fast. What’s true today may no longer be in six months. The right habit is to test periodically, not to carve a decision in stone.

What it is: empirical confirmation that inference cost is a variable you can optimize without sacrificing quality — as long as you route consciously rather than using the same model for everything.

This routing changes nature once it’s no longer a personal bill to optimize but a team budget to allocate. The question stops being “which model is cheapest” and becomes “where do we spend for maximum quality, and where do we accept a budget model” — no compromise on risky work (auth, payments, data migrations), a budget model is fine for boilerplate. An explicit routing policy, written down somewhere, beats every dev making that call alone.

Guide: optimizing your AI workflow costs