It’s 2am and your agent pipeline is dead. Not broken-code dead, just… stuck. Every request is timing out against one provider’s endpoint, and your entire orchestration layer, the retry logic, the tool-calling schema, the token accounting, all of it was built assuming that one endpoint would answer. You sit there staring at a stack trace that isn’t really a stack trace. It’s an architecture decision you made six months ago, finally sending its invoice.
I thought about that feeling when I read that Crusoe walked away from a $1.25 billion turbine order.
What actually happened
Crusoe, the Denver-based AI data center builder that recently raised $3.9 billion, scrapped its agreement to buy 29 natural-gas-fired Superpower turbines from Boom Supersonic, another Denver company. The turbines were a new line of stationary power plants, 42 megawatts apiece. Crusoe was the first customer Boom had publicly named for its power business. Now Boom doesn’t have that launch customer anymore.
Crusoe’s stated reason is the part that should interest anyone who builds systems: it’s moving toward a flexible mix of energy sources instead of committing to one hardware line from one supplier.
That’s it. That’s the whole story, and it’s a small story if you read it as business news. Read it as an architecture story and it gets more useful.
The coupling problem, but with turbines
Every bot builder I know has made this exact bet at some smaller scale. You find a component that fits beautifully. The API is clean, the pricing is good, the docs are great. So you build around it. Not behind an abstraction, around it. Your prompt templates assume its formatting quirks. Your function-calling logic assumes its schema. Your cost model assumes its per-token math.
Then the component changes, or gets deprecated, or the company pivots, or rate limits tighten, and you discover that what you built wasn’t a bot. It was a wrapper around someone else’s roadmap.
Crusoe placed a 29-unit bet on a turbine line from a company whose main business is supersonic aircraft. On paper it’s elegant. Aerospace turbine expertise, local supplier, same city, one procurement relationship instead of twelve. The kind of clean dependency graph that makes an architect happy.
Except power for AI compute is exactly the kind of input where you want optionality. Gas prices move. Grid interconnect queues move. Solar and storage economics move. Regulatory conditions move by county. Locking 29 units of capacity to one new product line from one vendor means your build schedule inherits that vendor’s manufacturing schedule, their yield problems, their learning curve on a product they’ve never shipped at volume.
Flexible mix is just dependency injection
When Crusoe says “flexible mix of energy sources,” translate it into terms we use daily. They want an interface, not an implementation. Power in, watts measured, source swappable. Whoever gives them the best cost-per-megawatt this quarter gets the order this quarter.
That’s the same reason your bot should talk to a model through your own thin layer:
- One adapter per provider, each one normalizing requests and responses into shapes your code owns, not shapes a vendor owns.
- Capability flags instead of assumptions. Does this model do structured output? Vision? Long context? Ask the adapter, don’t hardcode the answer.
- A routing policy that’s data, not code. Cheap model for classification, stronger model for reasoning steps, and the ability to change that mapping without a deploy.
- Cost and latency measured per route so switching is an informed decision rather than a panic move.
None of that is clever. It’s boring plumbing, and it’s the plumbing that lets you walk away from a bad bet cheaply.
The cost of being the launch customer
There’s a second lesson here, and it cuts the other way. Boom lost more than an order. It lost the reference customer that made the power business credible to the next buyer. If you’ve ever been the first production user of a new framework or a new model release, you know both sides of that trade. You get attention, influence, maybe favorable terms. You also absorb the risk of shipping on top of something unproven.
Being an early adopter is a reasonable strategy. Being an early adopter without an exit path is the mistake. Crusoe had an exit path. It used it.
What I’d take back to my own repo
I’d go looking for the places where a supplier’s name appears in my business logic. Model names in prompt files. Provider-specific error codes in retry handlers. Vendor SDK types crossing into domain code. Every one of those is a small 29-turbine order.
Crusoe had $3.9 billion in fresh capital and still decided that flexibility beat a single big commitment. A company with that much room to absorb a wrong call chose optionality anyway. Most of us building bots have a lot less runway and a lot faster-moving dependency tree. The reasoning applies more to us, not less.
🕒 Published: