The Access Cliff: The Best AI Model Isn’t Buildable
The best model announced this month is one most founders cannot use. OpenAI pulled GPT-6.1 Astra before it shipped, citing safety tests. Google put its strongest model, Gemini 4 Argon, behind a vetted-partner program and blocked public access. Mistral’s new flagship went out as a guarded preview on one console, with the weights promised later. A powerful research model started billing, then stayed locked to approved labs. Read the launch coverage and you would think the frontier had a huge month. Try to build a product on any of those models and you hit a wall.
I have been through this gap enough times to stop being surprised by it, and I want to name it, because naming it changes how you pick what to build on. The model that tops the leaderboard is often the one you can least build a business on. The same things that make a model frontier, that it is new and powerful and risky, are the things that keep it gated, previewed, cancelled, or repriced. The announcement and the dependency are two different objects. We keep treating them as one.
There is a cliff between what the frontier shows you and what you can actually ship on, and it is getting steeper. I call it the access cliff. Most of the expensive mistakes I have watched founders make with AI over the last three years trace back to standing on the wrong side of it, building a roadmap, a pitch, and a price around a model they had seen but could not depend on having.
The variable founders optimize is not the one that decides whether they ship
Walk into almost any AI startup and ask how they chose their model. You will hear about benchmarks. Index scores, task scores, a demo that blew someone away, a comparison thread on X. Capability is the variable everyone optimizes, because capability is the variable everyone can see. It has a number. The number goes up. You pick the one with the highest number that you can afford.
Capability is real and it matters. But it is not the variable that decides whether you have a product in six months. That variable is access, and access is almost invisible until it moves. Access is the full set of terms under which you can actually use a model: whether you can get it at all, at what price, under what rate limits, for how long before it is retired, and whether the terms of service even permit your use case. None of those show up in a benchmark. All of them decide whether you ship.
Here is the asymmetry that makes this dangerous. Capability is published and stable. A model’s score is announced on day one and it does not change. Access is unpublished and unstable. It is set by a vendor who can change it with little notice and no obligation to you. So founders anchor on the one number that is both visible and fixed, and ignore the dozen terms that are both hidden and moving. They optimize the wrong variable because it is the only one with a scoreboard.
I watched a team last year build their entire demo, their seed deck, and their launch timeline around a model that was in a limited preview. The demo was genuinely good. The model was genuinely the best for their task. Then the preview tightened, the rate limits dropped below what their product needed to feel instant, and the pricing they had modeled turned out to be introductory. They had a beautiful product that was economically impossible to run and a launch date they could not hit. Nothing about the model’s capability had changed. Everything about their access to it had.
The reason this keeps happening is that the two frontiers look like one frontier from the outside. You see a launch post. You assume launch means available. It does not. A launch is a marketing event. Availability is a commercial relationship with terms you have not read yet.
The capability number was not measured on your problem
There is a second reason capability is the wrong thing to optimize, and it is worth sitting with even before we get to access. The number you are chasing was produced on someone else’s problem. A benchmark is an average over a fixed set of tasks a lab chose, and your product is not that set. A model that scores a point higher on a public index can be worse at your specific workload, and a model that scores lower can be better at the narrow thing you actually do. The leaderboard rank is a proxy, and it is a proxy for a question you are not asking.
The question you are actually asking is whether this model produces the result your customer pays for, reliably, at a cost you can carry. That is a measurement you have to run yourself, on your own tasks, because nobody else has your tasks. I have argued before that the metric that matters is the business result per dollar you spend getting it, not the benchmark rank, and this is where the two ideas meet. If you measure capability on your own problem instead of on the public scoreboard, two things happen. You stop overpaying for frontier capability you do not need, because a cheaper, more dependable model often wins on your actual tasks. And you build the exact measurement apparatus, a test set drawn from your real work, that you will need later to swap models safely. The discipline that frees you from the benchmark is the same discipline that frees you from the vendor.
So the capability obsession fails twice over. The number is seductive and fixed, which pulls your attention away from the moving access terms that actually decide your fate. And the number is measured on the wrong problem, which means even the variable you are optimizing is a bad proxy for the thing you care about. Two reasons to stop picking by leaderboard. Now the bigger one, the one about what you can actually keep.
The two frontiers, and the drop between them
Draw it as two lines moving through time. The top line is the announced frontier: the best capability that exists, the thing the labs demo, benchmark, and write launch posts about. It climbs fast, and it is the line every founder watches. The bottom line is the buildable frontier: the best model you can actually license, at scale, today, on terms you can live with. It climbs too, but it sits below the top line, and it lags.
The gap between those two lines is the access cliff. It is the distance between the capability you can see and the capability you can depend on. And the thing to understand, the thing that makes this a strategy problem and not a timing problem, is that the gap widens as the frontier rises. The more powerful a model is, the more reasons a lab has to gate it: safety review, misuse risk, compute scarcity, a desire to serve enterprise and government customers first, a desire to price-discover before committing. So the newest, strongest capability is exactly the capability least likely to be dependably yours.
Most of the noise in AI lives on the top line. Most of the decisions that determine whether a company survives live on the bottom one. When I look at where the real opportunities in AI are, they almost never sit at the frontier of capability. They sit at the frontier of what you can actually build and keep.
What makes a model buildable has almost nothing to do with how smart it is
If capability is not the thing, what is? A model is buildable when you can depend on it. Dependence breaks down into four terms, and not one of them is a capability. You do not control any of them. The vendor does.
The first is availability. Can you actually get the model, at the scale you need, without a waitlist, an approval program, a partner tier, or an invite? Plenty of frontier capability fails this test on day one. When GPT-4 launched, paid developers sat on an API waitlist for months. That pattern never went away. It got more formal. Now the gate is a named program you apply to, and the answer can be no.
The second is price, and specifically price you can model. A headline price at launch is often an introductory price. The number you build your unit economics on is the number the vendor can change after you have shipped, after you have signed customers, after you have made pricing promises of your own. The direction of that change is not guaranteed to be down.
The third is rate limits. A model you can call ten times a minute is a different product from the same model you can call ten thousand times a minute. Limits are set by the vendor, for the vendor’s reasons, and they move. Anthropic cut the weekly usage limits on Claude Code by seventeen percent in a single change. For a product whose whole experience depends on calling that model freely, a seventeen percent cut is not a footnote. It is a feature regression you did not ship and cannot fix.
The fourth is the deprecation runway: how long you have before the specific model you depend on is retired, and how much notice you get. This is where the published terms create false comfort. OpenAI’s own policy sets minimum notice at six months for generally available models and three months for specialized ones. That sounds safe. Then look at what happened to one of its cyber models: it entered deprecation on September 11 and shut down on October 1. Twenty days. The out is a safety and compliance exception with no stated floor, and when a lab invokes it, the published minimum is worth nothing. You planned around six months. You got twenty days.
| The announced frontier (what you see) | The buildable frontier (what you can ship on) |
|---|---|
| A benchmark or index score | Whether you can get it at all, at your scale, without a gate |
| A launch demo that looked effortless | A price you can model and build margin on, that will not reprice under you |
| A headline price on day one | Rate limits you can live with at full load, not at demo load |
| A thread saying it beats the last one | A deprecation runway you can survive, and notice you can act on |
| A model you have watched, not used | Terms of service that actually permit your use case |
Read that right column again. Not one of those is about intelligence. A model can be the smartest thing ever built and fail every item on that list, and if it fails them, it is not buildable, no matter how good the demo was. This is the part founders resist, because it feels like settling. It is not settling. It is the difference between a company and a prototype.
Why the best model is usually the least dependable
It would be easier if capability and access moved together, if the best model were also the most available. They move in opposite directions, and there is a reason that is structural rather than accidental.
A frontier model is, by definition, the one a lab understands least. It is the newest, so it has the least operational history. It is the most powerful, so it carries the most misuse risk, which means the most safety review and the most reason to gate. It is the most expensive to serve, so it faces the tightest compute constraints and the strongest pull toward the customers who pay the most, which is enterprise and government, not a seed-stage startup. And it is the most commercially uncertain, so its price is the most likely to be a guess the vendor will revise.
Stack those up and you get a clean inversion. The attributes that put a model at the top of the capability line are the same attributes that push it down the access line. New means unstable. Powerful means gated. Scarce means rationed. Uncertain means repriced. The frontier is where capability is highest and dependability is lowest, at the same time, for the same reasons.
This is why the specialist models that flooded out recently matter more to a working founder than the flagship that got cancelled. A small decision model you can run under an open license, a two-billion-parameter model that runs locally for free, a translation model you can download: these are boring. They will never top an index. But they pass the four tests. You can get them, the price is zero or near it, there is no rate limit you do not set yourself, and nobody can deprecate a model whose weights are on your own disk. The buildable frontier is often made of exactly the models that get no launch coverage.
The preview trap is the most expensive mistake on the board
The bottom right quadrant is where founders lose the most money, so it deserves a name. The preview trap is what happens when you build your roadmap, your fundraise, and your pricing on a model that is brilliant and that you cannot depend on. High capability, low access. The demo works, the investors are impressed, the plan assumes the model you showed them will be there, at that price, at that latency, when you need to scale.
It almost never is. A preview is a signal of intent, not a supply guarantee. The capability you saw is a preview of your roadmap, not a foundation for it. There is an enormous difference between those two framings, and the whole error lives in collapsing them. If you treat a gated model as a preview of where the field is going, you make good bets. If you treat it as a dependency you can build on today, you make a promise your vendor never made back to you.
The tell that you are in the trap is simple. If a single vendor could break your product next quarter by changing a term you do not control, and you have no second path, you are standing in the bottom right quadrant, no matter how good your demo looks. The fix is not to find a more impressive model. The fix is to move your foundation to a model you can keep, and treat the impressive one as upside.
Build on the floor, adopt from the ceiling
Here is the operating rule I keep coming back to. Build on the floor, adopt from the ceiling. Your product’s foundation, the part that has to work every time a customer touches it, should sit on the most dependable model that is good enough for the job, not the best model that exists. That is the floor: boring, available, price-stable, hard to deprecate out from under you. Everything above that floor, the frontier capability you would love to use, you adopt opportunistically, behind a seam, when and only when it becomes dependable enough to lean on.
The architecture that makes this possible is a layer between your product and any single model. Call it a seam. Your product talks to the seam. The seam talks to whatever model is dependable for each job, and it can be swapped without touching the product. This is the practical version of routing between models behind one interface, and the reason to build it is not cost optimization, though you get that too. The reason is that a seam turns a model from a load-bearing wall into a replaceable part. When a model gets gated, repriced, or retired, you swap the part. The product does not notice.
Two things live in that seam and earn their keep. The first is the ability to route each job to the model that is dependable for it, which often means a cheap specialist for the common case and a stronger model only where the job demands it. The second, and the one founders skip, is an evaluation harness: a set of tests, drawn from your real workload, that tells you in an afternoon whether a candidate model is good enough to swap in. Without that harness, swapping a model is a terrifying, open-ended project and you avoid it, which means you stay locked to whatever you started on. With it, swapping is a Tuesday. The harness is the thing that makes your model actually replaceable, which is the thing that makes you free.
Notice what this does to the question founders agonize over, which model to pick. It makes the question matter less. If your model is the most replaceable part of your system, the stakes of picking the current best one drop to nearly zero, because you can leave. The founders who are calm about the weekly model churn are not the ones who guessed right. They are the ones who built so that guessing wrong costs them an afternoon. The stakes of the choice are set by your architecture, not by the model.
The terms you do not control move more often than the models do
It is tempting to treat all of this as a deprecation problem: the model goes away, you move. But the harder version is that the terms move while the model stays. The model you are using is still there. Its price went up. Its rate limit came down. A clause in the acceptable-use policy now excludes your use case. Nothing was deprecated. Your economics still changed.
This is the part that is genuinely new about building on AI, and it is why the usual software instincts mislead you. When you depend on a database or a cloud provider, the terms are relatively stable and the switching costs are understood. When you depend on a frontier model, you have taken on a supplier whose product changes weekly, whose prices are discovery experiments, and who can alter your cost of goods, your latency, and your legal permission to operate, unilaterally, with little notice. The model is not just a component. It is the single most volatile dependency in your entire stack, and most founders have given it the least thought about what happens when it moves.
| The term | What it looks like when it moves | The question to ask before you depend on it |
|---|---|---|
| Availability | A waitlist, an approval program, a partner tier, an invite-only preview | Can I get this at my scale today, or am I planning on a maybe? |
| Price | An introductory rate, a repricing, a change to cached or input billing | Does my margin survive if this price doubles? |
| Rate limits | A weekly cap cut, a throttle under load, tiered access by spend | Does my product still feel instant at full load, not demo load? |
| Deprecation runway | A retirement date, a legacy tag, a short-notice safety exception | If I get twenty days’ notice instead of six months, do I survive it? |
None of this means a single vendor’s model is a bad choice. It means a single vendor’s model is a bad single point of failure. The cost term you cannot forecast, the limit you cannot raise, the runway you cannot extend: these are the things that quietly set the ceiling on your unit economics and your margin, and they are set in a room you are not in.
This is a different problem from the one you solve after you have shipped
I want to be precise about what the access cliff is and is not, because it sits next to two ideas it is easy to collapse into.
It is not the same as surviving model churn. Once you have built on a model and it starts moving under you, deprecated and repriced and verticalized, you have a defense problem, and the answer is to own something the model cannot: a data loop, a workflow, a distribution advantage. That is a real and separate discipline, and I have written about what to do once the model you built on starts moving. The access cliff is upstream of that. It is the choice you make before you build, about which model to stand on and why the best one is the wrong target. Survival is what you do after you have committed. The cliff is about committing wisely.
It is also not the capability overhang. The overhang is a demand-side gap: models can already do far more than most companies have adopted, and the lag is on the buyer’s side, inside the org. I have written about why so much AI value sits unused. The access cliff is the supply-side mirror of that. Here the capability exists but is withheld, gated, or unstable, and the lag is imposed by the vendor, not chosen by the buyer. One gap is about what you have not picked up yet. The other is about what you are not allowed to hold. A founder can be on the wrong side of both at once: unable to get the frontier model, and not using the capable one they already have.
And it sits next to the question of what you actually add on top of a model. If your product is a thin pass-through to someone else’s model, access volatility is fatal, because you have nothing to absorb the shock when the terms move. The thicker the thing you own around the model, the more a term change is a nuisance rather than a death. The access cliff and the thin-wrapper problem are the same force seen from two angles: the model is a commodity you rent on terms you do not set, so your defensibility has to live somewhere the vendor cannot reach.
Pivoting your model should be an afternoon, not a project
Most teams have never actually tried to swap their model, so they do not know how long it would take. That not-knowing is the real exposure. If the answer is “we are not sure, probably weeks, we would have to re-check everything,” then you are not depending on a model, you are married to it, and a vendor you did not choose to marry holds the terms.
The number worth tracking is your swap time: from the moment you decide to change the model under a given feature, how long until the new model is live and verified in production. When that number is measured in days, the whole access problem softens. The model becomes a supplier you can fire. When that number is unknown or large, every term change the vendor makes is a crisis, because you cannot respond to it. The point of the seam and the evaluation harness is to drive swap time down until pivoting is routine. A founder who can swap models in an afternoon reads a gated flagship or a surprise price change as news, not as an emergency.
There is a parallel here to how the cost of running AI keeps moving around the stack, and the same discipline applies: watch where the real cost of inference is migrating and keep yourself able to move with it. The teams that stay flexible on where compute runs and which model does the work are the ones who are not held hostage by any single line on anyone’s pricing page.
The frontier you cannot use today is your floor in a year
There is an optimistic pattern buried in all of this, and missing it leads founders to the opposite mistake, treating the access cliff as a reason for despair instead of a reason for design. The gap between the two frontiers is real, but it is not permanent for any single capability. The gated flagship of this quarter becomes the commodity model you can host next year. Capability that was locked behind a vetted-partner program eventually leaks into open weights, cheaper tiers, and smaller models you can run yourself. The frontier does not just rise. It also descends, as each year’s restricted capability becomes next year’s boring default.
That descent is the thing to build around, because it tells you exactly how to use the top line without depending on it. Watch the announced frontier the way you watch a weather forecast: it tells you what is coming, so you can plan, so you can decide which capabilities are worth designing your product to eventually use. Do not move onto it. Move your foundation onto the buildable floor, and keep that floor swappable, so that the moment a capability descends from the gated frontier into dependable availability, you can adopt it in an afternoon instead of rebuilding to reach it.
This reframes the whole exercise from defense to position. You are not hiding from the frontier. You are standing where you can both ship today and catch each new capability the day it becomes dependable, without ever betting the company on a model you cannot keep. The founders who compound are the ones who treat the top line as information and the bottom line as home. The cliff is not a wall you are stuck behind. It is a schedule, and if your architecture is swappable, you are early for every arrival instead of stranded by every departure.
Sometimes you should build on the model you cannot keep
There is a real counterargument, and I do not want to wave it away, because following the dependable-model rule too rigidly has its own failure mode.
Sometimes the frontier capability is the entire product. If the thing you are building is only possible at all because of a capability that lives only on a gated or preview model, then building on the boring floor means building nothing. In that case you should build on the model you cannot keep, and the point is to do it with your eyes open. You are not laying a foundation. You are renting a countdown. You take the frontier model, you build the thing that proves the market exists, and you spend the runway doing two things at once: capturing whatever is durable, the data, the users, the workflow, and racing the buildable frontier, which is rising toward where you are standing, so that by the time your rented capability gets pulled or priced out, a dependable model has climbed up to replace it.
That is a legitimate bet. Some of the best AI companies started exactly there, on a capability they did not control, and won by converting a temporary access advantage into something permanent before the access went away. The mistake is not building on a frontier model. The mistake is building on one while believing it is a foundation, so that when the terms move you have captured nothing durable and have no dependable model to fall back to. Rent the countdown on purpose, or stand on the floor on purpose. The disaster is doing the first while thinking you did the second.
Running your first model-dependency audit this week
Here is the concrete work, and it takes an afternoon. The goal is to find every place a specific model’s specific behavior is load-bearing in your product, and to turn each one from an unexamined assumption into a decision.
Start by listing every feature that calls a model, and for each one write down the exact model it depends on and whether that feature breaks if the model’s behavior changes. You are looking for the places where you have tuned to one model’s quirks so tightly that a version bump would regress you. Those are your coupling points, and each one is a place the vendor holds a lever.
Then run the four terms against your main model, honestly. Is it generally available at your scale, or are you on a maybe? Does your margin survive the price doubling? Does the product feel instant at full load, or only in the demo? And if you got twenty days of deprecation notice instead of the published six months, would you survive it? Any term where the honest answer is “we would be in trouble” is an exposure you are currently carrying for free, and did not know you were.
Next, name your dependable tier. Decide, explicitly, which model is good enough to be your floor, the one you would be comfortable depending on for a year, and whether anything in your product should actually be built on it instead of on the frontier model you drifted onto. Then measure your swap time, even roughly, by picking one feature and asking what it would really take to move it to a different model. If the answer is “we have no idea,” that is the most important finding in the audit, and building the evaluation harness that shrinks that number is the highest-return week of engineering you can spend, because it is the thing that converts the whole access problem from a threat you cannot answer into a routine you can.
Do this once and the weekly model news stops feeling like something you have to react to. A flagship gets cancelled and you note it. A price changes and you check your margin. A model is retired and you swap the part. You stop living on the top line, where the capability you cannot have is paraded past you, and you start living on the bottom one, where the companies that actually ship are quietly built. If you are building a company to be AI-native from the start, this is the muscle that keeps you standing when the ground under the frontier moves.
Questions founders ask about choosing an AI model to build on
How do I choose which AI model to build on?
Stop choosing by benchmark alone. Pick the most dependable model that is good enough for the job, not the best model that exists. Run every candidate through four terms you do not control: availability at your scale, a price you can model, rate limits you can live with at full load, and a deprecation runway you can survive. A model that fails those is not buildable, however high it scores. Then put a seam between your product and the model so the choice matters less, because you can leave.
What is the access cliff?
The access cliff is the gap between the announced frontier, the best capability that exists and gets demoed, and the buildable frontier, the best model you can actually license at scale on durable terms today. The gap widens as the frontier rises, because the newest and most powerful models are the ones labs most want to gate, preview, or price-discover. Founders design roadmaps against the capability they can see and get wrecked by the access they do not have.
Why is the best AI model often the one I cannot use?
Because the attributes that make a model frontier are the same ones that make it hard to depend on. New means little operational history. Powerful means more misuse risk and more safety gating. Scarce means rationed toward the customers who pay most. Commercially uncertain means the price is a guess the vendor will revise. The frontier is where capability is highest and dependability is lowest, at the same time, for the same reasons.
Should I build my product on a model that is in preview?
Usually no, not as a foundation. A preview is a signal of intent, not a supply guarantee. Treat a gated or preview model as a preview of your roadmap, something you adopt later when it becomes dependable, not as a dependency you can ship on now. The exception is when the frontier capability is the entire product and the boring alternative builds nothing. Then build on it deliberately, knowing you are renting a countdown, and spend that runway capturing something durable.
How do I protect my startup from a model being deprecated or repriced?
Build a seam between your product and any single model, and an evaluation harness drawn from your real workload that can tell you in an afternoon whether a replacement model is good enough. Together they turn the model into a replaceable part and drive your swap time down to days. Then a deprecation, a price change, or a rate-limit cut is a part swap, not a crisis. The goal is that pivoting your model costs you an afternoon, not a project.
Is depending on one AI provider actually risky?
A single vendor’s model is a fine choice but a bad single point of failure. That one supplier can change your cost of goods, your latency, and your legal permission to operate, unilaterally and with little notice. One lab cut a product’s weekly limits by seventeen percent in a single change. Another shut down a model with twenty days of notice against a published six-month minimum. If a term you do not control could break your product next quarter and you have no second path, that is concentration risk, not a model choice.
What is the difference between the access cliff and surviving model churn?
They are two ends of the same timeline. The access cliff is upstream: the choice, before you build, of which model to stand on and why the best one is the wrong target. Surviving model churn is downstream: what you do once you have built and the model starts moving under you, which is to own something the model cannot copy, like a data loop or a workflow. One is about committing wisely. The other is about defending what you committed to.
Do cheap open-weight models belong in a serious product?
Often yes, and more than founders expect. A small specialist you can run under an open license, or a model whose weights sit on your own hardware, passes every access term by construction: you can get it, the price is near zero, you set the rate limit, and nobody can deprecate a model you host. These models will never top an index, but the buildable frontier is frequently made of exactly the boring, available models that get no launch coverage. Use the strong frontier model where the job truly needs it, and the dependable specialist everywhere else.
I’m a four-time founder building AI-native companies. I write about the founder mindset, AI opportunities, and the mechanics of building with AI at vikasmalpani.com.