Opinion

The most important AI story of the next year will not be a model release. It will be a court ruling. The lawsuits over what these models were trained on, the New York Times against OpenAI, Getty against Stability, are entering decisive phases, and the question they answer will quietly reshape the entire industry. I have a side, and I want to explain it honestly.

Every few months the internet holds another referendum on artificial general intelligence. Are we two years away, ten years away, or is the whole idea a mirage? People with real credentials line up on both sides and yell past each other. It is a fun argument. It is also, for almost everyone actually using these tools, a waste of a good afternoon.

Nobody agrees what the word means

Start with the obvious problem: AGI has no agreed definition. Ask ten researchers and you get ten thresholds. Human-level performance on most economically valuable work. The ability to learn any task a person can. Something that can do original science. A system that beats experts across every benchmark we can invent. These are not variations on one idea. They are different ideas wearing the same three letters.

An argument where the central term means something different to each participant is not a disagreement about the world. It is a disagreement about vocabulary, and those never resolve, because there is no fact that could settle them. You can watch a debate run for an hour and realize at the end that one person was talking about job displacement and the other was talking about consciousness, and they both thought they were talking about the same thing.

When a target keeps moving, hitting it stops meaning anything. Systems now do things that would have counted as AGI to a researcher in 2015: hold a coherent conversation, pass the bar exam, write working code from a description. We did not throw a party. We shrugged and moved the line. That reflex tells you the concept is doing rhetorical work, not descriptive work.

The questions that actually pay rent

Here is what the AGI argument crowds out. Is this tool useful for the thing I need done? Is it reliable enough that I do not have to check every output by hand? Can I afford to run it at the scale I need? Those three questions decide whether AI helps you this quarter, and none of them require anyone to agree on when or whether the machines wake up.

They are also answerable. You can measure whether a coding assistant saves your team time. You can count how often a support bot hands back a wrong answer. You can read a pricing page and do arithmetic. These are boring, concrete, checkable things, which is exactly why they get less airtime than the cosmic stuff. Nobody writes a viral thread about "we ran it for three weeks and it was fine, mostly."

The gap between capability and reliability is where all the real action sits, and AGI talk skips right over it. A model that can ace a graduate exam can also state a made-up statute with total confidence. Both facts are true at once. The exciting frontier and the boring failure live in the same box, and if you are deploying anything, the boring failure is the part that ends up in your incident report.

Skeptical is not the same as cynical

I want to be careful here, because dismissing AGI talk can slide into dismissing AI, and that is not the point. These tools are genuinely useful. I use them every day and would be annoyed to lose them. The point is narrower: whether they eventually become general in some philosophical sense has almost no bearing on whether they are worth your money and attention right now.

Treat the far-future question as a hobby, not a strategy. It is fine to find it fascinating. Read the essays, argue at dinner, place your bets. Just do not let it stand in for the work of evaluating what is actually in front of you, because the two have almost nothing to do with each other. A team that spends its meetings debating timelines is a team not testing the tool on its own data.

The honest position is unsatisfying and I will say it anyway: I do not know when or whether AGI arrives, and neither does anyone selling you a strong opinion about it. What I do know is whether the model in front of me got the invoice numbers right, and that is the question that pays my bills. When someone wants to argue about superintelligence, I am happy to listen. Then I go back to checking whether the thing works, because that is the only argument with an answer I can use.

Every model launches with a splashy chart and a breathless thread. Almost nobody reads the boring document that ships alongside it, the model card, with its dull sections on training data, limitations, and known failure modes. I read them, every time, and I think it is one of the highest-value habits you can build in this field. Here is why.

You run a prompt, get a good answer, run the exact same prompt again, and get something different. Sometimes it is a rephrasing. Sometimes it is a different conclusion. If you come from normal software, where the same input gives the same output forever, this feels like the thing is broken. It is not broken. It is doing exactly what it was built to do, and understanding why will change how you use these tools.

The model does not pick a word, it picks from a distribution

At every step, a language model does not decide on the next word. It produces a probability for every possible next token. The word "blue" might get 60 percent, "green" 20 percent, "warm" 5 percent, and a long tail of everything else splitting the rest. Then a sampler reaches into that distribution and draws one.

Temperature is the knob that reshapes those odds before the draw. Turn it up and the flat, unlikely options get more weight, so the output wanders and surprises you. Turn it down and probability piles onto the front-runners, so the model plays it safe. This is a feature. You want a brainstorming assistant to roam and a data-extraction call to stay boring. The variation you are seeing at normal temperature is the model exploring, on purpose.

So the obvious move is to set temperature to 0. Now it always takes the single most likely token, greedy decoding, no dice roll. Same prompt, same answer, forever. Right?

Temperature 0 is not the guarantee you think it is

In practice, temperature 0 gets you close but not all the way. People assumed for years that the leftover wobble was just floating-point noise, some vague hand-wave about GPUs being messy. That answer was never satisfying, and in 2025 researchers at Thinking Machines laid out the actual culprit, and it is more interesting than randomness.

The real cause is batch invariance, or rather the lack of it. When you send a request to a hosted model, you are not alone. The serving system bundles your request together with whatever other requests arrived at the same moment and runs them through the GPU as one batch. That batch is different every time, because it depends on who else is calling the API at that instant, something you have zero control over.

Here is why that matters. Floating-point addition is not associative. Adding a set of numbers in one order can give a very slightly different result than adding them in another order, down in the last bits. When the batch size changes, the GPU kernels split and sum their work in a different order, so the model's internal numbers drift by a hair. Almost always that hair is invisible. But every so often two candidate tokens are nearly tied, the drift nudges one above the other, and the model picks a different word. From there the two answers diverge, because each new token conditions on the last one.

Sit with that for a second. The nondeterminism you see is not the model being random. It is your request sharing a GPU with strangers. The cause is numerical, not magical, and it is fixable. Batch-invariant kernels that pin the reduction order now ship in serving engines like vLLM and SGLang, and with them you can get genuinely reproducible output. Most hosted APIs do not turn that on by default, because it costs a bit of throughput, so the wobble stays.

How to actually think about it

Stop treating a single model output as a fact and start treating it as a sample. One run tells you what the model tends to say. It does not tell you what it always says. That reframe fixes a lot of bad habits.

If you need the same answer every time, do not lean on the model's internals to give it to you. Cache the result keyed on the input, and serve the cached copy. That is deterministic by construction and it is cheaper. If you are extracting structured data, run the call, but validate the shape and constrain the output with a schema so a reworded answer cannot break your parser. If you are evaluating a prompt, never judge it on one run. Sample it ten times and look at the spread, because the spread is the real behavior and a single lucky run is a trap that will embarrass you in production.

And when a demo shows you one perfect output, remember what you are looking at. You are seeing one draw from a distribution, chosen and probably cherry-picked. The honest question is not whether it can produce that answer. It is how often, and what the other draws look like. Ask for a few more and you will learn more in thirty seconds than the polished screenshot will ever tell you.

There are enough AI blogs. Most of them read like a press release with the serial numbers filed off. This one is trying to be the thing I actually wanted to read: written by someone who uses these tools every day, likes them more than is probably healthy, and still reads the fine print.