A developer who has spent over $30,000 in API tokens since January across Codex, Claude, and GLM has a framework for understanding where LLMs stand in September 2026. The mental model is simple: there are two categories of models, and they serve fundamentally different purposes. The distinction matters for how you build, how you spend, and where you think the technology is going.
Instructions-Following Models Are Autocomplete With Guardrails
The first category is instruction-following models. The developer names Luna and Sonnet as examples. These are models that do exactly what you tell them and nothing more. They do not try to read between the lines. They do not make judgment calls. They execute instructions with precision but without initiative.
The developer used to call these models dumb, then realized that framing was wrong. The limitation is not intelligence. It is the absence of common sense reasoning. These models cannot tell you when your instructions are self-contradictory. They cannot infer that a requirement you forgot to mention matters. They cannot make the kind of soft judgment calls that experienced developers make without thinking.
But that limitation is also the point. If you make the core architectural decisions up front, if you define the interfaces, the data models, the error handling strategy, and the testing approach, then coding with an instruction-following model becomes autocomplete. You describe the next function, the model writes it. You describe the next test, the model writes it. The model does not need to understand the whole system. It needs to understand the next unit of work.
The economics reflect this role. Luna especially is cheap to run. The model processes tokens at a price point that makes it viable for large-scale code generation, test execution, and iterative refactoring. The developer describes these models as workhorses for pennies. The value is not in the model's judgment. The value is in the model's ability to turn your judgment into code at machine speed.
Frontier Models Make Tradeoffs
The second category is frontier models. The developer names Astra and Fable as examples. These are models with higher common sense reasoning, models that try to understand the intent behind your question rather than just parsing the literal text.
The key distinction is tradeoff-making. Software engineering is fundamentally about tradeoffs. Should this service be synchronous or asynchronous? Should this data live in a relational database or a key-value store? Should this error be retried or logged and skipped? An experienced developer makes these decisions based on context, constraints, and priorities that are rarely stated explicitly. A frontier model attempts to do the same thing.
The developer is clear that today's models are far from making the right human-like tradeoffs consistently. They sometimes pick the wrong tradeoff, sometimes miss a constraint that a human would catch, sometimes over-optimize for the wrong objective. But the attempt is the important part. An instruction-following model will not even try to weigh competing priorities. A frontier model will try, and it will get it right more often than not.
Frontier models also know how to orchestrate instruction-following models. This is a capability that sounds trivial but is not. A human manager delegates tasks to a team, reviews the output, and course-corrects when needed. A frontier model can do the same thing with instruction-following models: break a complex task into subtasks, assign each subtask to a capable model, review the results, and assemble the pieces into a coherent whole. The developer notes that humans get too lazy to do this kind of prescriptive orchestration consistently. The model does not get lazy.
The $30,000 Question
Spending $30,000 on API tokens in nine months is a significant investment. It is also a significant data point. The developer is not experimenting casually. He is running production workloads across multiple model families, comparing their behavior on real tasks, and building a mental model of where each one fits.
The spending pattern itself reveals the architecture. Cheap instruction-following models handle the volume work: code generation, test writing, refactoring, documentation. Frontier models handle the high-judgment work: architecture decisions, design reviews, complex debugging, strategic planning. The two categories are not competitors. They are layers in a stack.
This is the pattern that is emerging across the industry. Teams use expensive, capable models to make decisions and cheap, fast models to execute them. The frontier model writes the architecture plan. The instruction-following model implements the functions. The frontier model reviews the PR. The instruction-following model applies the fixes. The cost per decision stays low because the expensive model only touches the decisions that require judgment.
Where Common Sense Meets AGI
The developer's final observation is the one that matters most. He believes the path to AGI runs through common sense tradeoff-making. If a model can consistently make the same tradeoffs a human would make, given the same context and constraints, that is a meaningful milestone. Not because it means the model is conscious or sentient, but because it means the model can operate independently in the messy, ambiguous, tradeoff-rich environment where real software gets built.
Today's frontier models are not there yet. They make good tradeoffs more often than instruction-following models, but they still miss things that a senior developer would catch. They still occasionally choose the wrong abstraction, miss an edge case, or optimize for the wrong metric. The gap between "tries to make tradeoffs" and "makes the right tradeoffs consistently" is the gap that the next generation of models needs to close.
The practical implication for developers is clear. Build your systems so that the expensive model's judgment is applied where it matters most, and the cheap model's speed is applied everywhere else. That architecture works today, and it will work better as the frontier models improve. The $30,000 lesson is not about any single model. It is about understanding which model fits which job, and designing your workflow around that understanding.