The Mainframe Era of AI Is Ending

My Anthropic bill went from $25 a day to $800 a day in the week I started using OpenClaw seriously.

Thirty-two times the cost. The code was still broken at the end of it.

Claude would loop. It would insist a function existed that didn't. It would apologize, try again, apologize again. "Oops you are right, I shouldn't of did that." I paid for that sentence. Real money. At commercial rates. Multiple times in a single session.

The 90 minutes of looping on a phantom import? Billed. The four apology cycles? Billed. The retry that finally got close but still missed? Billed.

The landlord doesn't care if the work was right. The landlord cashes the check either way.

That is what bothers me about renting intelligence. I also rent its mistakes. A higher bill doesn't mean I got further.

I don't think the answer is to stop using capable cloud models. I think it's to stop making them the only place my work can happen.

KB

---

The bill that matters

I needed working code. That's the standard the bill has to answer to, whether I'm paying a provider or buying a machine.

A local model might have failed on that code too. It might have failed for longer. I would have avoided those particular API charges while still losing the day. My bill explains why I care; it doesn't prove a hardware purchase would have saved the same amount.

That is the missing line in a lot of local-AI math: the cost of getting the work accepted.

If a cloud call costs more but gets the answer right, it can be cheaper than a local loop that needs constant supervision. If a local model handles a repeated task reliably, paying a remote provider for every repetition may be unnecessary. The comparison has to include retries and my time, not just the price of a token.

Buying the box moves costs around. Electricity, repairs, hardware depreciation, setup, and maintenance don't vanish because there is no invoice for each generation. Neither does the cloud bill for work the local model cannot do.

I would compare the same workload on both paths, with the same acceptance criteria. How often does each finish? How long does it take? How much intervention does it need? What does the whole month cost? An assumed split between easy local work and hard cloud work can't answer that. Some short calls are cheap already; some apparently simple tasks become difficult when the input is messy.

Cost is one reason to want another path. I also want a say in how that path works.

What I mean by sovereign AI

My ideal is my own hardware, downloaded weights, and rules I control.

A model running on a box I own doesn't need a provider's inference endpoint to produce an answer. I can keep a particular version instead of rebuilding my workflow around whichever version a service offers next. That is a meaningful kind of control, even with licenses on the weights and dependencies in the software.

A rented server gives me control over software without ownership of the machine. A local agent can keep its instructions and files on my computer while still sending prompts to a cloud model. The agent organizes the work; the model produces the answer. Calling the whole arrangement local hides where the inference runs and where the data goes.

That distinction matters when the reason for keeping work nearby is privacy. An agent can call a search engine, send an email, use cloud storage, or upload a log. Speech transcription can be another external service. Keeping prompts out of a model provider's endpoint doesn't keep the rest of those connections inside my network.

If a task is meant to stay local, the whole path needs to stay local. That includes the tools, logs, backups, and whatever turns audio into text. I don't want a routing layer quietly sending a sensitive document to the cloud because the local attempt failed. Failure should not change the privacy agreement.

The computer can fail or be compromised, and nearby inference doesn't justify unrestricted access to files and credentials. I want narrow permissions and approval before consequential actions. Owning more of the stack gives me more responsibility for enforcing those choices. It isn't a security guarantee, and it doesn't settle ownership of every output.

---

The work it can do

The next question is whether the model I can run will do enough useful work to justify that responsibility.

There are real models to experiment with, not just promises. The Qwen3 release is one example of a family with downloadable weights and local deployment options. It gives me something to test against my work, not proof that any particular member can replace the cloud model I use.

Fitting a model into memory is not the same as getting useful work out of it. The checkpoint, quantization, context length, and serving software all matter. GPU memory is not interchangeable with the system RAM printed on a computer's box. A model that answers a short question acceptably may still struggle through a long coding task.

I don't need a local model to win every benchmark. I need it to clear the bar for the task I give it. Extracting fields from a document and untangling a broken codebase are not the same job.

That also changes the hardware advice. Start with the machine you have and a task you can check. Find out what fails before buying a computer to fix it. More memory won't repair every reasoning failure, and a faster answer isn't useful if I spend longer correcting it.

The cloud gives me access to capacity and models I cannot sensibly operate myself. I should pay for that when it earns the call. What I object to is needing it for everything by default.

Where I would build

The useful business opportunity is making those choices easier to manage. Someone processing the same kinds of documents may want lower variable costs. Someone else needs a stable model version or a tighter boundary around data. I would build around that constraint rather than sell everyone the same box.

A routing layer should let someone compare results and decide which jobs belong where. A model manager should make updates reversible. Those are useful products even if the customer keeps renting cloud capacity indefinitely.

For regulated work, the product also has to fit the organization's obligations. Healthcare, law, and finance aren't blanket bans on cloud services, and running locally doesn't grant automatic compliance. Selling the word sovereignty doesn't do that work for the customer.

The investment temptation

I am a guy with opinions and a brokerage account. A shift toward local inference is going to get my attention.

Memory, chips, systems, and compute marketplaces are all places I would look. But a technology becoming useful does not guarantee that its suppliers' stocks are cheap, or that a token captures any of the value flowing through a network.

With decentralized compute, I would want to know who supplies the machines, who pays to use them, how reliable the service is, and why the token is necessary. A rented GPU somewhere else is still a rented GPU. Putting a market around it doesn't turn it into hardware I own.

I also think restricting access to model weights is a bad way for the US to compete. If useful models can be distributed openly, I want American companies and researchers participating, not treating access as something only a few institutions should control.

I care about what people ship and the terms on which I can use it. A model's country of origin doesn't establish its privacy properties. My preference for open access isn't a prediction that one country must win, and being excited about the technology doesn't mean the money moves in only one direction.

---

The mainframe analogy

When I call this the end of the mainframe era, I mean the end of treating centralized access as the only serious option. I don't mean cloud computing is about to disappear.

The part of the personal-computer story that interests me is the operator getting a machine on their desk. Not a machine that beats every larger system. One they can use without negotiating for every turn.

That's the extent of the analogy. An AI agent isn't ordinary desktop software, and a machine on my desk cannot absorb every remote workload. What I want is the ability to try something, keep a version, inspect the surrounding software, and decide when an outside service is worth using.

My reason for caring

I built cypher.camp around the idea that one person can get more done with good tools and judgment. That gives me a stake in this argument. It doesn't prove a productivity multiplier or make my product the answer to every reader's problem.

The bill full of apologies makes me want control over the next attempt. I want to decide what the agent is allowed to spend, when it has to ask me, and when the loop stops. Those rules need to live in the software around the model, rather than depend on the model promising to do better. I want to be able to change the model without abandoning the work.

For someone who wants to try this, I would start with one non-sensitive task whose result is easy to check. Keep the instructions and inputs portable. Compare a local option with the cloud option. Keep the better path for that job, and don't buy hardware until the work gives you a reason.

I want the cloud to be a choice, not the only place my work can happen.