Over the past few months, many engineers have been absorbed by the excitement around Agentic Coding. It really works: reading repos, changing code, running tests, explaining errors, performing migrations, cleaning up technical debt. Work that used to be too annoying to touch is suddenly movable.

AI now feels like something you cannot avoid using, but once you use it, the bill hurts.

The real danger is not that it is expensive. The real danger is that the more useful it becomes, the more people use it; the more people use it, the less the bill looks like a tool expense and the more it looks like a tax. That is the unfinished part of the previous post, The Wintel Era Is Over.

If the PC really is entering a new era, the next correct investment direction is not another AI app, not another laptop with an AI PC sticker, and not another fight over who has higher TOPS. There is only one question worth watching: who can make high-frequency intelligent work cheaper, stabler, and more controllable after Agentic Coding becomes a necessity?

This Quarter Will Force The Question

Agentic Coding is still in the excitement phase. People are seeing that it can do real work. By the end of this quarter, many teams will face a different question: did it actually make delivery faster, or did it simply move labor cost into token cost?

This does not mean Agentic Coding lacks value. It means the opposite. Only genuinely valuable tools expose cost problems this quickly. Nobody uses useless tools every day. Useful tools enter daily workflow; once they do, they are no longer demos, POCs, or innovation budget. They become infrastructure.

The scariest thing about infrastructure is not that it is expensive. It is that every use is uncontrolled. Today, many Agents have an ugly cost structure: the expensive part is not generating a few lines of code. Before that, the Agent reads a dozen files, scans half a repo, asks the model repeatedly, retries after failures, and feeds test logs back into context.

Human engineers also explore and take wrong turns. The difference is that human exploration cost is packaged into salary, while Agent exploration cost shows up line by line in the token bill. So the question is not "should we use AI?" Teams cannot avoid it. The question is: can it become cheap enough to use all the time?

Do Not Read AI PCs Through TOPS

Most AI PC messaging is still stuck in hardware language: how many TOPS, how much NPU, which benchmark. These numbers are not useless, but they are not the language enterprises actually care about. Enterprises care about more specific questions:

  • Can a PR review burn half as many tokens?
  • Can a code migration understand the repo locally before it calls the cloud?
  • Can a failed test log avoid going to the cloud in full every time?
  • Can an Agent task use a local small model to judge difficulty before calling a frontier model?

If AI PCs work, they are not selling "smarter computers." They are selling cheaper intelligent workflows. This is why Wintel was the answer in the previous PC era, but may not be the answer in this one.

The old PC question was: can this machine run Windows software smoothly? The next PC question is: can this machine run enough local intelligence at lower cost? Those are entirely different questions. The first one is about CPU, operating system, and application ecosystem. The second one is about local runtime, model routing, context caching, memory bandwidth, GPU/NPU scheduling, enterprise policy, and developer experience.

Anyone still talking only about TOPS has not entered the real problem.

First: The Local Intelligence Routing Layer

The next important investment direction is the local model router. Not every app deciding which model to use for each request. Apps are bad at this, because an app usually does not know what hardware exists on each machine, what the battery state is, which local models are available, what enterprise policy allows to leave the device, or whether a task is worth going to the cloud.

This should become a capability shared by the OS, IDE, enterprise platform, and model runtime. A reasonable chain looks like this: simple tasks go to local small models, private context goes to local RAG or enterprise private models, routine tasks go to cheaper models, critical reasoning goes to cloud frontier models, and sensitive tasks are forbidden from leaving the device or enterprise boundary.

That is why Microsoft's Foundry Local matters. It is not just "run a model on your machine for fun." It puts a local model catalog, SDK, automatic hardware acceleration, and an OpenAI-compatible API into the application development path.

Azure AI Foundry model router points in the same direction: the platform routes according to modes such as quality, cost, and balanced. Today this mostly happens among cloud models, but the logic will eventually move across device, private, and cloud.

The real opportunity is not "we have a model list too." It is who can turn local, private, and cloud models into a governable cost-routing system.

Second: Make Repo Context Thin

The expensive part of Agentic Coding is not writing code. It is understanding code. Writing one line is cheap; finding the right place to change is expensive. Generating a diff is cheap; knowing whether the diff will break something is expensive.

So the investment opportunity in Agentic Coding is not another chat wrapper. It is the context layer: local code index, repo map, symbol graph, AST and call graph, mapping test failures to source files, log compression, tool result cache, conversation summary, and context deduplication, ranking, and pruning.

These sound unsexy, but they are the cost foundation of Agentic Coding. The repo naturally lives on the PC. IDE state lives on the PC. Terminal output lives on the PC. Local build results live on the PC. Uncommitted diffs live on the PC. If all of that is shoved into a cloud model every time so the model can understand it from scratch, the enterprise is paying tax repeatedly.

A good local context layer should turn 50k tokens of messy context into 15k tokens of useful context before the large model is called. That is not prompt optimization. It is a change in cost structure. Whoever helps Agents start from less zero directly reduces token consumption.

Third: Turn Repeated Inference Into An Asset

A large share of AI cost is repeated inference. The same repo summary, the same system prompt, the same kind of test failure, the same migration pattern, the same API document, the same enterprise policy. If each one is uploaded, understood, and paid for again, the enterprise is paying tax on repeated work.

So cache becomes important. Not as a small browser-cache style optimization, but as a foundation asset for Agent workflows. Prompt cache, semantic cache, embedding cache, tool result cache, KV cache, and failure pattern cache all move into the infrastructure layer.

AWS Bedrock's prompt caching states the point directly: caching long and repeated contexts can reduce latency and input token cost. But that is only the beginning. The valuable cache will happen at the local and workflow layers, because the most stable, reusable, privacy-sensitive context usually lives on the user's device and inside the enterprise environment.

If an engineer asks an Agent to inspect the same repo every day, why should it start from zero every time? If a team fixes the same kind of test failure every day, why should it explain the pattern again? If a company uses the same coding standards every day, why should they be pushed into the prompt repeatedly? For Agentic Coding to move from "useful but painful" to "useful and controllable," cache is unavoidable.

Fourth: High-Frequency Low-Value Tasks Must Leave The Cloud

This is easy to misunderstand. I am not saying all AI should run locally. In the short to medium term, local models do not need to beat Claude, GPT, or Gemini. They only need to absorb enough high-frequency, low- to mid-complexity tasks.

That includes intent detection, task classification, log summarization, simple code edits, local embeddings, document retrieval, sensitive-content preprocessing, and initial screening before Agent routing. These tasks do not always require the strongest model, but they happen constantly. If all of them go to the cloud, the bill gets ugly.

That is the real enterprise value of AI PCs. They are not replacing frontier models. They are reducing calls that should never have gone to the cloud. In the past, buying a PC meant buying a terminal for accessing cloud services. Next, buying an AI PC should mean buying a local intelligence node that continuously reduces cloud token spend.

If this becomes true, hardware procurement logic changes. 32 GB is no longer just "Chrome feels smoother." 64 GB is no longer just "developers feel better." Memory bandwidth, unified memory, local SSD cache, and GPU/NPU scheduling stop being only specs. They become part of token efficiency.

The question is not whether x86 or Arm has the better religion. It is who can complete the same Agent workflow with lower power, lower latency, and fewer cloud calls.

Fifth: Agents Need A Cost Brake

The biggest problem with Agents is not only that they make mistakes. It is that they can make mistakes very diligently. A normal LLM call is one input and one output, so cost is at least somewhat estimable. Agents plan, read files, call tools, fail, retry, reflect, and call tools again. Without boundaries, they can turn a simple task into an expensive trip.

A real Agent platform cannot only answer "can the task be completed?" It also has to answer how much we are willing to spend, how many steps it can take, what happens when it exceeds the token budget, whether it should downgrade the model, whether it should switch to a local model, whether it should stop and ask a human, and whether it should reuse an existing cache.

This is not a traditional FinOps dashboard. A dashboard only tells you the money has already burned. The real opportunity is putting cost control into the execution path. An Agent should know its budget before it acts, evaluate marginal return while it acts, and have a brake before it keeps burning money. Otherwise automation just becomes automatic taxation.

What I Would Watch

If the new era of PC is real, I would not only watch who sells more AI PCs. That is the result, not the cause. I would watch four categories.

First, local AI runtime and model routing layers. They unify CPU, GPU, NPU, local models, private models, and cloud models into one inference entry point that developers do not have to manage by hand.

Second, the context layer for Agentic Coding. They turn repo, IDE, terminal, test, log, and diff data into reusable local intelligence assets instead of repeatedly feeding them to cloud models.

Third, cache and cost-aware execution for Agent workflows. They do not merely display the bill. They reduce waste before each tool call, context assembly, model route, and retry.

Fourth, AI PC ecosystems that can translate hardware specs into economic outcomes. Not "how many TOPS does this machine have?" but "how many cloud tokens can this machine save the team?"

I would be cautious about the opposite: AI PCs without local runtime, TOPS without tokens per watt, Agent automation without cost boundaries, model capability without model routing, and FinOps dashboards that do not enter the execution chain. These may get attention, but they struggle to answer the real question.

The Point

So when AI PCs become the next boom, I would not first look at who sold more laptops, or whose TOPS number is higher. Those are surface outcomes. What matters is who owns the layer between the PC and the cloud model.

That layer includes local runtime, model router, context layer, workflow cache, private inference, and Agent execution control. These things do not sound like PCs, but they decide whether AI PCs can move from a marketing name into infrastructure enterprises are willing to buy.

Because enterprises will not ultimately pay for the words "AI PC." They will pay for one thing: can the same Agent workflow run cheaper, stabler, and more controllably?

If the answer is yes, AI PCs are a real boom. If the answer is no, they are just another hardware refresh narrative. So the opportunity is not in the abstract question of "who defines the PC." It is in something more specific: who can turn local compute, context, model routing, and execution cost into the default foundation for the next generation of AI workflows?

That company is selling the real picks and shovels of the AI PC era.