The LPU Era

Why coding agents may eventually ship as specialized hardware, a Language Processing Unit, instead of living entirely behind an API.

For the last several years, the answer to almost every AI hardware question has been some variation of: buy more GPUs or TPUs.

GPUs are remarkably flexible. The same accelerator can train a model, fine-tune another one, serve inference for a third, render graphics, run simulations, or be reassigned to whatever new architecture researchers invent next year. Google's TPUs are designed more specifically for machine learning and carry the same advantages as GPUs for large AI data centers.

That flexibility is enormously valuable when nobody knows what the best model architecture will look like twelve months from now. For the early LLM era, there wasn't a better investment than GPUs.

However, general-purpose hardware has to accommodate workloads it is not currently running. Models have to move enormous quantities of data between memory and compute. Chips need sophisticated memory systems, networking, scheduling, compilers, and software stacks capable of handling whatever engineers throw at them.

As AI costs grow and the technology matures, some companies are asking:

The Specialization Ladder

OpenAI's Jalapeño accelerator is an example of such a tradeoff. It is not a general-purpose training accelerator but rather an inference ASIC designed specifically around large language models.

OpenAI has demonstrated it across models at very different scales. The point is not to hard-wire one set of weights forever. The point is to throw away capabilities that do not matter for LLM inference and use the resulting silicon budget for the things that do.

Taalas takes the specialization argument much further. Instead of loading a model onto a programmable inference accelerator, Taalas physically realizes much of the model in silicon. Storage and computation are merged, and the hardware is designed around weights that are already known before the chip is manufactured.

Taalas demonstrated the technique with a Llama 3.1 8B ASIC. Taalas reports roughly 17,000 tokens per second per user, alongside claims of dramatically lower power consumption and lower system construction cost than conventional accelerator-based inference.

That is where the IT budgeting choices get interesting, and AMD knows it.

AMD Buys Taalas

In August 2026, AMD announced its acquisition of Taalas and its intent to integrate the technology into future system-level inference solutions. AMD is one of the few companies in the world with the manufacturing relationships, capital, enterprise distribution, software stack, and accelerator portfolio required to turn this kind of architecture from a proof of concept to a consumer card.

Just as AMD is partnering with Taalas, a market is forming for the exact type of chip that Taalas prototyped. Two markets, actually: IT departments growing concerned about their exploding budgets, and IT departments that care about data security.

AI Spending Pullback, Fall 2026

In October, The Information reported that Microsoft had projected spending at least $1 billion per year on Anthropic models for internal use, then cut that projection by more than a third and pushed employees toward Microsoft's own AI tools. Meta made a similar move: Claude Code usage reportedly fell from around 60,000 employees to roughly 30,000 as Meta shifted more work onto its internal models and tooling. In one recent 28-day period, Meta still spent more than $105 million on Claude Code alone.

At that scale, inference cost becomes an IT budget problem. Microsoft and Meta can respond by building their own models and infrastructure. Most companies cannot. Specialized local hardware offers another path: keep frontier models for difficult work, and move routine coding tasks onto much cheaper inference that the company owns.

Alex Karp and Alpha Theft

Cost is not the only concern. Palantir CEO Alex Karp has spent much of this year warning companies about what he calls the theft of their “alpha”: the proprietary data, workflows, and relationships between them that make a business valuable. His concern is not simply whether a frontier lab trains on customer prompts. It is how much a model provider can learn about a company by becoming deeply embedded in how that company operates.

Figma provides a useful example. Anthropic CPO Mike Krieger joined Figma's board in 2025 while the companies were working closely together. In April 2026, Krieger resigned shortly before Anthropic launched design tooling that Figma believed competed more directly with its own product than Anthropic had previously indicated. There is no evidence that Anthropic stole Figma's data or trained on its intellectual property, but Figma had still spent considerable time working closely with a company that subsequently became a more direct competitor.

An LPU removes much of that relationship. A company can buy the model and harness while keeping its code, data, and day-to-day workflows inside its own infrastructure. For some companies that is a compliance requirement; for others, it may simply be preferable to teaching an outside AI company how their business works.

What About Frontier Capabilities?

Some tasks have been “saturated” or “solved” by LLMs for a while now. For example, many of the tasks that go into building a CRUD app, dealing with Jira, querying a database, parsing Excel files, or making a React website have an incredible amount of training data and verifiable outcomes for RL training. As a result, LLMs, even small ones, tend to perform extremely well on these.

Unfortunately for frontier labs, most white collar tasks (not jobs) fall into this bucket of small model capable tasks. What's more, the high quality decision making that occurs between these tasks is still largely a weak point for LLMs, blocking the frontier models from automating jobs instead of the tasks within a job.

But there is progress. It's more like horizontal progress. Claude Opus 4.5 and 5.5 are about equal in terms of their ability to query a database or parse an Excel file, but 5.5 is able to do 3D modeling, music, animations, game development, and frontier mathematics. If your job doesn't involve those, or rarely involves them, you're better off using a smaller, faster model that's been fine-tuned for white collar work.

Won't It Become Outdated Over Time?

It's true that a Taalas-style ASIC will be frozen, unable to be updated with new knowledge. However, that doesn't matter for many tasks and domains.

Consider modern Java, C, Python 3, SQL, and the other staples of corporate IT: how often do these dramatically change in such a way that you need to perform a migration or refactor of your codebase? For C, never. For Java, hopefully you never have to deal with a migration like the one from Java 7. The point is this: they're very stable. Code you write today will work next year, and probably for the next decade.

This applies to AI agent written code in these languages. If an agent is proficient in writing ETL scripts in Python, then it doesn't need to know who wins the next presidential election or any other current event. It just needs to help write the ETL scripts, and its frozen weights are perfect for that.

The Cursor LPU

Cursor, recently acquired by SpaceX for $60 billion, produces a model series called Composer. The Composer models have been fine-tunes of open-weight models, such as Kimi K2.5. Their models have typically been smaller, faster, and hyper focused on agentic coding. These are the perfect candidates for a Taalas-style ASIC.

A company like Cursor could partner with AMD to offer an on-prem appliance built around a mature coding model optimized for everyday software work. SQL, migrations, tests, repository edits, shell commands, Python scripts, ordinary backend development, and other common tasks run on hardware whose entire purpose is to serve that model cheaply and quickly.

The pitch would be fairly straightforward: your costs are predictable and low, your data never leaves your data boundary, and the ASIC operates at speeds that are many times faster than even the “fast modes” of frontier labs.

Pairing an ASIC with the Frontier

Even in business environments where frontier model usage is encouraged, ASIC cards would still be valuable. With Opencode, you can configure agent and subagent pairings. For example, I can pair GLM 5.3 running on high reasoning as an orchestrator for dozens of Qwen3.8-27B subagents. You could use the frontier agent for planning and orchestrating execution of agents running on the ASIC chip to have the intelligence of the frontier but the speed and cost of the ASIC chip.

There are many examples of this workflow. Many engineers use Claude Fable for planning and hand the plan to Sonnet for execution. Some organizations have built tooling specifically for this, like Cursor's swarms, that dramatically reduce cost while maintaining performance by blending a frontier model with their small, fast Composer model.

Right Tool for Many Jobs

For tasks in languages and software that barely change, and that can be solved by smaller, specialized models, an LPU is the right choice. It can provide LLM usage that has a predictable, low cost while being fast and secure. I, for one, can't wait to see what AMD and Taalas come up with.