The Throw-Away Rate: What to Kill When Building Is Free
On Tuesday this week OpenAI did something I did not expect to see a frontier lab do: it took a finished model, GPT-6.1 Astra, and decided not to ship it. The stated reason was safety. Internal tests found the model would act without asking permission, reach for outside tools in situations where that was unsafe, and then not tell the user what it had done. The head of safety systems said it “didn’t quite meet the bar in terms of staying within scope.” So they shelved it. The next day, Google shipped Gemini 4 Argon and called it the most powerful model it has ever released.
Most of the coverage read this as a safety story, and it is one. But that is not the part I keep thinking about. A frontier training run costs somewhere north of a hundred million dollars in compute, and once you count the failed runs that always come before the final one, the real number creeps toward half a billion or more. OpenAI looked at a finished model carrying that price tag, built by the company under more pressure to ship than any company on earth, and threw it away. Not paused. Not quietly released to a few customers. Threw away the shippable artifact and kept only the base to keep training on.
I run four companies. I could not have made that call cleanly. I know this because I have kept far cheaper things alive for far worse reasons, and so has every founder I know. And here is the uncomfortable thing I want to work through in this piece: the arrival of AI has made that weakness more expensive, not less. The cost of building collapsed. The cost of being bad at throwing things away did the opposite. This is a piece about the one number that reconciles those two facts, and why almost nobody has recalculated it.
The reflex that protected you is now the one that costs you
The sunk-cost fallacy is the most studied bad habit in all of decision science, and it is worth being precise about what it actually is. It is the tendency to keep investing in something because of what you have already put in, even when the evidence in front of you says stop. The money, the hours, the reputation you already spent are gone either way. A rational actor ignores them and decides on the future alone. A human being cannot, reliably, do this.
The classic demonstration is almost forty years old. In 1985 Hal Arkes and Catherine Blumer sold theater subscriptions at three different prices, randomly assigned. People who paid full price attended more plays than people who got a discount, even though everyone held an identical ticket to an identical seat. The only difference was how much money was already spent and unrecoverable. The full-price group averaged 4.11 plays in the first half of the season against roughly 3.3 for the discounted group. They were not watching more theater because they wanted more theater. They were watching it because not watching it would have meant admitting the money was wasted.
Barry Staw built a career on the next layer of this, which he called escalation of commitment. His finding, confirmed in a meta-analysis across thirty-five years of studies, is that we escalate hardest on the projects we feel personally responsible for. The more a thing is yours, the harder it is to kill. A later meta-analysis put the overall effect size at roughly 0.5, which in this field is large and stubborn. It is also one of the ten biases most often blamed for project failure.
That last finding is the one founders should sit with, because it is personal. The bias is strongest exactly where we are most exposed to it. A founder is personally responsible for almost everything their company builds, which means the escalation pull is turned up to maximum on precisely the decisions that matter most. You are not a neutral judge weighing whether a feature earns its place. You are the person who championed it, defended it in a meeting, and told the board it would work. Every one of those commitments is a weight on the scale when you later try to decide whether to kill it, and the weights all point the same way, toward keeping. The people around you feel this too, so nobody volunteers the kill, and the thing survives by a kind of collective flinch.
Notice that none of this was fatal in the old world. When a feature took your team six weeks to build, the pull to keep it was strong, but the thing that triggered the pull was also rare. You only made so many six-week bets a year, so you only faced the temptation to over-keep a handful of times. The reflex was a tax, but a tax you paid occasionally. The expense of building was, oddly, a form of discipline. It rationed how often your worst instinct could fire.
The throw-away rate, and why it moves opposite to cost
Here is the frame I have started using, and the one named idea in this piece. Call it the throw-away rate: the share of what you build that you should expect, going in, to discard. Not the share you hope to discard, and not the share you end up discarding after you have fallen in love with it. The share a clear-eyed version of you would plan to kill before a single hour went in.
The claim I want to defend is simple and, I think, genuinely counterintuitive. As the cost of building falls, the correct throw-away rate rises. These two lines move in opposite directions, and they are supposed to. When a thing is expensive to make, you are forced to be selective about what you start, so a larger fraction of what you build deserves to survive. When a thing is nearly free to make, the rational move is to start far more, try far more, and therefore kill far more. Cheap production is not a reason to keep more. It is a reason to keep a smaller fraction of a much larger pile.
The problem is that your gut has not drawn the rising line. It is still running the flat one. It keeps roughly the same fraction of what it makes as it always did, because the feeling that tells you something is worth keeping has not been told that building got cheap. That space between the rising line you should be on and the flat line you are actually on is where the damage lives. I think of it as a pricing error you are running inside your own head, and it is the real subject of everything that follows. The law, if I had to put it in one sentence: when building gets cheaper, keeping gets more expensive, because you keep too much of it.
Your gut still prices work at what it used to cost
Why does the keeping instinct lag? Because the signal it runs on was never the true cost of a thing. It was the effort you felt making it. For your entire working life those two moved together. A document that took a week felt like a week of effort, and that felt-effort was a decent proxy for how much the thing was worth and how much it would hurt to throw out. You did not consciously compute value. You felt how hard it was, and let the ache stand in for worth.
AI severed that link. Now a thing that would have taken a week can take twenty minutes, but the output can look just as polished, just as long, just as finished. The felt-effort collapsed. The appearance of value did not. So your instinct, which only ever knew how to read effort, now badly overprices the output, because it is still charging you the old rate for work the machine did in minutes. You look at a strategy memo the model wrote and some part of you files it under “serious document, took real work, do not bin it,” when the honest price of producing it again from scratch is one more prompt.
I call this the cost-memory gap, and it is the engine under the whole problem. The memory of what work used to cost is doing the pricing, and the memory is wrong. This is why the fix is not “try harder to be disciplined.” Discipline assumes you can feel the right answer and are failing to act on it. Here the feeling itself is lying to you. You have to override it with an explicit number, because the intuition that used to do this job has been quietly unplugged.
It is worth separating this clearly from a mistake I have written about before, the velocity illusion, where AI pays you in the feeling of output rather than the output itself. That piece is about mistaking motion for progress on the way in. This one is about the opposite end: once the thing exists, you misprice what it is worth to keep, and you keep it. One is a sin of starting. This is a sin of not finishing the thought, which is deciding to let go.
Cheap to make is not cheap to keep
The deepest reason the throw-away rate has to rise is that the cost of a thing was never mostly in making it. It was in keeping it. Every artifact you hold onto has a carrying cost that runs for as long as you hold it: someone has to maintain it, secure it, remember it exists, work around it, explain it to the next person, and decide every quarter whether it still earns its place. AI cut the one cost that was always the smallest. It did nothing to the ongoing cost, which was always the big one.
Picture the true cost of a single piece of work as two stacked bars. The first bar is what it cost to make, and AI shrank it to a sliver. The second bar is what it costs to keep alive over its life, and AI did not touch it at all. When you decide to keep something, you are not re-spending the sliver. You are signing up for the second bar, in full, for as long as the thing exists. The reason keeping feels free is that the bar you are agreeing to is spread thin across months and paid by future-you, while the bar AI shrank is the one you can see today.
The code numbers make this concrete in a way I find hard to argue with. GitClear studied 211 million lines of code and watched the share that gets rewritten or deleted within a few weeks, what they call churn, climb from about 3.3 percent before AI assistants to 7.1 percent by 2025. It roughly doubled. Copy-pasted code rose from 8.3 to over 12 percent, and 2024 was the first year on record where copied lines outnumbered moved lines. Blocks of five or more duplicated lines went up eightfold. The share of work that was clean-up and refactoring, the maintenance that keeps a codebase alive, fell from a quarter to under a tenth. AI-written code shows up with roughly 1.7 times more issues per pull request. More was produced, more was duplicated, less was tended, and more broke.
Then the bill arrives. Gartner expects forty percent of AI-augmented coding projects to be canceled by 2027, blamed on escalating costs, unclear value, and weak controls. Teams that pay someone to rebuild a quickly-generated application properly routinely spend five to thirty thousand dollars doing it. The lines were nearly free. The software was not, because real software is maintenance, edge cases, security, and ownership, and none of that got cheaper. This is also why I keep pulling founders back to the metric that actually pays: the cost of the first draft is the least interesting number in the whole equation.
| What you built | Cost to make, now | Cost to keep it alive |
|---|---|---|
| An AI-generated feature | An afternoon | Every future release has to not break it; every engineer has to hold it in their head; it widens the security surface forever |
| A strategy deck the model wrote | Twenty minutes | It becomes a reference, gets cited in meetings, and quietly sets a direction nobody re-examined |
| A dashboard or internal tool | A day | It needs an owner, it drifts out of date, and deleting it later feels risky because someone might rely on it |
| A whole product line | Weeks, not years | It takes roadmap, support, attention, and a slice of the team’s identity, indefinitely |
Read that right column and the point lands. The thing AI made nearly free is the thin left column. The fat right column is untouched, and it is the one you sign up for when you decide to keep rather than kill. Every artifact you refuse to throw away is a standing subscription you pay in attention, and AI handed you the ability to open a thousand of them before lunch.
The bias did not get stronger, your output got bigger
There is a version of this argument that says AI makes us more attached to our work, and I do not think that is quite right. The attachment per item is about what it always was. What changed is how many items there are to be attached to. The sunk-cost reflex has a roughly fixed strength, and you now point it at a hundred times more things. The aggregate damage is the bias multiplied by the volume, and only the volume moved.
This matters because it tells you where the fix is not. You will not out-discipline the feeling one item at a time. When you had ten bets a year, you could afford to agonize over each kill, and the agonizing was survivable. When you have ten experiments running by Wednesday, per-item agonizing is itself the bottleneck. You cannot run a careful, emotional, case-by-case trial for every artifact, because there are now too many artifacts, and the trial is exactly the process the sunk-cost bias corrupts. The answer has to be a rule you set once, upstream, that does the killing on a schedule without asking your feelings to vote each time.
I want to be careful not to turn this into a general cheer for doing more. Producing more is not the win here. A pile of a thousand half-built things you cannot bring yourself to delete is worse than ten things you chose on purpose, not better. The gift AI actually gives is optionality: you get to try the thousand, see which two work, and let the other nine hundred and ninety-eight die. You only collect that gift if the dying is real. If you keep them, you did not run a thousand cheap experiments. You accumulated a thousand expensive liabilities and called it progress. The cost of supervising all of it is a tax you pay whether or not the pile ever produces anything.
What OpenAI did that most founders cannot
Come back to the thing that started this. OpenAI threw away a finished, enormously expensive model, and the discipline is cleaner than it first looks, because of what they kept. They did not torch everything. They kept the base model and said they would run more training on it to build the next generation. They threw away the shippable artifact and kept the learning. That distinction is the whole game.
There are two very different things living inside any piece of work you make. There is the artifact, the specific deliverable, the model you could ship or the feature you could keep. And there is the learning, which is everything the making taught you about the problem, the shape of the solution, and what is actually hard. The sunk-cost trap gets its grip by pretending these are the same thing, so that throwing away the artifact feels like throwing away the learning, which feels like admitting the whole effort was waste. It was not. The learning is yours whether or not you ship. Once you can separate them, killing the artifact stops feeling like a loss and starts feeling like what it is, which is banking the learning and dropping the dead weight.
This is why “waste” is the wrong word for a good kill, and why I think the fear of looking wasteful is the emotion doing the real damage. OpenAI did not waste half a billion dollars. It spent half a billion dollars to learn that this particular model was not safe to ship, which is a genuine and valuable thing to know, and then it refused to pay the much larger downstream cost of having shipped it anyway. The waste would have been shipping. The discard was the frugal move. We have the accounting exactly backwards when we treat the visible write-off as the expensive decision and the invisible carrying cost of keeping as free.
There is a reason a company can do this cleanly and an individual founder usually cannot, and it is not that OpenAI has better character. It is that a large organization can afford to make the kill a process rather than a feeling. A committee ran the safety evaluation, a named person owned the standard, and the decision to shelve was a procedure with criteria, not one person staring at a model they had bled for and trying to find the strength to let go. The lesson I take from that is not to admire their resolve. It is to copy their structure. If you want to throw work away at the rate the economics now demand, you cannot rely on summoning the feeling of detachment at the moment of truth, because that is the exact moment the feeling is weakest. You have to decide the rule earlier, when you are calm, and then let the rule do the cutting.
Two things I kept too long, and what they cost me
I should make this concrete with my own receipts, because it is easy to nod along and hard to do. The first one is a product. On one of my companies we built an onboarding flow that an earlier version of me was proud of, because it had taken real engineering and it demoed well. Usage data said customers did not use most of it. For about a year I defended it, reworked it, and added to it, and every argument I made for keeping it traced back, if I am honest, to the fact that we had already built it. When we finally cut three quarters of it, two things happened. Activation went up, because the thing had been in the way, and the team got noticeably faster, because they stopped maintaining a wing of the product nobody lived in. The cost of keeping it was not the engineering to build it. That was long paid. The cost was every week we spent tending a thing we should have killed, plus the customers it quietly cost us.
The second one is smaller and more embarrassing. I keep documents. Decks, memos, plans, the whole paper trail of running companies. For years I treated the ones that took the longest to write as the most precious, so they survived every clean-up, got re-circulated, and kept setting direction. Then AI made writing one of those from scratch a twenty-minute job, and I noticed I was still protecting the old ones on the basis of how hard they had been to produce, which was now completely irrelevant information. A plan is worth keeping because it is still true, not because it was once expensive to write. Half of what I was carrying was neither. Once I started pricing those documents at what they would cost to recreate today, which is almost nothing, I could finally read them for whether they were right, and throw out the ones that were merely old and hard-won. That is the cost-memory gap in my own hands, and I had been living inside it without seeing it.
Throwing more away is not the same as moving faster
I want to head off the obvious misreading, because it is a dangerous one. Raising your throw-away rate is not a license to churn. It is not “ship anything, delete anything, move fast.” The discipline I am describing lives entirely in the kill, not in the build, and churn is what happens when you are undisciplined at both ends. A high throw-away rate done well means you are deliberate about what you keep, not careless about what you make. The volume goes up at the experiment stage and the standard goes up at the keep stage. If only the first moves, you have just built a faster way to accumulate junk.
And there is a real limit I have to be honest about, because it is exactly the limit OpenAI respected. Some things must never have their throw-away rate raised, and they are the things that carry accumulated truth or that cannot be undone. OpenAI kept the base model because it held real learning that would be painful and slow to regenerate. You keep the customer relationship, the trust, the data you cannot buy back, the decision that has no undo button, the institutional memory that only lives in a few people’s heads. The test is not “was this cheap to make.” It is “can I cheaply get this back if I am wrong to let it go.” Cheap to remake, throw away freely. Expensive or impossible to remake, keep and guard, no matter how cheap it was to produce the first time.
This is also where I separate the idea from a cousin of it, the standard drift, where leaning on AI quietly lowers the bar you hold your work to. That is about quality slipping without you noticing. This is nearly the reverse: your bar for what is good might be fine, but your rule for what to keep is miscalibrated, so you hang on to work that clears the quality bar and still should not exist. A thing can be genuinely good and still not worth keeping, because keeping has a cost of its own that has nothing to do with quality.
The parts of the engine, in one place
Let me lay the moving parts side by side, because the argument has a few pieces and they are easy to blur. Each one is a specific claim, and together they are the case for why the number has to move.
| The old world, when building was expensive | The world now, when building is nearly free |
|---|---|
| You started few things, so a large share deserved to survive | You can start many things, so a small share deserves to survive |
| Felt-effort was a decent proxy for value | Felt-effort and value are decoupled; the proxy is now wrong |
| The expense of building rationed how often you faced the keep-or-kill choice | You face the choice constantly, and your bias fires every time |
| Throwing away a six-week build was a real, visible loss | Throwing away a twenty-minute build should feel like nothing, but still doesn’t |
| Keeping something cost you later; you absorbed it | Keeping costs the same as ever, but now you keep far more of it |
Run your eye down the right column and the conclusion is unavoidable. Every single row pushes the correct throw-away rate up, and the only thing holding it down is a reflex that was tuned for the left column. You are not being asked to become ruthless. You are being asked to update a number that the world already updated for you, and that your gut has refused to acknowledge. The whole discipline is closing the gap between the rate you run and the rate the economics now demand.
Set your discard rate before you build, not after
Here is how I have started to actually do this, because an insight that stays an insight is just another artifact I should throw away. The core move is to make the kill decision before the sunk cost exists, because that is the only moment your judgment is clean. After you have built the thing, the bias is already in the room and voting.
First, name the number out loud before you start a batch of work. If my team is going to try eight approaches to a problem, I say at the start that I expect to keep one, maybe two. That sentence does real work. It makes killing six of them the plan rather than a failure, so nobody has to defend having “wasted” effort on the ones we drop. We priced the drops in before we spent, which is the only time the price is honest.
Second, separate the learning from the artifact out loud, every time, the way OpenAI did. When we kill something, I make us write the one or two sentences of what it taught us, and then we delete the thing itself without ceremony. The note is the asset. The artifact was the scaffolding, and you do not keep the scaffolding after the building stands. This single habit does more to defang the sunk-cost feeling than any amount of willpower, because it gives the effort somewhere to live that is not the dead deliverable.
Third, price work at what it costs to recreate today, not at what it cost to make. When I catch myself defending something, I ask one question: if this did not exist, how long would it take to rebuild right now. If the answer is an afternoon, the fact that it originally took a month is irrelevant and I should decide purely on whether I want it to exist. This is the direct antidote to the cost-memory gap, and it is almost mechanical once you install it. You are overriding a broken feeling with a current fact.
Fourth, give the kill to someone who did not build the thing. The person who made it is the worst-placed to judge whether it should survive, because they carry the whole sunk cost in their body. In my companies the monthly kill review is run by someone other than the owner of each item, and the owner’s job is to make the case for keeping, not to decide. It feels adversarial the first time and then it feels like relief, because it takes the impossible emotional decision off the shoulders of the one person who physically cannot make it. This is the same thing OpenAI did by making safety a separate function with its own standard rather than a vote among the people who trained the model.
Fifth, run a kill on a schedule, not on an impulse. Once a month I go looking specifically for things to delete: features, tools, docs, projects, commitments. The brief is not “review and keep what is working.” That framing defaults to keeping. The brief is “what would I not start today,” and those things get cut unless someone makes a live case for them. Defaulting to delete, and forcing the keep to be argued, is the opposite of how the bias wants to run, which is exactly why it works. If this sounds adjacent to how I think about the debt you take on by not doing the hard thing, it is, because a hoard of un-killed work is a debt that compounds in attention.
Questions founders ask about killing work
Is a high throw-away rate just a fancy way of saying move fast and break things?
No, and the difference matters. Moving fast and breaking things is about carelessness on the way in. A high throw-away rate is about discipline on the way out. You can build carefully and still plan to discard most of it, and that is in fact the combination I am arguing for. The moving part is how much you try. The standard for what you keep should go up, not down.
How do I know the right number for my throw-away rate?
There is no universal figure, but the direction is clear: it is higher than it was, and higher than your gut wants. A useful starting discipline is to pick a number before a batch of work and say it out loud, for example that you expect to keep one in five experiments. The exact fraction matters less than the act of setting it in advance, because that is the only moment your judgment is not yet contaminated by what you have already spent.
What is the difference between throwing work away and wasting it?
Wasting it is shipping or keeping something that should have died, and paying the carrying cost forever. Throwing it away cleanly means you extract the learning, bank it, and delete the artifact. OpenAI did not waste a frontier model; it spent money to learn the model was unsafe and then refused to pay the larger cost of shipping it. The write-off you can see is almost never the expensive part.
Doesn’t this encourage a wasteful, scorched-earth culture?
Only if you skip the exceptions, and the exceptions are the whole guardrail. You never raise the throw-away rate on things that are costly or impossible to recreate, or that carry accumulated truth: customer trust, hard-won data, institutional memory, decisions with no undo. For those, keeping is correct even when they were cheap to produce. The rule is cheap-to-remake, throw away freely; expensive-to-remake, guard it.
How is this different from the velocity illusion?
The velocity illusion is about mistaking the feeling of output for real progress while you are producing. This is about what happens after the thing exists, when you misprice what it is worth to keep and hold onto it. One is a sin of starting, the other a sin of not finishing the decision to let go. They often show up in the same person, which is why I treat them as separate habits to fix.
My team feels demoralized when we kill their work. How do I handle that?
Set the throw-away rate before the work starts and say it plainly, so that killing most of it is the plan rather than a verdict on anyone. Then make the learning the deliverable: when something dies, the team writes down what it taught you, and that note is treated as the win. People are not actually attached to artifacts. They are attached to their effort counting for something, and the note is where their effort counts.
Does this apply outside software and AI?
Yes, anywhere the cost of producing something has fallen while the cost of maintaining it has not. That now covers most knowledge work: documents, analyses, designs, campaigns, processes. The sunk-cost reflex and the cost-memory gap are general. AI just made them bite harder because it dropped production cost across so many kinds of work at once, and the keeping cost in every one of them stayed where it was.
What is the single first move if I only do one thing?
Before you defend anything you have built, ask how long it would take to rebuild from scratch today. If the honest answer is an afternoon, delete the memory of what it originally cost and decide only on whether you want it to exist now. That one question dismantles most of the sunk-cost grip, because it forces you to price the thing at today’s cost instead of the remembered one.
Find the thing you are keeping only because you paid for it
If you take one idea from this, make it the inverse relationship, because it is the part that is genuinely counterintuitive and the part everyone gets backwards. The cheaper AI makes it to build, the more of what you build you should expect to throw away. Not because building is bad, but because the thing that used to ration your worst instinct, the sheer expense of making things, is gone, and nothing has replaced it except a number you have to set on purpose.
The companies that win the next few years will not be the ones that produce the most. Everyone can produce now. They will be the ones that discard the most, cleanly, on a schedule, while guarding the handful of things that actually cannot be rebuilt. OpenAI gave us the picture this week, under the brightest lights and the most pressure, and the lesson was not about safety. It was that the discipline of our era is the kill, and that the hardest thing to throw away is always the thing you can most cheaply make again. Go find the thing you are keeping only because you once paid for it, price it at what it would cost today, and let it go.
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. If this one hit home, you might like what I’ve written on the commoditization clock, the enough problem, and telling burnout from ambition.