The Fragile Colossus — On SpaceX's Trillion-Dollar Merger, Anthropic's Naked Code, and the Chain That Broke

Three things happened in the same week. They look unrelated until you draw the dependency graph, and then they turn out to be the same story told at three different orders of magnitude.

Musk filed to take SpaceX public at one point seven five trillion dollars. Anthropic accidentally shipped the source code of its flagship developer product to npm. And a company most people outside the labs have never heard of lost four terabytes of data — including recordings of the humans who train frontier models — through an open-source proxy library that nobody was auditing.

I have spent about fifteen years building software, the last stretch of it building agentic systems that run in production, and I have shipped a smaller version of every mistake in this article. That is the only reason I think the pattern is worth writing down rather than gawking at.

One Company, Four Regulators

Start with the number, because the number is what got the headlines. SpaceX submitted a confidential S-1 to the Securities and Exchange Commission on the first of April at a valuation of one point seven five trillion dollars, with five banks on the cover: Bank of America, Citigroup, Goldman Sachs, JPMorgan Chase, Morgan Stanley. The target is seventy-five billion dollars raised in a single offering, roughly three times the largest American IPO on record, aiming for June. Ahead of OpenAI. Ahead of Anthropic.

The sequencing matters more than the valuation. Three mega-IPOs are queued up this year, and the first one out of the gate sets the comparable that the other two get priced against. That is why June. Whoever prints first defines what a dollar of AI revenue is worth for everyone standing behind them, and going second means inheriting a multiple you never got to negotiate. It is the same dynamic as rushing a spec to publication ahead of a competitor. You do not do it because the spec is ready. You do it because the first mover writes the vocabulary everyone else has to argue in.

The number is the output. The merger is the input. SpaceX and xAI are now one company — the financial press has settled on "Space-AI conglomerate," which mostly tells you the press does not know what to call it either. The combined entity was marked at one point two five trillion before the filing. That extra five hundred billion is the market pricing what happens when orbital infrastructure and model training sit inside the same balance sheet, the same capex plan, and the same procurement org.

The premium is not crazy. The vertical integration here is real engineering rather than a slide. Training runs are gated on power, cooling, and interconnect. Inference is gated on getting tokens to users at acceptable latency. A company that owns launch, owns the largest constellation in low Earth orbit, and owns the model has at least a credible path to putting inference closer to demand and skipping a layer of terrestrial backhaul. Anyone who has tried to negotiate GPU capacity and network transit in the same quarter understands why you would pay to own both ends of that.

The problem is the org chart on the other side of the table. The SEC regulates the offering. The FAA regulates the launches. The FCC regulates the spectrum. The Department of Defense contracts for the payload. Each of those bodies has a complete view of its own slice and no view of the composite. No regulator's mandate is "the entity."

Merging two heavily regulated businesses does not double the oversight. It creates a seam, and the seam is where nobody is looking.

I have watched this exact failure inside a single codebase. Two services, both with good coverage, both owned by teams who know their domain cold. The outage happens in the contract between them, because coverage was measured per service and the integration was somebody's implicit assumption. The regulatory version has the same shape and considerably worse instrumentation. When my two services disagree about a null field, I get paged. When the FAA and the SEC hold incompatible models of the same company, nobody gets paged at all.

If you want a precedent for the financing, the railroad build-out of the 1870s is closer than anything in tech. Enormous capital committed against infrastructure that was genuinely transformative and genuinely early, followed by the Panic of 1873, six years of depression, and four hundred failed banks. Notice what did and did not survive. The railroads got built and are still there. The financing structure came apart. Both things are usually true at once, which is what makes this so hard to argue about in public — the bears are right about the equity, the bulls are right about the technology, and they spend a decade talking past each other.

Sixty Megabytes of Moat

On the thirty-first of March, Anthropic published version 2.1.88 of the Claude Code package to npm. Inside the tarball was a source map. Sixty megabytes, roughly five hundred thousand lines across nineteen hundred files: the internal architecture of the product, unminified, readable, complete.

Published. Indexed. Downloaded. Forked. Eight thousand one hundred repositories appeared on GitHub before anyone could respond.

The cause is boring, and the boringness is the point. A debug artifact survived a production build. Anthropic's spokesperson called it "a release packaging issue caused by human error, not a security breach," and that description is accurate. Nobody was breached. A map file that should have been excluded at pack time was not.

Look at the mechanics, because that is the part you can actually act on. A source map is a normal build output. Every major bundler emits one by default, and it exists precisely so that production stack traces stay readable. Keeping it out of the published tarball depends on the files array in package.json, or an .npmignore, or a bundler flag — three mechanisms with different precedence rules, any of which a refactor can quietly invalidate. And nothing downstream catches the result. The build is green. The tests pass. The package installs and works. No gate in the pipeline asks the only question that mattered: did we ship a file we did not intend to ship? Then publish runs, and publish is effectively irreversible. You can unpublish. You cannot un-download.

What followed did more damage than the leak. Anthropic filed DMCA takedown notices and GitHub complied, but the notices — drafted fast, which in practice means drafted broadly — swept up not only repositories hosting the leaked source but thousands of forks of Anthropic's own public Claude Code repository. Open-source contributors. People building integrations. People who had spent months advocating for the tool, waking up to find their repos disabled by the vendor they were promoting. Boris Cherny, who runs Claude Code, acknowledged the over-reach, retracted the bulk of the notices, and narrowed the takedown to ninety-six repositories.

The retraction was quick and it was correct. It also did not buy back much. Reversing a takedown restores a repository. It does not restore a developer's assumption that the vendor's automated legal machinery will never point at them by mistake. That assumption is load-bearing for every platform business on earth, and it sits on no balance sheet, which is exactly why it gets spent so casually.

There is a second-order lesson in the takedown, and I expect it to matter more every year. The notices went out at machine speed against a target set assembled by pattern match: this repository contains strings that look like our code. Forks of your own public repository match that pattern perfectly. Any enforcement system fast enough to be useful against a leak spreading at fork speed is, by construction, too fast for a human to review its target list before it fires. The false positives land on the people least equipped to absorb them. If you are going to automate a weapon, you own its precision, and precision is the first thing that gets cut when the clock is running.

Then the detail I keep coming back to. The leaked repository became the fastest-growing in GitHub's history. Read that twice. Not a new framework. Not a breakthrough. A packaging mistake. Almost nobody cloning it can do anything useful with half a million lines of someone else's internal tooling. The pull was never the code itself — people wanted confirmation that the thing was built by engineers making ordinary trade-offs under deadline, the same as everyone else.

Which points at the real lesson: the source was never the moat. If five hundred thousand lines going public could destroy Anthropic's position, then the position was one publish deep the whole time, and everyone building on it was mispricing their risk. It obviously isn't. The moat is the weights, the training pipeline, the inference capacity, the enterprise contracts, the distribution. What the leak destroyed is the story that the source was worth protecting — and a large share of the commercial tooling layer in this industry has been quietly pricing that story into its valuation.

So the review I would run after this is not "how did the file get into the tarball." That is a one-line fix plus a pipeline check, and you should do it, but it is not the interesting output. The interesting exercise is to list every asset your company currently treats as a secret and mark the ones that would genuinely cost you something if they were public on Monday. Every time I have run that exercise the list came back far shorter than anyone expected, and the effort spent guarding the rest turned out to be budget that could have gone to the things that actually compound.

The Dependency Nobody Owns

The third story is the one that should worry you most, and it will get the least attention, because it has no trillion-dollar number attached and no famous logo to embarrass.

Mercor is a recruiting startup. Founded in 2023, Y Combinator backed, contracts with OpenAI, Anthropic, and other labs to source and manage the human experts — scientists, doctors, lawyers, linguists — who train frontier models through reinforcement learning from human feedback. Mercor is not famous. It is load-bearing, which in this economy is the more dangerous thing to be, because load-bearing creates dependency, dependency creates attack surface, and attack surface nobody has bothered to name is where the interesting people go to work.

LiteLLM is an open-source proxy. One interface, many model providers, with retries and key handling and cost tracking thrown in. It gets millions of downloads a day precisely because it is small and does one job reliably. I have it in production. So do most people reading this, whether they know it or not — it usually arrives transitively, three levels down, pulled in by a framework you picked for unrelated reasons.

Someone — attributed to Lapsus$, and attribution in this field is practiced with more confidence than evidence — injected malicious code into LiteLLM. Mercor's systems pulled the compromised package. Through that one dependency, the attackers claim four terabytes: source code, databases, VPN credentials, Slack history, and video recordings of sessions between Mercor's AI systems and the human contractors who train the models that Anthropic and OpenAI serve to millions of users.

Sit with where that library sits in the graph. A model proxy holds provider API keys by design. That is its entire function. It is the one component in the stack whose job is to be trusted with credentials for every vendor you use, so a compromise there is never partial. And because it is a proxy, every request and every response passes through it — which, for a company in the RLHF business, means the training data passes through it too. The attackers did not have to go find the crown jewels. The crown jewels were being routed through the thing they already owned.

This is the actual topology of the risk: not a single point of failure but a graph of implicit trust, where every node assumes the integrity of its neighbors, none verifies it, and compromise propagates at the speed of a dependency install.

Mercor says it was "one of thousands" affected. One of thousands. Snyk reports the malicious code was identified and removed "within hours," which sounds like a decent response time until you multiply hours by the download rate. A package pulled millions of times a day, poisoned for a few hours, lands in some number of build artifacts that nobody has enumerated and nobody is going to. Those artifacts are now baked into container images, pinned in lockfiles, running in production. Pulling the bad version from the registry does not reach a single one of them. The registry is clean. The blast radius is not.

Here is the uncomfortable part for anyone shipping agentic systems, which is what I do for a living. The standard defenses are weak against this specific shape. Lockfiles pin versions, which helps only if the compromise predates your pin. Dependabot tells you to upgrade, which is the exact action that pulls the poisoned release. Reproducible builds prove your artifact matches your source and say nothing about whether your source's dependencies are honest. Scanners match known signatures, and a fresh injection has no signature during the window that decides everything.

What does help is narrower and much less satisfying. Hold provider keys somewhere the dependency tree cannot reach, so a compromised proxy gets a scoped, short-lived token instead of your account. Put egress rules on the process, so exfiltration needs a destination it is permitted to talk to — four terabytes has to go somewhere, and that is the cheapest control on this list. Delay transitive upgrades behind a cooling-off window instead of tracking latest, and accept the trade: a few days of patch latency in exchange for not being in the first wave. None of that prevents the compromise. All of it shrinks the blast radius, which is the only variable you actually control.

None of that is free, and I would rather be honest about the bill than sell you a checklist. Scoped short-lived tokens mean running a secrets broker and rotating on a schedule, which is a service somebody now owns and carries a pager for. Egress allowlists break every time a vendor quietly moves an endpoint, and the first month of that is genuinely miserable. The cooling-off window means deliberately running a known-vulnerable version for a few days, which is a real trade and not a clever free lunch. I take all three anyway. The alternative is a control set that looks complete on a slide and does nothing during the only hours that decide the outcome.

The Common Failure Mode

Three stories, one shape.

SpaceX merges launch and model training into an entity worth nearly two trillion dollars, and no single regulator has standing over the result. Anthropic, the company that wrote the safety playbook, publishes its own source by accident and then damages its own community during the cleanup. Mercor, embedded in the training pipeline of every major lab, is compromised through a dependency small enough that its risk was never on anyone's list.

In all three, no component failed. That is the part I want to underline. The publish worked exactly as specified. The DMCA process worked — it removed what it was pointed at, and being pointed at the wrong thing is not a defect in the process. LiteLLM did what a proxy does. Each regulator did its job. Every one of these failures lived in the assumptions between components, and assumptions have no owner, no budget, no test, and no line in the postmortem template.

We are building at a scale where that gap costs more than it used to. SpaceX near two trillion. OpenAI approaching its own IPO at eight hundred and fifty-two billion. Anthropic behind them. All of them stand on the same substrate: open-source packages maintained by a handful of people doing it after work, release pipelines where one misplaced file goes out irreversibly, oversight split across agencies drawn up for industries that no longer exist in that form, and a capital market that prices appetite as though appetite were the same thing as throughput.

Durability is not a function of size. It is a function of how many untested assumptions you are standing on, and that number grows faster than headcount, faster than revenue, and much faster than anyone's ability to enumerate it.

So, concretely, for the week ahead. Walk your dependency tree, find the components that hold credentials, and move those credentials out of the tree's reach. Add one pipeline check that diffs the file list of your published artifact against the file list you intended, and fail the build on a surprise. Then write down the five external things you trust with no verification, put a rough dollar figure beside each for the day it breaks, and find out who owns it. Not who uses it. Who owns it. That last question is the one that keeps coming back empty.

The S-1 is filed. The source is public. The chain is breached. And somewhere right now a model, trained on data gathered by a company that was compromised through a library nobody was watching, is producing output that several million people will read tomorrow and act on, because the system has worked every previous time. That is the entire argument for the assumption. It is also the only argument for it.

Build the colossus. File the S-1. Ship the package. Trust the chain — realistically you have no alternative, and I am not going to pretend otherwise. But write down what you are trusting, price what it costs you the day it breaks, and check whether anyone actually owns it. Across most of this industry right now, the honest answer to that last one is nobody.