GLM 5.2 @ <$0.10 / M tokens - How Featherless & GLM 5.2 slash the Opus bill from 150k to 7.6k with dedicated AMD GPUs.

Featherless AI dedicated GLM 5.2 instances start at $7,592 per month on four AMD MI325X GPUs.

Our Q4 evaluation configuration reaches 143 tok/s on a single stream and 1,482 tok/s in aggregate. FP8 reaches 112 tok/s and 1,034 tok/s, respectively, with greater model precision.

At sustained, high-volume utilization, blended costs across input, cached input, and output can fall below $0.10 per million tokens.

For a major telco deploying Featherless in phases, early production results show monthly inference costs for the sustained workload in scope falling 95%, from approximately $150K to $7.6K.

Dedicated GLM 5.2 also provides a portable, open-weight alternative that reduces exposure to regulatory changes and geopolitical events.

The cost of always-on agent workloads

Continuously running agents are becoming common across development teams and production systems. These include OpenClaw-style agents, 24/7 coding agents, and customer-facing production agents.

Long context, repeated system prompts, repository data, tool definitions, and conversation history can generate enormous token volumes.

As an illustration, a pool of eight continuous coding agents managed by a development team of 5 to 50 could generate the following monthly workload:

This represents approximately 1.1 million requests per month, or one request every 2.5 seconds, with 86.9% of input tokens served from cache.

This is an illustrative workload. Token mix, cache rate, and request volume vary by use case.

Measuring agent throughput under real-world load

To model agent workloads, we built a benchmark from traces of our internal agent traffic. It cycles through prompts from 2K to 220K tokens and outputs from 1K to 25K tokens, replaying fixed prompt and response lengths over several hours.

Agent throughput and equivalent API prices. Typical output tok/s per concurrent-agent setting. Opus output range sourced from OpenRouter.

As concurrency increases, each stream slows, but the instance completes more work in aggregate. In our benchmark, 8 to 12 concurrent agents provided the best practical balance between per-stream speed and total throughput.

B300 delivers approximately 11.5% more throughput and leads at single-stream speed, but costs over three times as much per GPU-hour. Once a workload reaches two or more concurrent requests, scaling across MI325X instances becomes the more economical path while preserving competitive per-stream performance.

At two concurrent requests, two MI325X instances match B300 per-stream speed. From four to 12 requests, they deliver higher per-stream speeds while being 35% cheaper, costing $15,184 per month vs one B300 instance at $23,360.

Where dedicated instances make sense

Dedicated GLM 5.2 instances provide the greatest savings when agents generate a sustained base load.

When configured with on-demand spillover, teams can size dedicated capacity around recurring demand and route brief peaks to shared infrastructure. This keeps reserved capacity highly utilized, maximizing savings without giving up the flexibility to handle bursts.

Short, high-intensity spikes that occur only weekly, monthly, or less often are a weaker fit. In those cases, on-demand inference may be more economical because dedicated capacity would remain idle for most of the billing period.

Beyond cost: capacity, privacy, and control

Beyond lower costs, dedicated inference provides reserved capacity, zero data retention, and greater deployment control.

Reserved capacity removes noisy neighbors and mitigates unexpected bill shocks, making performance and monthly spending more predictable. Featherless processes requests in real time without storing prompts or completions, as described in our privacy and logging documentation.

We manage deployment, monitoring, and optimization, giving customers dedicated control without requiring an internal inference team. Open weights also reduce provider risk by making it easier to move between hosts, regions, or deployment arrangements.

That portability matters as we enter an era in which access to closed models can no longer be taken for granted.

The Fable moment and what it means for open models

On June 12, 2026, the US government ordered Anthropic to suspend access to Fable 5 and Mythos 5 for foreign nationals. Because Anthropic could not reliably enforce nationality restrictions across a global cloud product, it took both models offline for every customer, according to the company.

While the restriction was lifted 18 days later, the episode exposed a business continuity risk for customers outside the US. A compliant customer operating in an approved region could still lose access because of another country's policy decision.

The shutdown also intensified European concerns over technological sovereignty. The issue reached the UK Parliament, while Le Monde described it as a demonstration of American power over the sector.

This shifts the buying conversation. A closed API may remain the right primary provider for some, but after Fable, treating it as the only provider is harder to defend.

Featherless AI's core mission is to make AI accessible to everyone. Regardless of language, nation, or compute.

No one — not me, not another billionaire, nor a foreign government — should get to decide how and if you have access to AI. Open models are key in making this possible.

~ Eugene Cheah, CEO & Founder of Featherless AI

GLM 5.2: capability with an exit path

In a striking coincidence, Z.ai released GLM 5.2 during Fable's 18-day shutdown. The open-weight model had closed much of the gap with Opus on coding, tool-use, and long-horizon agent evaluations.

GLM 5.2 does not lead every benchmark or workload. It does not need to. It is good enough that choosing an open model no longer means accepting a generation-old capability gap.

That makes portability a practical option, not merely a fallback to a weaker model. Because GLM 5.2 can be served by compatible inference providers, customers can switch providers without changing their agent workflows or rewriting their codebase. They retain control over their model strategy instead of depending on a single API gatekeeper.

GLM 5.2 arrived at exactly the right moment, as companies and governments began asking the same question: how do we ensure continued access to AI?

For the technical folks: how we did it

As a GLM 5.2 launch partner, Featherless worked with Z.ai and AMD to optimize the model for MI325X. The results came from tuning the complete serving path, not simply loading the model onto GPUs.

DSpark speculative decoding drafts multiple tokens and verifies them with GLM 5.2, adjusting its work based on confidence to avoid wasted computation. Custom AMD kernels optimize execution for the model's sparse architecture, while shared KV caching avoids repeating prefill work across requests with common system prompts, tool definitions, and repository context.

The single-stream and concurrency results below use a standard 8K-token prefill and 1K-token output with DSpark on coding tasks. Typical speeds may be lower at longer context lengths.

While we are aware that better single-stream token/s speeds are achievable in 8-GPU setups, we view this tradeoff as marginal, and would recommend a 4-GPU setup as an entry point.

Single-stream speed and standard token throughput

Our Q4 configuration reaches 143 output tokens per second on a single stream. FP8 reaches 112 tokens per second with greater model precision. Both provide fast interactive output while retaining enough capacity for concurrent agent fleets.

Concurrency lowers the speed of each request but increases the useful output of the instance. At concurrency 16, Q4 delivers 92 tokens per second per stream and 1,482 tokens per second in aggregate. FP8 delivers 64 tokens per second per stream and 1,034 tokens per second in aggregate.

Teams can tune their setup for interactive speed, maximum fleet throughput, or a balance between them. Across our agent-trace benchmark, 8 to 12 concurrent requests provided the most practical balance between interactive speed and fleet throughput.

One more thing: Q4 (4-bit quantization)

The Q4 results use a new custom quantization scheme that we are evaluating with a small group of partners. Quantization is what allows us to reduce the memory and bandwidth cost of serving the model, but throughput is only useful if model quality holds up on real work.

Q4 is still undergoing precision and task evaluation, so it is not yet our default recommendation. Customers prioritizing greater model precision can use FP8 today, while teams interested in Q4 can work with us on a workload-specific evaluation.

Put your agent workload on a fixed-cost node

Dedicated GLM 5.2 is designed for sustained and recurring agent workloads. The relevant question is not only the price of one API call, but how much useful work the system completes each month, how it handles peaks, and whether capacity remains available when the business needs it.

Send us your typical input length, output length, concurrency, cache rate, and token speed target. We will model the workload against a dedicated GLM 5.2 configuration and show how a dedicated instance and spillover affect the economics.

Talk to Featherless about a dedicated GLM 5.2 node

~ Eugene, Featherless AI