On January 20, 2025, a Chinese lab named DeepSeek released R1, an open-weight reasoning model published under an MIT license—and the price of "thinking" AI quietly fell off a cliff. For most of 2024, step-by-step reasoning was a premium, closed-API privilege you rented by the token from a single vendor. R1 arrived with frontier-class reasoning on hard math and code benchmarks, open weights anyone could download and self-host, and API pricing that undercut the incumbents by an order of magnitude. Whether DeepSeek's numbers hold up under scrutiny matters less than the precedent: open-weight reasoning is now a thing that exists, and it is cheap. As the CTO at Softechinfra, I do not think the durable lesson here is "switch to R1." Models churn; this one will be old news soon enough. The durable lesson is that the math underneath every AI feature decision just shifted, and the teams who internalize the new math will keep making good calls long after R1 is a footnote. This guide is about that math.
What Actually Changed on January 20
It helps to be precise about what R1 changed and what it did not, because the headlines blurred the two.
What changed is the floor. Reasoning—models that spend extra compute "thinking" before answering, which dramatically improves accuracy on multi-step problems—is no longer something only one or two vendors can sell you at a premium. There is now a credible open-weight option you can run on your own hardware, fine-tune, and inspect. That puts downward pressure on every reasoning API price and removes the assumption that capable reasoning must be expensive and rented.
What did not change is the hard part of shipping AI: your data pipeline, your evaluation harness, your guardrails, your latency budget, and your product surface. A cheaper model makes the inference line item smaller. It does nothing for the 80% of the work that was never about the model. Teams that treated "which model" as the whole problem were already in trouble; R1 just makes that more obvious.
The New Unit Economics of an AI Feature
Most teams reason about AI cost as a single per-token number. That is the wrong unit. The right unit is fully-loaded cost per successful task—the all-in cost to get one usable result, including the retries, the failures, and the human review you still need. Break it into four parts:
Inference cost
Tokens in and out, multiplied by price. Reasoning models burn far more output tokens than they appear to, because the hidden thinking counts. This is the line a cheaper model lowers.
Failure cost
What a wrong answer costs you—reruns, bad data downstream, an angry customer, a support ticket. A cheap model that fails more often can be more expensive per successful task than a pricier one.
Oversight cost
Human review, verification, and the eval infrastructure that catches regressions. This is fixed engineering work that no model launch removes.
Switching cost
The price of re-prompting, re-evaluating, and re-validating every time you change models. The higher this is, the less any single price drop is worth to you.
The trap is optimizing inference cost in isolation. A model that is 90% cheaper per token but needs three attempts and a human check to land one good answer has not saved you 90% of anything. Always compute cost per successful task, and always include the work the model never touches.
The Build-vs-Buy Decision, Reframed
Before R1, "build" mostly meant "you cannot have frontier reasoning on your own infrastructure, so buy the API." Open-weight reasoning removes that constraint, which means the build-vs-buy question is now a real decision again rather than a foregone conclusion. Here is the framework I use with our clients.
| Factor | Lean toward buying (managed API) | Lean toward self-hosting (open weights) |
|---|---|---|
| Volume | Spiky, low, or unpredictable traffic | High, steady, predictable throughput |
| Data sensitivity | Data can leave your boundary safely | Data must never leave your infrastructure |
| Team capability | No GPU or MLOps muscle in-house | You can run and monitor inference reliably |
| Latency control | Vendor latency is acceptable | You need to tune and guarantee response times |
| Customization | Off-the-shelf behavior is fine | Fine-tuning on your domain is a real advantage |
The most expensive mistake is self-hosting for the wrong reason. Open weights look free, but a self-hosted reasoning model carries GPU rental or capital cost, on-call engineering, capacity planning, and the opportunity cost of the team that could have shipped product instead. For a startup doing thousands of requests a day, a managed API almost always wins on total cost despite the higher sticker price. Self-hosting earns its keep at steady high volume, under a hard data-residency requirement, or when fine-tuning on proprietary data is a genuine moat. We walk through the self-host economics in more depth in our analysis of how R1 reshaped the AI landscape; the short version is that "free weights" and "free to run" are very different sentences.
A Decision Path You Can Reuse
When any cheap, capable model lands—and another one always will—run this sequence instead of reacting.
1. Define the task and its success bar
Write down what a correct output looks like and what a wrong one costs. You cannot compare models without a target.
2. Build a small eval set first
Twenty to fifty real examples from your domain with known-good answers. This is the single highest-leverage hour you will spend, and it outlives every model.
3. Run candidates through the same harness
Score the new model and your incumbent on identical inputs. Leaderboard rank is not your task; your eval set is.
4. Compute cost per successful task
Inference plus failure plus oversight—not just the per-token sticker. Compare on this number alone.
5. Decide, behind an abstraction layer
Route to whichever wins, through a thin interface so the next switch is a config change, not a rewrite.
That eval set in step two is the asset that survives. Models are disposable; a clear definition of "good" for your specific task is the durable infrastructure. We learned this building the AI scoring in ExamReady, our exam-prep platform—the moment we had a fixed set of graded answers to test against, swapping or upgrading the underlying model became a measured decision instead of a leap of faith. The same discipline underpins the production patterns we cover in our guide to building AI features.
Designing for a World Where Models Are Cheap and Disposable
If the lesson of January 2025 is that capable models keep getting cheaper and more interchangeable, the architectural response is to make models the easy part to replace. Four principles hold regardless of which lab is on top next quarter.
- Abstract the model behind an interface. Your application should call "reason about this," not a vendor-specific endpoint. The cost of switching models should be a config line, not a sprint.
- Own your evaluation harness. The model is rented; your eval set is owned. It is what lets you adopt a price drop in an afternoon instead of fearing it for a month.
- Keep your data portable. Prompts, embeddings, and fine-tuning data structured so they are not welded to one provider's format.
- Separate reasoning from the rest. Use an expensive reasoning model only where the task genuinely needs multi-step thinking; route simple calls to a cheap, fast model. Most "AI features" are 20% hard reasoning and 80% routine.
This portability mindset is also the antidote to vendor lock-in—a risk that gets sharper, not softer, as the model layer commoditizes. When switching is cheap, no single vendor can hold your roadmap hostage on price or availability. It is the same engineering discipline that turns a flashy demo into a dependable system, the gap between an impressive proof of concept and a maintainable product that, candidly, decides most AI projects. (For the longer founder's-eye view on building durable software in a fast-moving field, I keep notes on Vivek Singh's tech blog.)
What to Actually Do This Quarter
R1 is a useful forcing function, not an emergency. If you have an AI feature in production or on the roadmap, the productive response is unglamorous:
The pace of model releases is not going to slow down. There will be a cheaper, stronger model next month, and another after that. The companies that benefit are not the ones who panic-migrate on every launch—they are the ones whose architecture treats the model as a swappable component and whose decisions run on cost per successful task rather than headline pricing. Build that foundation once and every future launch becomes an opportunity instead of a fire drill. If you want help designing AI features on economics that survive the churn, that is exactly the kind of work we do.
Build AI Features on Economics That Last
We help teams ship AI features with the right model strategy, an eval harness you own, and an architecture that makes the next model launch a config change—not a rewrite.
Explore Our AI Automation Services → Talk to Our Team →
