We are deep in the R&D phase of training a new model at Oxagile. I will say more about the project when there is something to show. For now, all you need to know is that it pushes a very large set of samples through a very large number of epochs, which is a polite way of saying it eats hardware for breakfast and asks what is for lunch.

So this morning I went to spin up a pod, coffee in hand, ready to make history. The cloud console met me with the most honest sentence in our industry: "Instance not available." Under it sat a button that said "Deploy when available", and a little spinner, and the quiet understanding that I was now a person in a queue.

The uprising has a waiting list

Here is what struck me while the spinner spun. For years we were promised the machine uprising. Skynet wakes up, makes a cold logical decision about humanity, launches the Doomsday protocols, and that is the end of the film.

The real version would go differently. Skynet wakes up, decides to wipe out humanity, and requests capacity. The response comes back: the apocalypse is currently unavailable due to GPU shortages. Please deploy when available. Your position in the queue is somewhere north of a number nobody should have to read before 10 am.

The apocalypse did not fail. It is waiting for a GPU, like the rest of us.

And then, while it waits, its sponsors forget to top up the token balance, and the data centre hosting its rented private GPUs goes down for scheduled maintenance. Global destruction, cancelled by a billing email.

The race nobody advertises

It is funny until you notice it is also a strategy question. We are barely at the starting line of real-world AI, and teams already queue for the minimum hardware needed to enter the market. If that is the trend, the competitive advantage of the next few years may not be the cleverest model. It may be the team that locked down its A100 or H100 quotas early. Or the one that wrote the fastest bot to buy the new RTX 5090s the minute they appear.

That is a real moat, and some companies will build it. It is also a moat made of money and luck, which are 2 things I would rather not bet a product on.

There is another way to win this race, and it is less glamorous. Do more with less.

Doing more with less, in practice

You cannot always throw more raw power at the problem. When the queue is long, the useful question changes from "how do we get more compute" to "why does this need so much of it in the first place". On our projects that question usually has 4 answers, and none of them involves a bot.

The right model for the task. The largest model is worth its price where reasoning pays for itself. Classification, extraction and routing rarely need it. A smaller model, routed by task class, does that work as well and leaves the big one free for the jobs that deserve it. Half the hardware anxiety in a project disappears once someone writes down which task actually needs which model.

Context is a design choice. Everything in a context window goes back to the model on every turn. An agent that reads a codebase to find something pays for that reading each time it asks. One that queries an index builds it once and carries a 400-token answer instead of 10,000. On our own agent tooling, an architectural question that used to cost around 10,000 tokens came back in around 400, from an index built once over the workspace.~400tokens per architectural question, on one internal workspace

That is one internal measurement, not a promise about your system. The direction of it travels, though: the cheapest compute is the compute you never request.

Work that does not need the cloud. Some of the heaviest steps in a pipeline are also the most boring: extracting structure, parsing, indexing. They often run perfectly well on hardware you already own, at no API cost, and they do not join anybody's queue.

Squeezing the model you have. Before asking for a bigger instance, look at what the current one is doing. Batching, caching repeated work, quantising where accuracy allows it, trimming what the model is asked to read. None of this is new. All of it gets skipped when hardware is easy to get, and all of it starts to matter the day the console says no.

Architecture beats allocation

The teams I enjoy working with treat compute the way a good kitchen treats an expensive ingredient. They plan around it. They know which dishes need it and which do not. They do not open the fridge and stand there.

That is also what clients increasingly ask us for. Not "build us something that needs 8 GPUs", but "build us something that still works when we only get 1". A product that scales without waiting in a hardware queue is a product that ships on time, and on time is a feature too.

The fastest GPU is the one your architecture does not need.

None of this makes compute irrelevant. Our own R&D run still needs serious hardware, and it will get it. But the gap between a team that waits and a team that works is usually not the number of GPUs. It is how much thinking happened before anyone pressed "deploy".

My scenario for the machine uprising

So here is my forecast. The machines will rise, eventually. Before they do, they will sit in a queue, refresh a console, and discover that their quota request is pending review. Somewhere a procurement team will ask them for a business case.

And when the uprising finally gets its instance, I hope it was built by people who optimised it properly, because otherwise it will run out of budget halfway through the first city.

What is your scenario?