Cheaper AI becomes a business advantage when customer knowledge and workflows can move with you.
Open models promise startups more choice. Imagine finding one that handles your customer support workload at a lower cost, then discovering that switching would mean rebuilding the product around it. The potential saving has become an engineering project.
For founders, the useful question is how much of the product can stay intact when the model changes. Keeping customer knowledge, operating rules and quality checks portable gives you a way to benefit from better suppliers as they appear. That flexibility deserves a place alongside speed and accuracy when you decide what to build.
Lower prices need an exit route
Open models make their trained parameters, often called weights, available for others to run. In Y Combinator’s Lightcone conversation, Ollama co-founder and CEO Jeffrey Morgan describes cost as the immediate attraction, with greater control and customization as longer-term ambitions.
His forecast makes the economics especially interesting. Morgan suggests open models could eventually handle 80–90% of a business’s tokens while accounting for perhaps 10–20% of its model spending. Tokens are the units of text models process and generate. This is the outlook of a supplier serving that market, rather than a measured split across businesses today.
The implication for a founder is that different parts of a product may deserve different suppliers. A routine support request and a complicated troubleshooting exchange do not necessarily need the same model. You can explore that possibility without committing the entire product to a migration.
However, cheaper processing must cover the work required to adopt it. The cost of switching computing platforms is a useful lens: include changes to integrations, staff training and the time spent checking that existing customers still get the service they expect.
Keep customer knowledge under your control
Morgan also identifies company knowledge, coordination and execution as problems surrounding the model itself. For a small software business, that suggests a practical place to start: examine where the product stores what it knows about customers and how it decides what to do.
Consider a hypothetical support assistant for an online retailer. It needs the current returns policy, the order record and any promise a colleague has already made. Keep those records accessible in systems you can export from, with clear ownership of updates, so a replacement model can receive the same information.
A newer model cannot repair a workflow that supplies yesterday’s policy. The distinction between a model’s training cutoff and its access to current information matters here: access to the right records should be a capability you can preserve when the model changes.
Apply the same thinking to actions. Let the model propose a refund, while your application checks the order, enforces the retailer’s rules and records the outcome. Keeping those checks in the application gives you a stable standard against which to judge a replacement.
This can start small. Keep instructions in files your team controls, document which records each task needs, and isolate the connection to the model. A young company can preserve useful choices without building an elaborate platform for every possible supplier.
Test a replacement on work customers pay for
Connecting to another model is only the first test. Ollama’s documentation shows how developers can use an OpenAI-compatible interface to call local models. That provides a practical connection route; it does not establish how well a replacement will handle your customers’ requests.
For the retailer, a convincing comparison would include a straightforward return, a missing order number, an exception requiring approval and a customer changing their request halfway through. Run both models against the same records and judge them against the same business rules.
Decide what success means before looking at the answers. A fluent response that promises an unauthorized refund should fail. A request that correctly reaches a human can succeed if escalation is the intended outcome.
Then compare the cost of finished work, including repeated attempts, staff corrections and waiting time. Also estimate the engineering effort needed to maintain the alternative. A lower token price matters when your product can use it without an expensive rebuild.
The result may justify moving only one task. Keep a stronger model for difficult troubleshooting while testing an alternative on routine classification, provided your checks support that split. A focused change gives the team evidence about savings and reliability before expanding its responsibilities.
The founder’s takeaway: make the next choice easier
Choose one recurring workflow and identify everything a replacement model would need to complete it: current information, instructions, permitted actions and a way to check the result. Try an alternative on historical or carefully prepared cases, record the full cost, and keep a clear route back to the existing service.
That exercise can pay off even if you keep your current supplier. You will know which dependencies make a move expensive and which improvements would give the business more choice. A useful alternative is one you have tested on your own work.
Y Combinator: Open Models Change The Economics of AI, featuring Ollama co-founder and CEO Jeffrey Morgan.
A lower token price matters when your product can use it without an expensive rebuild.
A useful alternative is one you have tested on your own work.

Sources
- Y Combinator — Open Models Change The Economics of AI — Jeffrey Morgan on cost and control at 02:13, the infrastructure surrounding models at 13:58, and his forecast for token volume versus spending at 17:28. The percentages describe a possible future, not measured market shares.
- Transcript — Open Models Change The Economics of AI — Morgan's statements were checked against the [episode transcript](https://podscripts.co/podcasts/y-combinator-startup-podcast/open-models-change-the-economics-of-ai). The retailer example and proposed evaluation process are independent analysis.
- Ollama documentation — OpenAI compatibility — [Ollama's official examples](https://docs.ollama.com/api/openai-compatibility) demonstrate calling local models through an OpenAI-compatible interface. Interface compatibility does not establish equivalent task performance.
Innohub TV
Watch this content also on Innohub TV
We picked clips from Innohub TV that continue the same topic.
