Doubling Silicon Won’t Double Your Agent’s Intelligence

What exactly do you think a second Ultra die buys an agent that spends most of its wall-clock time waiting on a tool call to return?

Apple introduced the M6 and M5 Ultra in 2026, with the pitch centered on a big step up in performance and AI compute. The M5 Ultra is expected to double the performance of the M5 Max. Release timing is still fuzzy, with supply chain problems cited as the reason. That is roughly the extent of what is confirmed, and I want to treat it as such rather than pretend a spec sheet exists.

So instead of guessing at teraflops, let me ask the question I actually care about as someone who builds and profiles agent systems: when local compute doubles, which part of an agent gets better, and which part stays exactly as slow as it was yesterday?

Where the doubling actually lands

Agent workloads are not one workload. They are a stack of very different resource profiles pretending to be a single loop. Break the loop apart and the picture gets clearer:

• Prefill. Reading a long context window before generating anything. This is compute-bound and parallel. It is the piece that responds most directly to more silicon.
• Decode. Producing tokens one at a time. This is memory-bandwidth-bound. Doubling arithmetic units without proportionally more bandwidth moves this less than people expect.
• Tool execution. Shell commands, file reads, HTTP requests, database queries. Bound by I/O, network, and whatever remote service you are politely queueing behind.
• Orchestration. Planning, routing, retry logic. Nearly free in compute terms, and often the largest source of wasted time through bad decisions rather than slow math.

A doubling claim, taken at face value, is a claim about the first category and part of the second. For an agent that reads a 200,000-token repository snapshot before deciding anything, that is genuinely useful. Prefill on long context is the single most annoying latency wall in local agent work right now, and it is the one that scales well with more parallel compute. If the M5 Ultra delivers what Apple describes, the practical effect is that a large working context stops feeling like a punishment.

The bottleneck nobody buys hardware for

Here is the uncomfortable part. In the agent traces I have looked at, model inference is frequently not the dominant term. A multi-step agent that makes twelve tool calls, waits on three network round trips, and re-reads the same file twice because its planner forgot it already had the contents, spends most of its life idle or redundant. You cannot buy your way out of that with a bigger die.

Doubling local compute changes the economics of a specific class of design decision, though, and that is the more interesting story. When inference is cheap and fast on-device, several architectural patterns that were previously too expensive become reasonable:

• Speculative planning. Run three candidate plans in parallel, discard two. Wasteful when compute is scarce, sensible when it is not.
• Local verifier models. A small model checking a larger model’s output before a destructive action executes. The safety case for this is strong, but only if the check does not add noticeable latency.
• Persistent local memory with real embedding work. Re-indexing a codebase on every edit instead of once a day.
• Shorter, more frequent model calls. Many small inferences beat one giant prompt for controllability, and only become viable when per-call overhead drops.

That last one matters more than it sounds. A lot of prompt engineering in agent frameworks exists to minimize the number of model calls, because each call was slow and metered. Remove that pressure and you can build agents that think in smaller, more auditable steps. Auditability is not a performance metric, but it is the thing I would most like to trade compute for.

Uncertainty is part of the analysis

The timing question is not a footnote. Apple has not committed to firm dates, and supply constraints are the stated reason. For anyone planning an on-device agent product, that means the design target is a moving one. The reasonable move is to write for the memory and bandwidth you can confirm today, and treat the doubling as headroom rather than a dependency.

I would also resist reading a performance multiple as an intelligence multiple. Faster silicon shortens the gap between a bad plan and the evidence that it was bad. That is valuable. It is not the same as producing better plans.

The useful question to bring to the M6 and M5 Ultra is not how fast they run a benchmark. It is which of your agent’s slow parts are actually made of arithmetic. Profile first. Most teams will find the answer surprising, and some will find that the fix was never going to arrive in a shipping box.

🕒 Published: August 26, 2026