The race to make AI inference cheaper is pushing chip design beyond general-purpose accelerators. We’re now moving toward silicon that is tailored to individual models. And Google’s reported “Frozen v2” project suggests the Gemini AI model is part of the movement.

First reported by The Information, the unannounced chip would reportedly hardwire parts of Gemini’s architecture while leaving its weights updatable. That compromise could give Google much of the efficiency of model-specific silicon without making the hardware obsolete every time Gemini changes.

A spokesperson for Google tells The New Stack, “Our teams are constantly researching and experimenting with new innovations to deliver maximum performance and efficiency for our users and customers.”

A spokesperson for Google tells The New Stack, “Our teams are constantly researching and experimenting with new innovations to deliver maximum performance and efficiency for our users and customers. While not every project moves into production, this rigorous exploration is central to our full stack approach. By co-designing our hardware and software from the ground up, we ensure our systems are integrated and highly optimized for real-world workloads.”

According to the reporting, Google hopes the chip will help relieve the AI compute crunch that’s made it harder for cloud providers to keep up with demand, while also making Gemini much cheaper and more efficient to serve. Internal projections reportedly estimate the design could deliver six to ten times more tokens per watt than Google’s current generation of AI chips.

If the project moves forward, it would represent a different approach to AI infrastructure because Google would be building hardware specifically for Gemini. For developers, that’s an early indication that future AI systems may be designed with much tighter integration between the model and the hardware beneath it. 

Specialized silicon replaces flexibility

Currently, the vast majority of AI inferences run on Nvidia GPUs or Google’s own Tensor Processing Units (TPUs). Because these chips are intended to accommodate a wide variety of AI models, they carry a high degree of processing load.

There’s precedent for this kind of shift. Bitcoin mining followed a similar path, starting with CPUs, then GPUs, before ultimately settling on ASICs. AI inference may be headed in the same direction. Training still benefits from the flexibility of GPUs, but once a model reaches production, the priority shifts to serving as many requests as possible while using less power. 

Training still benefits from the flexibility of GPUs, but once a model reaches production, the priority shifts to serving as many requests as possible while using less power.

Competitors hardwire their own

Google isn’t the only company looking beyond general-purpose GPUs for AI inference. As inference becomes a larger share of AI workloads, more companies are experimenting with specialized hardware designed to improve performance while using less power. Even Nvidia, whose GPUs dominate the AI market, has invested heavily in inference, striking a reported $20 billion deal with Groq last year to license the startup’s technology.

Among the more ambitious efforts is Canadian startup Taalas. The company has demonstrated a chip with an entire 8-billion-parameter Llama model embedded directly into the silicon. By keeping the model on the chip instead of constantly moving data back and forth from external memory, Taalas says it can dramatically speed up inference, claiming throughput of roughly 17,000 tokens per second. Meanwhile, other companies are optimizing the spatial distance between memory and compute to avoid hardware lock-in.

d-Matrix’s new Corsair platform uses an SRAM-based in-memory compute architecture rather than relying on standard high-bandwidth memory (HBM) packaging. Similarly, SambaNova is deploying custom dataflow technology with a three-tier memory architecture to maximize tokens per watt for advanced workflows.

Google’s Frozen v2 sits uniquely in this landscape — borrowing the hyper-efficiency of hardwired architectures like Taalas, but retaining just enough flexibility to remain viable across multiple product cycles.

Freezing architecture, not weights

The “Frozen” name reportedly comes from the idea of permanently etching part of Gemini’s design into the chip itself. According to The Information, Google’s engineers have spent years trying to find the right balance between efficiency and flexibility.

An earlier concept, led by Google DeepMind Chief Scientist Jeff Dean, reportedly would have embedded Gemini’s model weights directly into the silicon. That idea was eventually abandoned because it would have tied the hardware to a single version of the model, dramatically limiting its useful life as Gemini continued to evolve.

Frozen v2 reportedly takes a different approach. Rather than locking in the weights, the chip would hardwire parts of Gemini’s underlying design while still allowing the weights to be updated over time. That would let Google continue improving the model without needing to replace the hardware every time Gemini receives a new version.

Rather than locking in the weights, the chip would hardwire parts of Gemini’s underlying design while still allowing the weights to be updated over time.

Cheaper inference reaches developers

By moving some of Gemini’s execution into the chip itself, Google could reduce some of the overhead that comes with running models on more general-purpose hardware. That could translate into lower latency, especially for applications that depend on near real-time responses. 

Google’s reported goal of delivering six to ten times more tokens per watt is ultimately about efficiency, and those savings could eventually make their way to enterprise teams building on Gemini, through lower API costs or more available capacity. While Google hasn’t said how it would pass those gains along, reducing the cost of inference has become a priority across the industry.

The post Google just bet its inference future on a chip built for one model appeared first on The New Stack.

Over the past nine months, Amazon, Microsoft, and Google have each introduced or renamed an enterprise agent platform. And all three have converged on the same core architecture. Runtime, memory, tool gateway, identity, observability, and governance now appear in Amazon Bedrock AgentCore, Microsoft Foundry, and the Gemini Enterprise Agent Platform, albeit under slightly different names. Each vendor presents these components as the foundation for production agents. What was a fragmented collection of libraries just 18 months ago is becoming a distinct platform layer.

To see where that shift may lead, consider the evolution of platform as a service. Between 2011 and 2016, developers built applications from virtual machines, load balancers, message queues, secret stores, and monitoring agents — each with its own API and operational model. Cloud Foundry and Heroku unified those pieces around an application contract. Developers could think less about machines and more about applications. The agent ecosystem is approaching a similar inflection point, but it still lacks an equivalent contract — and no open-source project has stepped forward to define one.

The plumbing a production agent still needs

Imagine a platform team putting a customer support agent into production this quarter. They choose a model provider, then a framework, and finally a place to store session state and long-term memory. They add a tool gateway so the agent can reach the ticketing system. An identity layer follows, so the agent acts on behalf of the person who asked, and a sandbox keeps generated code somewhere safe. Evaluation and tracing are considered last, once someone asks how quality regressions will surface before customers find them.

Each of those choices looks small on its own. When combined, they decide which cloud the workload lives in. Session state resides in a single provider’s managed store. The traces are logged in that same provider’s telemetry service, and the agent’s identity is derived from its directory. Moving that agent a year later means rebuilding the whole assembly, which is where enterprises were before PaaS gave applications a portable shape.

What Cloud Foundry got right before it lost the market

Cloud Foundry reduced application deployment to a single command, and the platform took responsibility for everything after it. Buildpacks detected the language and produced a runnable artifact. Service brokers provisioned a database or a message broker and bound the credentials into the application environment. Routing, logging, autoscaling, and health checks arrived as platform behavior, not as a queue of tickets aimed at an operations team.

What mattered was the contract, not the implementation. An application declared what it needed and stayed agnostic of where it ran. Buildpacks began life at Heroku back in 2011. Pivotal and Heroku started the Cloud Native Buildpacks project in January 2018, and the CNCF accepted it that October. A PaaS idea outlived the platform that produced it.

Cloud Foundry never became the dominant platform. Kubernetes did, and the Cloud Foundry community eventually rebuilt its abstraction on top of Kubernetes through Korifi. The design principles traveled anyway, and enterprises running that platform in 2016 had portability that most agent teams cannot buy today.

The same primitives across three clouds

Let me dissect the three platforms because the similarities are conveniently hidden behind the branding.

AgentCore reached general availability in October 2025 with seven composable services, namely runtime, gateway, memory, browser, code interpreter, identity, and observability. The runtime offers eight-hour execution windows with complete session isolation. The gateway connects to existing MCP servers and turns APIs and Lambda functions into agent-compatible tools, while observability exports through OpenTelemetry into CloudWatch.

Microsoft renamed Azure AI Foundry to Microsoft Foundry effective January 1, 2026. Foundry Agent Service covers the same ground. Microsoft documents hosted agents running in a session-isolated managed runtime, with Entra Agent ID handling identity. Managed memory spans session, user, and procedural scopes, and tracing is built on OpenTelemetry.

Google retired the Vertex AI name at Cloud Next 2026 and folded the platform into Gemini Enterprise Agent Platform. What was Agent Engine became Deployments, and Memory Bank, Sessions, Agent Registry, Policies, and Gateways sit alongside it under an agent-first information architecture.

The convergence is rational behavior rather than a conspiracy, since infrastructure companies build vertically integrated platforms because integration is where the margin lives. The consequence lands on customers rather than on the vendors. Identity, telemetry, and deployment all terminate within a single provider, which makes the operational layer beneath the agent the part that resists moving. Recently, I analyzed the runtime aspect of this problem in a piece about Google’s Agent Substrate.

The contract an agent platform would inherit

Any agent platform can be tested by one question: what would a Cloud Foundry-style contract look like if it had been written for agents rather than for web applications? The mapping is close enough to be instructive and different enough to be interesting.

PaaS abstraction	Agent platform equivalent	Where portability breaks today
Application source	Agent code, instructions and evaluation suite	Each framework defines its own package shape
Buildpack	Framework detection and agent packaging	No shared build contract across SDKs
Backing service	Model, memory, retrieval or tool provider	Providers are wired into agent logic
Service binding	Authenticated attachment of tools and data	Credentials are issued by the host cloud
Router	Agent endpoint, MCP or A2A interface	The protocols exist but not the lifecycle
Logs and metrics	Traces, tool calls, cost and quality scores	GenAI conventions remain in development
Release promotion	Evaluate, version and progressively deploy	Evaluation couples to one vendor’s harness
Platform policy	Agent identity, permissions and approvals	Identity ties to the provider’s directory

Real deployments will mix these rows rather than adopt them cleanly, and no team needs the complete set from day one.

Package the agent as one deployable unit

The thing developers ship has to be versionable, testable, and movable as a single artifact. The code, the instructions, the tool dependencies, the memory contract, the permissions, and the evaluation suite all travel together, or none of them do. AWS gets close with its harness export path. One command turns a configured harness into Strands code, and AWS says the export preserves the model, prompt, tools, memory wiring, and container environment. Customers can easily move from configuration to code without an architecture rewrite, which is the right instinct pointed at a single cloud.

Bind capabilities rather than embed providers

The Twelve-Factor App taught developers to treat databases and caches as attached resources reached through configuration. Models, memory stores, retrieval engines, browsers and tool gateways deserve the same treatment. An agent that names its model provider inside application logic has already given up portability, whatever the platform brochure claims.

Make operations part of the abstraction

Rather than just enabling deployment, PaaS proved its value by offering built-in capabilities like routing, logging, autoscaling, and rollback. The questions that matter for agents look different, and they should be the ones enterprises must ask. Platform teams want to know whether the agent completed the task and whether it chose the right tools. They also want to know whether it exceeded its authority, what the run cost was, and whether quality regressed after a model update.

How agents differ from applications

Agents are not web applications with a model attached, and a platform built on that assumption will fail in production. Three differences carry most of the weight here. Agent behavior is probabilistic, so two identical inputs can produce different tool calls. Agents act with delegated user authority, which turns a permissions bug into a real-world side effect rather than an error page. An agent’s dependencies can also change its behavior without any code deployment. A model update or a revised tool description alters what the agent decides to do.

The Twelve-Factor rule that processes should be stateless does not survive that. An agent platform needs disposable execution workers alongside durable, inspectable, and portable agent state. LangGraph already demonstrates the combination in open source, with checkpointing at every step, first-class human interrupts, and execution that resumes after a crash. The control plane around it is part of the commercial LangSmith product, covering deployment, evaluation, and observability. The fragmentation appears within a single project.

What the open protocols leave out

Most of the primitives a neutral platform would need already exist. The Model Context Protocol standardizes how agents access tools and data. A2A covers discovery and communication between independent agents. OpenTelemetry is defining GenAI conventions for agent spans, tool calls, and token usage, though most of those attributes remain marked as in development. OCI images stay available as the packaging escape hatch for anything a managed runtime cannot host.

The vendors have already conceded that a neutral layer matters. The Linux Foundation announced the Agentic AI Foundation in December 2025. Its founding projects were MCP from Anthropic, goose from Block, and AGENTS.md from OpenAI, and AWS, Google, and Microsoft joined as platinum members. Google also moved A2A into the Linux Foundation.

Protocols are not the same thing as a lifecycle platform. A foundation that governs how agents talk to tools says nothing about versioning an agent. It says nothing about promoting that agent through environments, or rolling it back when an evaluation regresses. Enterprises running diligence on agent platforms can work through three plain questions. The first is governance: whether the project is controlled by a neutral foundation or by the vendor selling the managed version. The second is packaging, where the same agent artifact should run on two different clouds without a rewrite. The third is state, where memory has to live somewhere the enterprise can export from. No open project answers all three today.

Where is this headed?

Kubernetes defined pods, deployments, and services, and those abstractions influenced how an entire industry thinks about running software. The equivalent agent abstractions have not been fixed yet. Whoever ends up owning the agent control plane will not merely own deployment. That owner defines what an agent is, which components it contains, and what a platform team is permitted to swap out.

In summary, hyperscalers are building robust platforms that effectively address operational questions. They also answer them inside a single cloud. If a neutral project assembles the same lifecycle atop the protocols already in place at the Linux Foundation, enterprises will regain the negotiating position that buildpacks and service brokers once gave them. An open, cloud-agnostic agent platform would benefit vendors as much as buyers, because a stable contract is what allowed the cloud-native ecosystem to grow beyond any single provider.

The post Amazon, Microsoft, and Google are converging on the same enterprise agent architecture appeared first on The New Stack.

After weeks of extending temporary access while bringing additional inference capacity online, Anthropic has finalized Claude Fable 5 subscriptions.

In a Friday announcement on X, the company said Claude Fable 5 will become a permanent part of Max and Team Premium subscriptions beginning Monday, July 20, at 50% of each plan’s usage limits. Pro and Team Standard users will transition to using the model through usage credits and will receive a one-time $100 credit.

An Anthropic spokesperson tells The New Stack, “Friday’s announcement means that Fable 5 at 50% of usage limits is now a standard, permanent part of Max and Team Premium plans.”

The changes bring an end to weeks of temporary extensions that left subscribers wondering whether Fable 5 would remain part of their subscription. Rather than introducing a new usage policy, Anthropic is making permanent the same access level subscribers have had since Fable 5 was redeployed on July 1.

Capacity drove the timeline

The move gives a glimpse into the economics of serving frontier AI models. Although Anthropic repeatedly extended temporary access over the past several weeks, the company says making Fable 5 a permanent part of Max and Team Premium subscriptions was always the goal.

An Anthropic spokesperson tells The New Stack, “Friday’s announcement means that Fable 5 at 50% of usage limits is now a standard, permanent part of Max and Team Premium plans. This was always our intention with Fable access (see more in our original launch blog on June 9). We planned to expand Fable 5 access in stages as we brought additional inference capacity online, with the ultimate goal of making it a standard part of subscription plans.”

Fable 5 usage limits explained

Anthropic has not explained exactly how it calculates the 50% limit or how many prompts that will translate to in practice. Developers using Fable 5 for heavy workflows are likely to reach the limit sooner than lighter users.

The company has said demand for Claude Fable 5 was difficult to predict and that broader access depended on bringing more capacity online. Reuters reported earlier this week that the company is in talks with Meta over a potential compute lease worth up to $10 billion, which could give Anthropic access to Meta’s AI infrastructure for as long as two years. 

Meta compute deal looms

Thariq Shihipar, an Anthropic Developer Relations team member, posted on X, crediting the company’s employees with getting the necessary capacity online.

“This was due to a heroic effort by many people at Anthropic working sometimes literally around the clock,” Shihipar wrote on X. “It was not at all clear that we’d be able to do this in time, and so proud of everyone who made it happen. Enjoy Fable.”

“This was due to a heroic effort by many people at Anthropic working sometimes literally around the clock. It was not at all clear that we’d be able to do this in time, and so proud of everyone who made it happen. Enjoy Fable.”

Claude expands into India

The revised policy reflects broader changes across the AI industry. Frontier models are becoming expensive, which means AI companies are forced to balance compute costs with subscription pricing. OpenAI recently introduced GPT-5.6 Sol, while Chinese AI companies have released increasingly capable open-weight models, including Moonshot AI’s Kimi K3. Although Anthropic has not linked today’s pricing decision to competitive pressure, both model capability and the cost of serving those models have become key competitive factors.

…both model capability and the cost of serving those models have become key competitive factors.

Alongside the subscription changes, Anthropic is also formalizing its presence in one of its fastest-growing markets by introducing local pricing for Claude in India.

Indian customers can now pay for Claude in rupees instead of U.S. dollars, with GST included in the listed prices. That removes foreign currency conversions and other cross-border payment costs that previously came with subscribing. Claude Pro is now priced at Rs. 2,000 per month with annual billing or Rs. 2,399 on a month-to-month plan (previously $20 USD per month).

Industry reports have identified India as Claude’s second-largest user base after the United States. Together, the announcements show Anthropic expanding Claude in two ways: by making subscriptions easier to purchase in a major growth market while locking in an access policy determined by the compute required to serve Fable 5.

The post Anthropic employees worked “literally around the clock” to keep Fable 5 from disappearing appeared first on The New Stack.