What's this about?
Calvin French-Owen spent a few weeks using gpt-5.6-luna, the small model in OpenAI's current line, and argues something changed: it runs at ~100 tokens per second, handles real work across a codebase and an email archive, and is hard to run a large bill on — searching thousands of emails costs tens of cents. His broader point is economic. Investors keep asking why there are so few consumer AI companies; his answer is token costs. The classic consumer playbook needs a product that is cheap to run at scale, and until now every AI request cost real money. With GLM-5.3 also sitting on the price/performance frontier, that constraint is lifting.
What is the "Pareto frontier" here?
Imagine plotting every model with cost on one axis and capability on the other. Some models are strictly worse than others — more expensive *and* dumber — and nobody should use them. The remaining models, where you cannot get cheaper without getting worse, form the frontier. "A new option at the Pareto frontier" means GLM-5.3 is not the best model or the cheapest, but at its price nothing beats it, so it becomes a real choice rather than a compromise.
What's the community saying?
- The loudest reaction is mild irritation: people without frontier-model expense accounts say they noticed small models were good enough a long time ago.
- A long sub-thread litigates the phrase "most tasks" — the counter-argument is that most of a working engineer's day is glorified autocomplete, but the memorable work is the hard algorithmic problem where frontier models still matter.
- Practitioners report a specific failure pattern with small models in agent loops: Luna gets stuck, over-assumes, persists in the wrong direction, over-engineers a throwaway script.
- A more useful distinction emerges from the thread: with a well-designed spec, a small model often produces *better* code; with a vague description, the frontier model guesses better.
- Several land on the conclusion the author gestures at — small models are excellent inside a good harness, which makes them an application-developer's tool rather than a researcher's.