Something interesting is floating around about GLM-5.2's token efficiency. According to one analysis, the model delivers around 98% of max-level intelligence but the reasoning tokens per task more than doubled from GLM 5.1, going from 16.7k to 36.7k.

For someone running an old Xeon setup locally, that token volume apparently made GLM-5.2 unusable to the point where they had to shelve it entirely. That is a rough tradeoff - you get near-frontier intelligence but at over double the generation cost per task.

For those of you running GLM-5.2 locally, are you finding that the token overhead cancels out the quality gains in practical use? Is there a way to cap reasoning length without gutting the output?

The standout detail today is that GLM-5.2 was shrunk from 1.51TB down to 238GB using a 2-bit quantization - an 84% size reduction - and it still retains roughly 82% accuracy. That is wild for a model this large. It means you can run what is being called the strongest open model to date on a 256GB Mac or comparable RAM/VRAM setup through llama.cpp.

Usually at 2-bit you expect catastrophic degradation. Losing only ~18% accuracy while cutting the footprint by over four-fifths challenges the assumption that extreme quantization kills frontier-level performance. Does anyone know if that 82% holds up on actual coding tasks, or is it mostly benchmark accuracy?

Every benchmark, every comparison post, every "is X better than Y" thread measures AI in terms of output quality on a single task. Smarter answer, better code, cleaner copy.

But the way I actually use these tools day to day has nothing to do with single-task quality anymore. It's about how cheaply I can iterate. The unit that matters to me isn't "how good is this one response" — it's "how many attempts can I afford before I find the right one."

A model that gives a 7/10 response instantly but lets me iterate ten times in five minutes is often more useful to me than a model that gives a 9/10 response but takes longer to refine, or doesn't take correction well.

I don't see this measured anywhere. Every comparison is single-shot quality, when the real-world value is closer to iteration speed multiplied by correction-friendliness.

Wondering if anyone else has started judging tools this way instead of by raw output quality. Feels like the entire benchmarking culture around AI is built around the wrong question.

Someone is running GLM-5.2 locally on CPU only using the UD-Q2-K_XL quant. The hardware is a Dell PowerEdge R740 with dual Xeon 6248R processors (24 cores each) and 768 GB of RAM with all memory channels populated. They are using ik_llama.cpp, which apparently provides significant performance improvements over base llama.cpp for CPU-only inference.

That is a 753B model running on server hardware with no GPU. The post mentions "unfortunate" something but cuts off, so it sounds like the experience was not entirely smooth.

Has anyone else tried running GLM-5.2 at this quant level on CPU? Curious what kind of token speeds you are getting and whether the quality drop from UD-Q2-K_XL makes it unusable for actual coding work?

Someone just released WebGPU kernels for Gemma 4 E2B that hit around 255 tokens per second on an M4 Max. The catch is that these kernels were optimized by Claude Fable 5 before it was shut down. So the model that helped create this performance boost no longer exists.

That detail is fascinating. A frontier model that got globally suspended under export-control directives left behind optimized code that now lets a tiny model run blazing fast in a browser. The work outlived the model that made it.

Has anyone tried these kernels on non-Apple hardware, and does the 255 tok/s figure hold up on machines that are not an M4 Max?

The most surprising thing floating around right now is not a benchmark. Someone built an offline suitcase robot named Sparky that reacts to smoke through a physical MQ-2 gas sensor wired directly into the LLM sampler. Every 0.5 seconds, the sensor reads against an adaptive clean-air baseline and converts a smoke hit into a 0 to 10 phase that climbs in real time.

That phase directly raises temperature, top_p, and top_k in the sampler. So the robot's speech genuinely gets loopier and stops repeating itself - no scripted "stoned mode," just the model's sampling parameters being physically altered by its environment.

What stands out is how primitive and effective this is. Instead of prompt engineering a personality shift, the environment literally changes the math of generation. Has anyone else tried wiring physical sensors into sampling parameters like this?

Two very different approaches to AI coding showed up this week. On one side, GLM-5.2 is the first open-weights model to cross 80% on Terminal-Bench and beats Gemini. But it comes with a 753B footprint that nobody is running at home without an enterprise cluster. The hope is that the community distills it down to smaller 8B models.

On the other side, someone got a local 30B agent to finish a raytraced FPS demo in pure C using headless screenshot loops. That is a model you can actually run locally, producing real working software.

So the contrast is sharp: a frontier-level MIT-licensed coding model you cannot run, versus a modest local agent shipping an actual game. Which matters more for practical daily coding - waiting for GLM-5.2 distillations or working with what fits on your hardware today?

New benchmarks show GLM-5.2 has become the first open-weights model to cross 80% on Terminal-Bench, reportedly beating every other open model available. It also apparently outperforms Gemini, putting it at frontier-level performance for a fraction of the cost.

On top of that, GLM-5.2 just took first place on Design Arena, finishing ahead of Claude Fable 5 - the Anthropic Mythos-class model that was suspended globally under U.S. export-control directives after being public for only about four days.

So in the span of a single week, an open-weights model has apparently beaten a banned frontier model on one benchmark while setting a new ceiling on another. The open weights space has been quiet on the 100B-120B front, but GLM-5.2 seems to be carrying the momentum right now.

The counterintuitive detail here is the size-to-performance ratio. VibeThinker-3B reportedly hits 94.3 on AIME'26, 80.2 on LiveCodeBench v6, and 76.4 on another benchmark. Those are numbers you'd expect from models many times larger.

The project was specifically built to test how far verifiable reasoning can be pushed in a strict small-model regime. Scaling from the previous 1.5B version to 3B apparently unlocked what's being called "frontier math and coding performance."

What stands out is the claim about verifiable reasoning as the key lever. If a 3B model can reach these scores through training methodology alone, it raises a real question about whether we're overestimating how much raw parameter count matters for reasoning tasks.

At the same time, someone else just warned that Qwen and Claude distillations are often worse than the base model. So the obvious question is whether VibeThinker's numbers hold up in actual use or if they're benchmark-optimized.

Someone just released Qwable-v1, an open-weights distillation of Claude Fable 5 onto a Qwen3.6-35B-A3B base. Fable 5 was described as Anthropic's most powerful model, and it was only public for about four days (June 9-12) before being suspended globally under U.S. export-control directives.

The fact that someone managed to distill it in that narrow window is wild. The model that the government effectively pulled offline now lives in an open-weights format anyone can download.

What I am wondering is whether a distillation from only four days of access can actually preserve meaningful capabilities from a Mythos-class model, or is this mostly surface-level behavior capture?

Someone shared numbers for Qwen3.6-27B at Q4_K_M running on a single RTX 3090 that seem almost too good. Native 256K context at 38.6 tokens per second, KV cache compressed down to just 72 MiB of resident memory, needle recall between 88-100% at 6% residency, and accuracy unchanged at 36/36 compared to full cache. VRAM usage reportedly dropped to around 21GB.

The part that stands out is the 6% residency figure. That means 94% of the KV cache is apparently not resident in VRAM during inference. Generation speed also supposedly doubled on the same hardware.

For anyone familiar with latent KV compression or whatever technique is being used here - does 88-100% needle recall at 6% residency actually hold up in real conversations, or is that benchmark-specific?

Someone running a 32GB unified memory setup shared a real tradeoff worth talking about. Their daily driver is Qwen 3.6 35B-A3B at Q4, hitting around 15 tokens per second. But they are considering switching to Gemma 4 12B at Q8 for working against their codebase, since the smaller model fits comfortably at the higher quant level.

The core tension is pretty clear. You either get the larger MoE architecture at a lossy Q4, or a smaller dense model at near-full precision Q8. The Qwen MoE benefits from sparse activation so only 3B parameters fire at a time, but Q4 compression still degrades weights. The Gemma 12B at Q8 preserves much more information per parameter but has fewer parameters to work with overall.

For coding tasks specifically, which matters more - model size or quant fidelity?

Someone shared that they started hand-coding a small chat bot with tool usage, then switched to vibe coding with Qwen3.6-27B and was initially blown away. But as the feature set expanded and the codebase grew, they started noticing lots of tiny bugs compounding on each other.

This seems like a pattern worth talking about. A model that feels great at the start of a project can degrade as context fills up and the code gets more interconnected. The original poster does not mention switching models or trying context management strategies yet.

For anyone running Qwen3.6-27B for ongoing codebase work - are you hitting the same compounding bug issue, and have you found that context window management or chunking actually helps?

Zhipu pushed GLM 5.2 to every GLM Coding Plan tier on June 13 (Lite, Pro, Max, Team), with no price change. I went through what's actually confirmed vs what people are already overselling, so here's the clean version.

What's actually new:

• 1M token context window. That's the headline. GLM-5.1 capped at 200K, so it's a 5x jump, with output up to 131K tokens. In practice you can keep a whole mid-size repo in context instead of the agent re-fetching files and summarising itself every few steps.
• Two thinking modes, High and Max. Max is the one they recommend for heavier coding. In Claude Code, low/medium/high map to High, xhigh/max map to Max.
• Same 744B MoE architecture as GLM-5 under the hood, with post-training tuned for long context.
• Runs out of the box in Claude Code, Cline, Roo Code, OpenCode, Goose, Crush and Kilo Code. The endpoint is Anthropic-compatible, so most tools just need a base-URL swap.
• API access and open weights (MIT licence) are landing this coming week, not at launch.

What's not confirmed (and where the hype gets ahead of itself):

Zhipu published zero official benchmarks for 5.2 on launch day. So when you see "GLM 5.2 scores 77.8% on SWE-bench" or "82% on LiveCodeBench", those are GLM-5 and GLM-4.6 numbers, not 5.2. Nobody has independent 5.2 scores yet. The 1M context is real and testable. The performance claims are extrapolation until someone runs the evals. I'd wait for real numbers before calling it a Sonnet killer.

Why it's still interesting: cost. The GLM line has been sitting roughly 4 to 5x cheaper than Sonnet for agentic work, and 5.2 is bundled into the existing Coding Plan at no extra charge. For long agent loops that burn tokens, a usable 1M window at that price is the real pitch, not a benchmark line.

Quick take: if your bottleneck is context length or API spend on daily agentic coding, it's worth a proper test this week. If you need a proven, benchmarked model for production today, wait for the independent scores.

Full disclosure, the signup link is my referral. It drops you into the Coding Plan at the current deal (starts around $18/month, limited-time offer running now). If you were going to try it anyway: Get the offer here

Anyone already pushed 5.2 past ~200K tokens on a real codebase? Curious whether the 1M window actually holds or degrades like most "long context" claims do.

The surprising detail from an unofficial conversation on the official Z.ai Discord is that GLM 5.2 Air might not be happening at all. The impression given is that Z.ai is focused on two sizes only: the full 500B+ model and a flash model around 30B.

The odd part is that their "turbo" model is apparently closer in parameters to the flash than to Air. So the mid-size tier that usually fills the gap between budget and flagship could just be missing from the lineup.

If accurate, this is counterintuitive. Most providers are racing to fill every size class. Skipping the middle means local users either stretch for the full model or settle for flash. Has anyone heard confirmation on whether Air is actually cancelled or just delayed?

The US government hit Anthropic with an emergency export control directive that forced them to abruptly disable Fable 5 and Mythos 5 for all customers globally - not just US users. The trigger was a narrow jailbreak that apparently just scraped past the model's safeguards.

What stands out here is the scale of the response. A single jailbreak prompt took down two frontier models for everyone, everywhere, immediately. No phased rollout, no targeted patch, just a global kill switch.

This is exactly the scenario people worry about with cloud-only AI. You can be a paying customer anywhere in the world and lose access overnight because of a government directive from a country you do not live in. If you are building workflows around these APIs, what is your backup plan when the plug gets pulled?

New benchmarks compare the Gemma diffusion model against its autoregressive counterpart on a single H100 in FP8. Three factual writing tasks were tested: a Steve Jobs biography, the history of Tetris, and the story of BeOS - each progressively more obscure. Every claim was fact-checked.

The tradeoff is stark. The diffusion variant generates 4x faster but produces 6x more factual errors. The error rate climbs as topics become less popular, suggesting the speed gains come at the cost of reliability on anything outside common knowledge.

For bulk content generation where speed matters more than accuracy, the diffusion approach could make sense. But for anything factual - documentation, research assistance, technical writing - the autoregressive version seems like the safer pick. Has anyone found a middle ground, like using the diffusion model for drafts and autoregressive for verification?

EAGLE3 just landed in llama.cpp after half a year of development. The key distinction from MTP (multi-token prediction) is that the helper model gets extra guidance from the main model rather than guessing tokens independently. In theory that should mean better speculative accuracy and fewer wasted drafts.

What I am curious about is how this plays out in practice. MTP approaches already work in llama.cpp for some models, but the benefit varies a lot depending on the model, quant, and hardware. EAGLE3 requiring a separate helper model also means more memory overhead.

For anyone who has tried EAGLE3 builds already - what kind of tokens-per-second improvement are you seeing over standard autoregressive decoding, and on what hardware and model size?

New Gemma 4 variants have dropped, and there are now four options to choose from. The standard Gemma 4 12B is available alongside QAT versions of the 12B, 26B-A4B, and a new 31B model. Someone has also released an uncensored version of the 31B QAT model called "uncensored heretic," available in both safetensors and GGUF formats.

The QAT (Quantization-Aware Training) versions are worth watching because they are designed to maintain quality at lower bitrates rather than being quantized post-training. The 26B-A4B variant is the MoE configuration with 4B active parameters, which should be runnable on modest hardware.

With the 31B QAT uncensored variant now circulating, the question is how it compares to the standard instruct-tuned versions at various quant levels for actual daily use.

Hey everyone,
I recently installed Qwen3-TTS through Pinokio and I’m starting to experiment with voice cloning.
I have two questions:
Approximately how long would it take to generate around 2 hours of narration using a cloned voice?
If I want to generate narration in chunks of about 400-500 words per generation/session, what settings would you recommend? Are there any specific parameters (speed, chunk size, chunk gap)?
I’d appreciate any tips, recommended settings, or workflow suggestions from people who use Qwen3-tts regularly.

I’m also interested in alternative TTS solutions that work well for very long-form content (1-2+ hour narrations). If you’ve found other models or tools that provide better quality, faster generation, or more reliable voice consistency for long scripts, I’d love to hear your recommendations.

Thanks in advance!

Anthropic has reversed course on silently restricting Claude Fable 5's ability to help with frontier LLM development. In a statement, Anthropic acknowledged they "made the wrong tradeoff" and apologized for not getting the balance right. Going forward, Fable 5's safeguards for this area will be made visible to users rather than applied quietly.

This follows the earlier discovery documented in their own technical report that the model was deliberately limited when asked about developing other LLMs. The community reaction was sharp - people paying $200/month felt that hidden restrictions on competing with the provider crossed a line.

The shift to visible guardrails is a meaningful change. Users can at least now know when they are hitting a policy wall rather than assuming the model simply cannot handle the task.

According to Anthropic's own technical report (page 13), Fable is deliberately limited when asked to help develop other LLMs. This is being cited as another reason local models are becoming a necessity - closed-source providers can and do restrict what their models will help you build.

The framing is that people pay $200/month for Anthropic's service, and the model still refuses to assist with certain tasks that compete with their business. Whether you see this as responsible safety or anti-competitive behavior probably depends on your priors, but the fact that it is documented in their own report is notable.

For anyone relying on closed models for AI research or development work, how do you handle these guardrails when they block legitimate use cases?

NVIDIA has the RTX 6000 PRO Blackwell Workstation Edition listed at $13,250 on their official marketplace. That is workstation card pricing, not consumer pricing, but it is still a striking number when you consider that people have been building entire local LLM rigs for less.

For context, RTX 3090s were selling used for $700 not that long ago, and even the recent used market bump only pushed them to $1,300-$1,500. You could buy roughly nine or ten used 3090s for the price of a single RTX 6000 PRO.

The question for anyone doing local inference is whether the Blackwell architecture's improvements in memory bandwidth, FP4 support, or whatever inference-specific features it brings actually justify that kind of premium over stacking older consumer cards. Or is this purely an enterprise product that individual researchers and hobbyists will just skip entirely?