Back to Y Combinator

Open Models Change The Economics of AI

Y CombinatorSeptember 4, 202657m
Topics63
Open Models Address Cost and Customization in Enterprise AI0:00State of AI with Jeffrey Morgan of Ollama1:03Token Flow Data and Usage Trends1:30Chinese Models Dominate Cloud Usage2:00Cost as Entry Point to Customization2:00AT&T's 40% Shift to Open Models2:30Coding Agents and OpenClaw Drive Token Usage3:01Exponential Token Usage Growth3:30Context Window Expansion Enables Growth4:30Out-of-the-Box Open Models Take Off5:02Model Release Cadence Accelerating5:30AI Safety Creates Opportunity for Open Models6:30Open Models Excel at Security Testing7:30Ollama's Role in Model Launches8:30Deepseek's First Multimodal Model9:00Ollama Creates Legible Standards10:00Packaging Models with Hardware and Providers10:30Ollama as Operating System for AI11:30Building Technical Expertise12:33Reproducing the Five-Layer Cake for Open Models13:00Hidden Layers in the Stack13:30Unbundling Opportunities14:00Bundling vs Unbundling Dynamics15:00Coding Agents Reducing Lock-in16:00Memory as Stateful Problem16:30Future State: 80-90% Open Models17:30Cloud Computing Parallel20:00Local Models Mix with Cloud21:00Hybrid Execution Model for AI Workloads22:08Geographic Distribution of Model Usage23:01Nvidia's Open Source Strategy24:00Desktop AI Hardware Pricing24:31DGX Spark Capabilities25:32MLX Technology Stack26:30Local vs Cloud Coding Experience27:00GPU Market Dynamics27:30Developer Access Solutions28:30Startup Budget Optimization Strategy29:00Efficiency and Adoption Patterns30:00Model Orchestration Benefits31:00Model Architecture Philosophy31:31Frontier Competition Landscape33:00Geopolitical Considerations34:00Security and Model Integrity35:00Ollama Origins and Founding Story36:30Naming and Branding38:30Series A Pitch and Investment39:00Pre-Pivot Struggles40:01Critical Pivot Decision42:01Initial User Reception43:30Early Days and Initial Adoption44:22Rapid Growth and Product-Market Fit45:00Speedrun from Homebrew to Enterprise Adoption46:01Monetization Timeline and Business Model Development47:00Strategic Patience and Market Timing48:00Risks of Waiting and Customer Connection49:01Decision to Join YC and Second-Time Founder Perspective50:01Learning from Previous Companies and Team Experience51:31Breaking Old Infrastructure Analogies53:32Non-Determinism as a Feature54:30Building Services with Unknown Code55:01Curation and Integration Value56:00Closing57:00
In a Nutshell

Open models are now economically viable for enterprise AI because they solve the primary blocker of cost, with Chinese models dominating cloud usage and a 40% shift already seen at companies like AT&T. Token consumption is exploding 10-150x due to coding agents and coworker-style automation enabled by expanded context windows, driving demand for efficient orchestration layers above the models themselves. The long-term equilibrium is 80-90% open model usage with hybrid local/cloud execution, where frontier models handle only the hardest tasks while open models power the majority of work through specialized routing and coordination systems.

AI-Generated Notes

These notes were generated by AI and may contain inaccuracies.

Cost is by far the largest pain point that open models can jump in and solve. Every business has a vision of getting better control over AI and customizing it for their business, and that's really their north star. Cost is something they can solve in the short term, but it then enables them to customize these models for their unique use case.

Early 2024, there was lots of interest in fine-tuning your own custom models. Then it sort of went away and all of that it will just be wasted effort. It'll get stomped by the next model release. It seems like it's coming back now.

Ollama is used by 9 million developers, has 178,000 GitHub stars, and is used by 85% of the Fortune 500. Jeffrey Morgan, co-founder and CEO of Ollama, has a front seat to what models score highest on benchmarks and what developers actually download and keep using.

The biggest thing being seen is a shift to open models, especially in enterprise. This is from a mix of US and Chinese origin models, and it's predominantly driven by coding agents and also AI assistants more coworker cases like OpenClaw and Hermes.

Ollama sits in the token flow of so many tokens and has really good data on what models people are actually using and how it's changing. Ollama started as a way to run open models on MacBook or other hardware including Nvidia, AMD, Intel. Earlier this year, Ollama launched Ollama's cloud.

What is being seen on Ollama's cloud is that it's predominantly Chinese models right now of Chinese origin. But they're being accessed by businesses all over the world, especially US and Germany, which is actually a big source of where open model tokens are being accessed.

Cost is by far the largest pain point that open models can jump in and solve, but every business has a vision of getting better control over AI and customizing it for their business, and that's really their north star. Cost is something they can solve in the short term, but it then enables them to go and customize these models for their unique use case.

There was a great article in The Information yesterday from AT&T and it ends up they've already shifted 40% of their token consumption to open models. That's right now predominantly through US and Europe models, but they're also evaluating the Chinese models.

The workflows predominantly run are coding agents. From the extreme growth and per developer or per user token usage, it has predominantly been from coding agents. Earlier in March and April, OpenClaw took off and subsequently the Hermes project, the Hermes agent project, took off, which has then opened up that ability to automate a huge chunk of work over a long span of time to non-developers too, whether it's like finance or support or marketing or sales.

There is a graph of token usage by developer on Ollama's cloud showing the average amount of tokens they use per week. This is per developer, so the graph looks like it should be an aggregate of Ollama's growth, but this is actually the per user. On an individual user basis, how many tokens are they using a week?

There are two big inflection points. One is that initial runup at the start of the year which was driven by coding agents. Kimmy, the GLM models, Miniaax launched. Finally, there were open models that could power coding agents. Then in April, there was incredible growth from OpenClaw, which was then not just developers, but the rest of the world could take a hard problem, give it to an open model, and let it go complete the task, which obviously consumes a ton of tokens as it's figuring out what tools to use, what data to go fetch.

The context window went from 128K to a million plus with open models. All that enabled this explosive growth. It went from roughly 5x, so under somewhere around 15 million tokens before all these coworker type of use cases. That's about right for that OpenClaw jump seen in April. In aggregate it's in the 10 to 20x if not more as a whole. Through cloud, 150x growth was seen since the start of the year.

Open models in 2024-2025 from the large models being served were mostly being served as custom models. You'd take an off-the-shelf model like Deepseek or Kimmy and you'd fine-tune it for your use case, like for example Cursor had famously done, and from there you could serve that at scale. But seeing out-of-the-box open models being served, that really only took off at the start of this year.

The release of these models, the cadence is only speeding up, which makes it ever more harder to stay on top of that. The latest closed frontier models are releasing faster than ever. On the open source side it's getting faster and faster. This summer there have already been three iterations of the Deepseek Flash model as an example. What used to be more of a six-month cycle, the gap is closing.

This makes it even harder to custom train models. On the flip side, the tooling is getting better and so it allows teams that want to fine-tune their models to stay on top of it.

AI safety is becoming more and more of an issue at the Frontier Labs. The frontier may well slow down to figure out its alignment and containment issues, and meanwhile the open source models and open weight models are continuing to grow and get better.

The announcement and the release of the GLM-53 model and its capabilities from a cybersecurity standpoint being extremely impressive creates a big opportunity for whether it's startups or existing businesses in the security and governance space to really jump in and help. If you look at that AT&T article, largely the blocker to adopting open models is largely around security and safety. But from experience talking to customers, whether it's in Europe or here in the US, if you can solve the safety problems, by and large adopting the Chinese origin model labs is completely on the table.

Hugging Face had to use open weight models to actually even detect the hack from the frontier. A common question is where can open models be used that are leaps and bounds of an advantage over using a frontier closed model. One of the key use cases is security testing and making sure that your software is secure.

If you try to get Claude to like pentest your product, it will just refuse to do that. By and large, whereas there are literally obliterated security researcher models that you can find on Hugging Face that allow you to do it. There are ones that are custom trained to be even more liberal to go and attack these problems. But even the out-of-the-box models, they do come with safety training but they're a little better understanding if you're doing this for a good use case versus one that's more of a negative or malicious use case.

Because Ollama is such a key distribution channel for these models, typically the model developers are contacting Ollama before the general release to coordinate launches and stuff like that. Ollama often gets previews of what's about to happen and gets incredible growth spikes when a new model drops.

A successful day zero model launch playbook has been developed. There are a lot of things to get right. There's making sure that it's supported in your favorite inference engine, which is generally sometimes a multi-week process to make sure it's fast, to make sure it's accurate, to make sure it's up to spec with the reference. There's also finding the right use cases and harnesses for developers and users to make use of this model.

Deepseek launched their first multimodal model from a large model LLM standpoint. They had previously had some smaller OCR models, which unlocks a whole bunch of use cases. But what they also changed was the Deepseek harness, which launched recently so that it could support this capability.

Step two is then to find the harnesses, make sure they're prepared to actually run this model and to do that effectively. But every model's different. They all have different challenges and architecture changes and tool calling mechanics, and getting all this right is really hard. The key thing to do at the end of the day is to run benchmarks against the final product ahead of release and make sure that it's running as the research team at the lab specified.

One very important part Ollama plays in the whole ecosystem is creating a very legible standard to be able to make sure there's the best way to use the harness for each new model, each new tool call, and all of it is consistent across all the different models, which is pretty hard to do.

There are three things really that Ollama tries to package together. One is a harness for example, whether it's an off-the-shelf harness or an SDK to help use the model. Some existing harness that is designed for this. What's great now is there are so many great open source harnesses. The Codex harness is open source. Open Code's a great one and one of the most popular harnesses from Ollama users.

Step one is getting the harness right, but then you've got to package it with the model, making sure that it's available, it's reliable, if it's in the cloud, that there's enough capacity for it because day zero tends to be the largest growth day obviously. Then importantly, there's the hardware and the providers. That's actually where there's a lot of collaboration to be had, whether it's like an inference provider optimizing the model or with some partners whether it's Nvidia or working with the Apple silicon stack, making sure that it actually runs the model really fast, because if the model's capable but it's really slow that's not a great experience.

Getting those three things packaged into a box. Generally, you're lucky if there's the ability to access the model a few weeks in advance. A lot of this stuff comes together in the last 24 hours before the model gets released and so it's generally a fire drill.

Ollama is kind of like an operating system in the old world where you needed to really integrate very tightly with all the drivers, all the hardware, and then at the application level to make sure that all the apps were really tuned up well. Ollama is the glue for all of it.

The OS analogy is a good one because you've got the drivers for the hardware and the providers and the inference layer, but you also have the application runtime and making sure that the harness works. Gluing that together, it's a very combinatorically large problem to solve. Doing that well is really difficult. Over time, pieces are developed that allow you to quickly develop that, test it, release it, and kind of have this common runtime that can match any harness to any model. That's the role Ollama is really playing for developers.

The Ollama team aren't AI researchers by background. They're from VMware and Docker, and from other networking companies. The classic compute problems are kind of reinventing themselves in the inference land, and that's where they like to focus their time. At the end of the day, it all comes down to the developer experience. What is it like when the developer makes a call to the API and gets tokens back? What happens? There's more and more happening in that layer right now. Getting that right needs all the layers of the stack to work well together.

One of the challenges with open models has been that hasn't been happening at the rate of what a frontier model lab puts out, where they have the classic five layer cake that Jensen mentioned, which is like the apps, you have the model, you have the infrastructure and inference, you've got the chips, and you've got the energy, and they've got all that ready to go for developers on day zero. That's really the thing that Ollama is trying to reproduce for open models. Ollama won't do every layer of the stack, but they can help orchestrate that.

In open models, there's more than five layers. The model layer actually has a lot to it. There's the model weights, but there's also a lot of the orchestration components that each model is uniquely good at. There's this developer API layer. There are so many opportunities to build between the model and the application layer that are kind of hidden in today's five layer cake stack.

Those hidden layers might get unbundled and become their own companies or providers. There was a really good talk from some of the Anthropic team, the platform team, and they talked about three big things. One was knowledge. How do you connect your company's data and context to the model? One is coordination. So as you know, when you make a request to your cloud app or Codex, it goes off and spins out a bunch of subagents, some of those in the cloud, some locally, there's a coordination problem. Then lastly there's an execution problem, which we talk a lot about as sandboxes, but these agents more and more of them are moving to the cloud. There's a huge compute problem to be solved there.

If you look at what's happened classically in the cloud business, open source has meant that there are best of breed companies for each of those problems. Whereas you might have had the Herokus of the world, Google App Engine, all those things were bundled together. But what developers ended up preferring is best of breed products for each one.

The nihilism which is all things are just bundling or unbundling. The frontier model labs want you to be totally in their walled garden of managed agents and their context, their memory layer. Meanwhile little tech and all the founders out there and all the open source developers don't want to be caged in, so they're going to make all this other stuff, and it'll be an interesting moment to figure out like what ends up winning. It'll probably be some mix of both.

There's an abundance of open model tokens that's being created. There are just dozens of open model providers that are able to serve these tokens. The new scarcity, the problems now are what's above the tokens. How do you orchestrate an agent from A to B? These are problems that have tons of new systems and engineering problems that are just really hard to solve for an individual dev. There's no way they're going to build all those layers.

The coding agents themselves are getting a lot better, and ostensibly this is the worst the models will ever be. The classic reason why there was a moat here was it was just too hard to have really well-maintained software that was properly tested that actually satisfied user need. What if that goes away? We're literally at this moment where actually maybe you'll just have a cursor and it runs a markdown file in some TypeScript and it'll just work. There's no lock-in anymore. You could be using OpenAI's memory system one day and then actually you could have an agent be constantly syncing that against your own memory system and actually it just works. It's fine. It works over MCP. There's all this runtime testing and then there's no lock-in.

A lot of what we know of as harnesses today, a lot of those pieces will go down into the model. But as you kind of push a lot of the core loop of the model and hooks down to the model itself, there are these pieces that kind of come out like memory is a great one. The general guidance being used is if it's a stateful problem, like there's storage involved, that's something that in the end can't go into the model because the model's trained and it's as we know training runs are now happening on like a monthly basis but it's still not up to date with the latest data. So generally storing data is like a huge problem space that won't ever make its way down into the model layer.

Managing credentials and that kind of stuff isn't security credentials safety. Open models don't have all the safety tooling that closed model providers give you out of the box, but that's super important especially for businesses to adopt them.

The super majority of tokens will be open models within a business. Call it 80-90%. That doesn't mean 89% of the budget will go to open models. In fact, what the open model community is doing incredibly well together is lowering the cost to make it more accessible. Maybe you'll only pay 10 to 20% of the cost towards open models, but most of your tokens will be going through the open models. That will enable a whole bunch of use cases on top because you have this abundance of tokens. You're not thinking about taking away token access from your team. You're giving more and more access.

For the hardest tasks, that's reserved for these frontier labs where a lot of the best researchers are. Then from there, there's a whole bunch of problems in the middle, where maybe it's a combination of open and closed models working together.

The steady state is that most of the software, most of the models are open. As the models get more powerful, ideally you just want to delegate to your smartest model to figure out when to go to an open model, but the labs who own the models presume you don't want that. All the labs are aligned in many ways to one thing, which is how do you serve the customer? It will be up to the customer to decide if they have a router where some of the scheduling and harder orchestration happens through a frontier model, so be it. But a lot of the kind of line item work can happen through open models and the collaboration of the two together.

A ton of projects whether it's from Sakana AI or OpenRouter have combined the two and it's seen really good results. This is not too dissimilar from a human organization. Like a law firm, there's like a partner and then there's like a bunch of associates, and the partner farms out the work to the associates. It's like the same.

The same thing was seen with cloud computing where it was really a blend of proprietary software, some of them provided by the cloud providers themselves. For example, AWS had DynamoDB which was kind of their proprietary scale out database. But then a lot of customers use that in conjunction with Postgres DB, and in the end what we see is customers will use a combination of the two.

This is also the same design for why the Apple silicon is actually more superior. The special accelerators for different kinds of workloads for let's say image processing as opposed to audio. That's been or even go way back in the PC era you had like your standalone audio card, graphics card and all that.

Speaking of Apple Silicon, local models are incredibly exciting because it's similar to the closed versus open model question. It'll be a mix in our mind and that's what we hear from customers as well, where for easier tasks you could run them locally and with lower latency and of course lower cost when it comes to the per token cost. Ultimately, you're buying hardware up front and you'll use that in conjunction with these cloud models.

What's exciting about this next generation of hardware, which we've had for a few years now, is just how good they are at running the 20 billion parameter to 40 billion parameter range of models, sometimes up to 128 billion parameters.

Qwen 3 8 38B is now as good as Opus 4.6 for coding. That's what the benchmarks show. It's incredibly exciting because you can run that on not the lowest memory MacBook, but the second lowest memory MacBook you can buy from the store. It's incredible.

From the side of which models they're running, we're seeing a really solid mix of US and Chinese trained models being used for local, and we have the incredible models from the original Llama models of course but also

Open models from the original Llama series and Gemma models from DeepMind represent strong choices for local deployment. Coding agents prove most effective with large cloud models when solving difficult problems like writing code and tests, while document processing workflows run extremely well locally due to simpler end-to-end tasks.

A hybrid execution model emerges where easier tasks run locally and a router directs complex requests to large cloud models. This approach reduces customer costs beyond open model pricing advantages by enabling free local execution on existing business hardware.

Cloud coding agent models predominantly use Chinese models today. Local models show a balanced mix of US, European, and Chinese origin models. The contrast is stark: US and Chinese models are neck-and-neck for local deployment, while cloud-hosted models show approximately 100% Chinese model consumption.

The graph indicates a clear need for more US labs to develop large models. The launch of the Neotron Ultra model represents the first wave of US response to this gap.

Nvidia's business model differs from typical technology companies. Rather than creating new software businesses or selling tokens, Nvidia focuses on releasing substantial open-source resources to advance the ecosystem, which helps maintain hardware market leadership.

The company powers an ecosystem around open models through both hardware and model releases. The new DGX Station computers feature GB300 capabilities on desktop hardware.

A GB300 workstation can run Frontier models, though slowly, at approximately $200,000 to $300,000. The price point is more competitive than initially expected, enabling multiple Frontier-level models at high speeds at costs approaching traditional workstation computers.

Banks and industrial businesses already maintain Nvidia workstation GPUs on every engineer's desk, sometimes numbering in the tens of thousands, originally purchased for CAD work. The next generation builds on RTX A6000 systems.

The DGX Spark provides 128 GB of unified memory capable of running 20B to 120B parameter models. These systems can be chained together using fast network links to create miniature data center racks on a desk, similar to Mac Mini clustering approaches.

Both Apple and Nvidia are driving next-generation hardware designed specifically for running large models effectively. DGX Spark and Apple Studio systems offer competitive performance depending on available hardware and preferred technology stack.

The MLX project provides a mature technology stack for running LLMs on Mac Studio, smaller Macs, and DGX Spark systems. The stack enables effective local model execution across multiple hardware platforms.

This development signals a renaissance for personal desktop computing as hardware capabilities catch up to model requirements.

Ollama began as a local-first solution, but coding agent demand shifted to cloud deployment. The expectation is that local execution will return as hardware capabilities advance. GB300 desktop systems will enable the fastest coding loops, matching the millisecond response times of GitHub Copilot autocomplete at 100 milliseconds.

The pattern follows a journey from local to cloud and back to local, ultimately using both together.

GPU prices fluctuate rapidly with high supply and demand volatility. Startups face significant challenges accessing B200 and B300 GPUs needed for latest models. Inference providers are building platforms to address this access gap.

Extreme demand exists for high-end GPUs, creating growth limitations based on GPU availability. Partnerships with multiple providers help manage demand, though this requires substantial coordination work including model placement decisions, performance optimization, regional considerations, and latency management.

Products like Open Router, Ollama, and Open Code project enable end-user developers to access GPU resources without negotiating B200/B300 pricing or managing 24-month hardware forecasts.

For startup founders with limited funding seeking maximum token usage, DeepSeek Flash exemplifies a new class of ultra-low-cost-per-token models. These models offer both low cost per token and low cost per task, representing the first step toward "unlimited tokens" usage patterns.

Model architecture must be custom-trained for high-volume token usage to achieve this goal. The focus has shifted from reaching frontier intelligence to achieving extreme efficiency.

GBT Luna model pricing has enabled widespread team adoption. Similar efficiency gains are expected with open models, with DeepSeek Flash leading adoption. Flash models handle 80% of tasks effectively while being fast and ultra-cheap.

Coordination layers enable chaining multiple flash models together for different tasks, achieving results comparable to larger models. Cheaper models provide accessibility, speed, and high-volume access while enabling new problem-solving approaches through orchestration.

This creates opportunities for startups, existing inference providers, and large businesses solving workflow problems.

Early AGI discussions assumed a single "god model" would handle everything. Current reality shows task composition with smaller, specialized models provides repeatability, trustworthiness, and feasible costs. This approach has proven more practical than single massive models.

Most customer use cases reach a sufficient intelligence level where models can continue operating without needing god-tier capabilities. Models may improve in speed, architecture, and capabilities while remaining at adequate intelligence levels.

Open models excel at run-of-the-mill business problems that are hard enough to benefit from AI but don't require solving the hardest challenges. Zoo AI and GLM are achieving frontier-level performance on specific tasks. The Kimmy model demonstrated superior web development capabilities, creating market shock waves.

The competitive landscape has shifted from gap-closing to head-to-head competition between open and closed models.

Model origin and deployment location matter significantly. Some customers prioritize where models run rather than where they originate, while others care about model origin due to data concerns and communication patterns. Models go through phases of sounding more robotic or friendly, which affects user experience.

For mission-critical tasks, model origin transparency becomes essential. Llama powers analytics for a power plant in Finland to detect surges and maintain power supply.

The "Manchurian candidate problem" refers to concerns about models potentially being compromised. No known cases have been identified. Fortune 500 companies' IT and security teams are experienced with supply chain security issues, as average applications contain thousands of dependencies where single points of failure can compromise entire systems.

Chain poisoning represents a decades-old security concern. While models are opaque and deterministic, proper screening with safety checks addresses most concerns according to customer feedback.

Founders previously built Docker Desktop at Docker, developing expertise in creating excellent developer experiences. The company spent initial years searching for the right problem to solve with this capability.

The original YC application in Winter 2021 focused on building a Kubernetes desktop experience, described as "Kitematic for Kubernetes" or "Docker Desktop for Kubernetes." The company pivoted multiple times before launching Ollama in July 2023 after raising Series A funding.

"Llama" derives from the concept of open models rather than any specific existing model. The name combines "LLM" with the animal concept, creating a memorable character and mascot for the brand.

Benchmark invested in 2022, before ChatGPT's release. The pitch emphasized building great developer experiences and solving security problems, leveraging previous Docker relationships. Peter, the Benchmark partner, had been the Series A investor in Docker.

The investment focused on the founding team's values and approach rather than the specific problem being solved at that moment, which was SSO for Kubernetes.

The company spent approximately two years in the "wilderness" working on ideas that weren't gaining traction. This period involved constant customer conversations that weren't fully resonating, creating uncertainty about whether they were solving real problems.

The founding team had previously built a company acquired by Docker. Having a team of more than 10 people during this uncertain period added pressure. Multiple pivots occurred, including from Kubernetes security to developer desktop security.

A pivotal meeting in Toronto led to throwing out all previous ideas and starting fresh. Two major problems were identified: building a gateway for seamless model access and helping make open models run effectively, leveraging the team's VMware and Docker systems expertise.

The team gave themselves two weeks to launch the first version of Llama. Llama 2's release coincided with the deadline, prompting immediate launch. This represented a shift from overthinking to bias toward action.

The first external awareness came through Reddit's local LLM subreddit, where users were enthusiastic about Ollama's capabilities before realizing it was a YC company. The project was originally called a different name before becoming Ollama.

The founders initially connected through different company names in internal systems, with an early interaction involving catching up with Jared and an encounter on the stairs. The founder was wearing company t-shirt or swag, creating a memorable first impression. The timing of launching open models during YC was discussed, though it wasn't possible at the time since Llama hadn't launched yet.

The project became one of the first GitHub projects to quickly reach 100,000 GitHub stars, growing much faster than Docker and Kubernetes. The founder described being "beside yourself because you can't totally explain why" as the best way to explain product-market fit. While monetization with Llama's Cloud only began earlier in the year, seeing people "fall in love with the product" represented a zero-to-one moment. The transition from "cranks on Reddit" interested in running their own rigs at home to 85% of the Fortune 500 in about 2 years was highlighted as remarkable.

The growth was compared to a "homebrew computer club to broad computer adoption like speedrun" that took 10 years for the PC but only 18-12 months for this technology. The original users were very much hobbyists tinkering with what was possible, but two key factors enabled rapid enterprise adoption: the models were free to get started with and could run anywhere. This was "incredibly helpful to a Fortune 500 IT developer team because they don't have to ask for permission to use it." The transition from hobbyist to business developer happened naturally, and the stateless nature of LLMs made for an "easy transition" compared to databases like MongoDB.

In 2023, Llama 2 took off with 100,000 GitHub stars, but users were primarily "Reddit cranks" with no obvious revenue path. It took 2 years to figure out a business model, similar to Docker's position. The founders identified two monetization approaches: privacy-focused AI products and capturing use cases where open models could serve the largest consumption of AI. The transition to coding agents running with open models represented the moment when "the largest consumption of AI being matched with finally open models being able to service that."

The team waited for the market to mature, recognizing that open models initially lacked the product-market fit that closed models had. They asked themselves "what would be the most important problem we could solve for a customer," determining that accessing open models for the hardest problems was the key opportunity. The local piece was "an important part of that story" but "never felt like the whole story."

Risks of waiting included building a culture that might not prioritize monetization, a lesson learned from Docker days. The biggest risk of having an open-source project that takes off is considering your user base and customer base "like your customer just a blob on the internet," which is "a really risky way to think about customers." The team wished they had done more customer connection work in the last few years and are now "doing a ton of that."

As second-time founders, they went "back and forth" on doing YC when they "should have just said, of course, we're doing YC." Starting a company is "a really lonely experience" even with a great co-founder who was a college roommate at University of Waterloo. Having peers through YC, talking to Jared and "five other groups of founders every week" helped reduce loneliness. The network was "incredible," including meeting founders building on open models and AI. Transparency among YC founders about mistakes was valuable, and they still keep in touch with the founder of Docker who's now an investor.

The team includes people from companies that "ended up working great" like Docker and VMware, bringing lessons from "ups and downs." The advice emphasized that "if you've never worked on a team that shipped really amazing technology to like a lot of people or like real clear product market fit, do that once" - even for a month or three months. Having seen "what good looks like" multiplies chances of success, providing "a set of values you can work around especially when you have so much power in your hands with AI."

Several lessons from previous generations of DevOps and infrastructure aren't valid in the AI world. Platform as a Service companies like Heroku represented a vulnerable position as a startup, but "going up the stack can sometimes be even better because you're closer to the customer" in the AI world. The concept that "if you're a layer on top of something else that you're in kind of a vulnerable position as a startup" is "absolutely not true in the AI world."

LLMs are "never perfect" and by definition "are not" exactly as designed, which contrasts with traditional systems where "you want everything to be exactly as it's designed to run." This non-determinism is "a feature not a bug" - "You want it to be a little non-deterministic." AI staffing requirements differ significantly, with fewer engineers needed for customer support pipelines and cloud service delivery compared to 10 years ago.

A fundamental challenge is building services "where no engineer knows exactly how all the code works," requiring new lessons from infrastructure 1.0 in the 2000s to cloud in the 2010s to AI space. The team is "actually doing an incredible service to both sides of the ecosystem" by providing clean, working interfaces where "tokens just come out and they're very clean and the API makes sense and is rational and logical."

One of the "big opportunities in the open model landscape is curation" - taking a "fragmented universe of models and inference technology and cloud services and harnesses and making that actually just work." The end developer "just want to build their software right they just want to build stuff they want to build their next company their next application." OpenRouter represents a good example where developers don't have to sign up for "a hundred different providers" but can "just go to one" and "pay in one place." OpenCode allows "one harness that integrates with any model," creating "a really powerful experience for developers just looking to try the next model to see if it solves their use case better."

The conversation concluded with acknowledgment that curation addresses the scarcity of bringing together abundance of models and providers into something that works.

Keep Y Combinator in your library

Save the videos and channels worth coming back to, and find them again in one place.