Startups choosing an AI foundation increasingly face a less ideological and more practical question: should they rely on proprietary frontier-model APIs, deploy open models, fine-tune their own systems, or combine several approaches?
TechCrunch Disrupt 2026 will put that question on its Builders Stage in a session led by Nvidia’s Nader Khalil, director of developer tech, and Sydney Sykes, the company’s global head of VC partnerships. The event is scheduled for October 13–15 in San Francisco.
The key point for operators is not that one model category has won. It is that model selection now affects core business mechanics: unit economics, data handling, infrastructure commitments, product velocity and a company’s ability to change suppliers.
The gap may be narrowing, but the choice is not simpler
Open models have advanced quickly, including Nvidia’s own Nemotron family. Nvidia said in July that 145 ICML 2026 papers cited its Nemotron open models and datasets, with work spanning areas including robotics, autonomous vehicles and biomedical research.
Meanwhile, proprietary model providers continue to advance their frontier systems. That leaves builders with a broader set of viable options, rather than a single default architecture.
For an early-stage team, a proprietary API can reduce time to a working product and limit the burden of operating model infrastructure. But that convenience can create exposure to changing prices, capabilities, terms and provider availability. It can also limit how deeply a company can customize deployment or control where sensitive workloads run.
Open models can offer more flexibility around deployment, customization and data control. In return, companies take responsibility for evaluation, optimization, serving infrastructure, reliability and ongoing upgrades. The attractive per-token economics of a self-hosted model may not hold once GPU capacity, engineering time and operational complexity are included.
Hybrid is the more realistic design pattern
Nvidia CEO Jensen Huang has argued that the future is not proprietary *versus* open, but proprietary *and* open. For many product teams, that is likely to be the useful starting assumption.
A company might use a proprietary model for difficult, high-value tasks while routing routine or latency-sensitive workloads to an open model. It could run a local model for data-constrained environments and retain an external API for peak reasoning capability. A multi-model approach also creates a degree of negotiating leverage and reduces dependence on one provider.
But hybrid architecture is not free. It requires clear routing rules, consistent quality evaluation, observability across vendors and deployment environments, and safeguards against uneven outputs. Teams need to measure performance at the task level, not rely on broad model benchmarks.
Nvidia has a particular interest in this outcome. Khalil previously co-founded Brev.dev, an AI infrastructure company acquired by Nvidia in July 2024. Nvidia’s developer tooling has emphasized deploying AI software across public cloud, private cloud and on-premises systems rather than tying developers to one compute source.
The model is rarely the durable advantage
The strategic risk is treating access to a model as the product’s moat. If competitors can call the same leading API, defensibility must come from other assets: proprietary data, embedded workflows, distribution, customer relationships, domain expertise or a materially better user experience.
Using an open model does not automatically change that equation. Control over weights and deployment can be valuable, but only if it enables lower costs, better performance on a critical workflow, stronger compliance positioning or a differentiated customer experience.
Nvidia’s March launch of Nemotron 3 Super, a 120-billion-parameter open model positioned for agentic workloads, illustrates the market’s direction: more capable open options alongside continued use of proprietary systems. The practical question is where each belongs in a product stack.
What to watch next
Founders should expect the optimal mix to keep moving as model capabilities, inference costs and deployment tooling change. The best response is architectural optionality: isolate model providers behind a layer that supports testing and substitution, retain evaluation data, and calculate costs against real workload volumes.
The winning decision may not be open or closed. It may be the ability to change that decision without rebuilding the business.
