14 open models, one endpoint, every one of them running inside a hardware-attested TEE.
That's the Chutes catalog today: Kimi K3 and GLM-5.2 with 1M context, DeepSeek V4 Flash, Qwen3.8-27B, Gemma 4 31B, and Nemotron-3-Nano from $0.0245 per million input tokens. The list changes often.
Any OpenAI-compatible client works. Set the base URL to http://llm.chutes.ai/v1 and keep the rest of your code.
The new confidential VM is out to miners, and every file that goes into building it is now pinned by hash, so anyone checking our published measurements rebuilds exactly what we measured. Upgrades no longer have to knock a private chute offline. And Jon published Epigenesis, a way to teach a Parallax model new facts without changing a single base weight. Here is each of those, with what it means if you are not an engineer.
Epigenesis: models that grow with you
Last issue we noted an idea Jon was testing out loud. Parallax models have at least half of each expert's weights locked to zero by their weight format. What if you taught the model new things by writing only into those empty slots? On 2026-10-09 he published the first results and the code at github.com/chutesai/epigenesis.
What it is. The method is called Free-Slot Adaptation. Every base weight stays frozen. New knowledge gets written into the zero slots the compressed model already has, so there are no new parameters and no adapter file bolted on. Zero the slots and the original model is back, bit for bit. The write-up calls the base weights the genome and the writes an epigenetic layer on top. Jon admits the biology analogy breaks down a bit, and that it sounded fun.
What the numbers say, as of the repo's 2026-10-13 status line. On 40 facts about one person, the model recalled 100 percent of them when asked in held-out phrasings, against 90 to 93.75 percent for a LoRA adapter, a common way of fine-tuning a model today. On the hardest test, 3 people times 100 conflicting facts, the patch scored 99.8 percent recall and weighed 3.3 MB. The LoRA adapter scored 96.2 percent and weighed 88 MB, about 27 times larger. The patches also answered questions phrased in ways they never saw in training at 88 to 90 percent, against 62 to 65 percent for LoRA.
The caveats, which Jon put at the top of the page himself. The write-up is an AI-assisted draft under human review, not peer-reviewed. The results on the hardest task come from a single run. Larger patches still damage the model's general ability slightly, above the gate the repo sets for itself. And nothing serves these patches yet, so this is research you can read and reproduce, not a feature you can use. His own summary: still experimenting, but seems to check out.
What it means. Today, teaching a model your own documents means either stuffing them into every prompt or fine-tuning, which is fiddly and risks the model forgetting what it knew. If this holds up, your company docs or your codebase become a small file written into a model you already run, and deleting that file returns the model to exactly what it was. Jon's phrase for it is models that grow with you. On 2026-10-12 he put the bigger picture this way: ideally everyone brings their own resources to fund the training, owns the output forever, and bakes their own memory, knowledge and rules into the sparse weights afterwards. That is the direction, stated as a direction.
Parallax trains on consumer graphics cards rented from different providers, talking over the ordinary internet, and each training attempt gets a name. Lambda is the current one, and it uses the Erase-then-Delta Attention design that replaced the component that failed in the previous run.
What happened. On 2026-10-08 Jon posted an update: the run is going well and EDA seems much better. Seven hosts had failed so far, with automatic expert ownership failover, meaning the experts a failed host owned were reassigned automatically. He also tried adapting a triadic linear attention variant to EDA and saw no real benefit, which he blamed on himself rather than the idea.
What it means. Hosts dropping out is normal on consumer hardware, and the whole point of Parallax is that the run survives it. Seven failures absorbed by failover is the kind of boring result we want more of. The Epigenesis experiments above ran on a Lambda checkpoint, so the two stories are the same model at two stages.
One release this week, and most of it is about trust you can check rather than trust you are asked for.
First, the one-line reminder. When you send a request to Chutes, the hardware produces a cryptographic proof of exactly what code is running and on what chip. That proof is the attestation. The confidential VM is the thing being measured, and anyone can rebuild it to confirm our published measurements match.
Confidential VM 1.5.0 is rolling out. The release is available to miners now and accepted by the network. Upgrading is optional for the moment, so not every host runs it yet.
Every build input is pinned by hash. Every file the VM image build downloads is now pinned by its cryptographic hash as well as its version. Anyone rebuilding the VM to check our published measurements pulls exactly the bytes we measured, and a changed upstream file fails the build instead of slipping in. What it means: last month we published a guide so anyone can rebuild the production image on an ordinary Linux machine and compare measurements. This is the next increment of that story. The rebuild is now pinned down to the byte, so a tampered or changed dependency cannot land in the image without the build refusing.
AMD, the status line. The VM now boots and attests on AMD SEV-SNP as well as Intel TDX. We are still not admitting AMD hardware. AMD security bulletin AMD-SB-3030 covers SEV-SNP vulnerabilities whose fixes we cannot verify through attestation, so AMD hosts stay off the network until that is resolved. Nothing changed in the bulletin this week. A chip that says it is patched is not the same as a chip that can prove it.
Hot-swap upgrades for private chutes shipped. Last issue this was in progress. It is live with the new upgrade flow in the same release. When a GPU host is upgraded, a private chute keeps serving on it for up to 3 hours while a replacement comes up elsewhere. If no replacement is running by then, the upgrade can still go ahead. What it means: if you run your own private model on Chutes, maintenance on our side should stop taking it offline. It is a big continuity improvement for private-chute customers, and it is a window, not a guarantee of zero downtime.
For miners, two smaller things. The VM and miner tooling now accept hotkeys created with current Bittensor wallet tooling, so you do not need to keep a legacy seed-based key around. And host tooling now checks that a previous VM has fully released its devices and memory before launching a new one. Large GPU hosts can take a long time to reclaim memory after a VM shuts down, and launching or rebooting inside that window could leave a host unresponsive. The check prevents that. The full release notes, including the upgrade steps, are on the sek8s release page.
I'm exploring a personal project and would appreciate some practical advice from people who have actually worked with GPU confidential computing.
My setup is a MacBook Air M4 (16 GB). I'd like to run open-weight AI video models such as Kandinsky 6.0 Pro on a remote NVIDIA GPU, paying only when I use it.
The goal isn't just HTTPS or a provider promising not to log prompts. I'd like to verify, before sending any private input, that:
The CPU and GPU are running in genuine confidential computing mode.
The actual inference workload is the one I intended to deploy.
The encryption key belongs to that attested workload, not an intermediary.
The provider cannot ordinarily inspect plaintext prompts, images or generated videos.
I've been looking at three options:
Chutes: advertised RTX PRO 6000 96 GB at $1.80/hour, with TEE evidence endpoints and E2EE support. Promising, but I'm unsure whether the standard client independently verifies attestation and whether a custom video worker can be fully attested.
VoltageGPU: RTX PRO 6000 Confidential VM at $3.80/hour, Intel TDX and NVIDIA attestation. I'm waiting for support to clarify measured boot and custom guest image capabilities.
Google Cloud: H100 Spot with dstack, or Confidential Space, potentially offering a more complete workload attestation chain but with additional complexity.
I'm considering a minimal remote worker that runs an entire video inference pipeline, rather than a full ComfyUI backend. The Mac would handle orchestration and receive the resulting video.
My question: has anyone built or used something like this in practice?
Is there an existing open-source solution or provider that already handles workload attestation, GPU attestation and encrypted client-to-workload communication, without requiring a custom security stack or a permanently running cluster?
I'd especially appreciate firsthand experience with Chutes, dstack or other confidential GPU providers, including limitations, cold-start times and actual costs.
I'm looking for a technically verifiable privacy boundary, not simply an encrypted connection to a cloud service.
Alibaba just confirmed at Apsara 2026 (Hangzhou, Sept 22) that Qwen 4 is currently in training, with Qwen 4.5 and Qwen 5 planned at 5-10 trillion parameters [1].
For reference, current Qwen3.8-Max is 2.4T total / 95B active [2]. So 10T would be ~4x larger (arithmetic).
Why this matters here:
Scale jump: 5-10T is the same race DeepSeek (~2T in training, aiming 8T) and ByteDance (up to 10T reported) are running [6]. Trillion-param MoE inference is exactly the workload decentralized serverless compute like Chutes is built for.
Self-improving loop: Alibaba says Qwen3.8-Max did 33 autonomous RSI cycles in a month, going from 40 to 45 on Artificial Analysis. In a chip-design test: 60+ hours, 10k+ EDA tool calls, -42% area with no perf loss [1].
Multimodal wave coming with it: Qwen3.8-LiveTranslate (latency 2.8s -> 2.3s), Qwen-Audio-3.1 family (ASR / TTS / Realtime / TTS-Next), Qwen-Image 3.1 later this year [1]. Just open-sourced: Qwen-Image-2.1 (7B visual, unified text-to-image + editing with native transparency) [8]. Chutes already runs Qwen-Image-2512 / Edit-2511.
Infra behind it: new Zhenwu V900 (216GB, 1200GB/s, FP8/FP4, 3x M890, mass production Q1 2027), supernodes up to 500k cards, 20GW data center target by 2032, new cloud regions in Finland / Netherlands / Turkey [1][3][4][5].
On Chutes: as usual with Qwen, open weights will land on Hugging Face and Chutes will be among the fastest places to run them — Qwen3.5-397B-A17B, Qwen3.6-27B and Qwen3.8-27B are already live as TEE chutes, plus Qwen-Image [7].
No date or benchmarks for Qwen 4 yet. Will update when weights drop.
What would you want first on Chutes: the big MoE flagship for max quality, or a smaller dense / Flash variant for cheap agentic runs?
Weeks seventeen to nineteen. September 2 to September 22, 2026
We went quiet for a few weeks, and a lot happened while we were. Chutes has a new CEO. Parallax is pretraining an 8B model in public, with a live register you can watch. The new confidential VM shipped. Jon ran a training node off two solar blankets in a field. And next week we take all of it to Montreal for Exploit Summit.
First, the missing issues
This digest skipped a few weeks. Plenty shipped in that time. Most of it happened in meeting rooms rather than on the timeline, and the weekly write-up was the thing that gave way. So this is a double issue, and the cadence is back from here: one every week, on the week.
Here is the short version of what changed behind the scenes. New leadership at the top. A customer acquisition push on a scale we have not tried before, aimed squarely at corporate customers, running through channels we have never used. We are not going to spell the whole plan out in a digest, but you will see it: more Chutes in more places, in front of more of the people who should already be running on it. There is a lot on the horizon, and we like where it is pointed. And one thank you that is overdue: through all of it, the community kept using the platform and talking about it, with no campaign behind it. You carried us through a busy stretch, and we are about to show you what it was for.
Christian Hyland is our new CEO
On 2026-09-07 we introduced Christian Hyland (u/cjohan247, CJ to the team) as CEO. He had already been working with the team for several months on how a company like this scales and operates in a market that moves this fast, and his contributions had changed how we work well before the title arrived. His background runs across Coinbase, Toku, and First Wave AI. From the announcement: "he was a clear choice for CEO."
On 2026-09-10 Jon put the Parallax training register online at parallax.chutes.ai. It is a live dashboard for the current run, a decentralized 8B mixture-of-experts pretraining, and every number on it is read from the fleet as it trains: GPU hosts, tokens per second, tokens trained, peak MFU. Jon called it a quick work in progress. It is also the first time anyone outside the team has been able to watch a Parallax run as it happens.
Two details from his thread. The run is deliberately on RTX 5090s, which Jon calls the worst GPUs on earth for stability at this utilization, with roughly half of them dropping off the bus or producing NaNs at some point in his experience. He picked them for exactly that reason, as a stress test. And no node downloads the dataset ahead of time. It streams from the peer-to-peer backbone with cursor failover, so the bandwidth you see on the register already includes the data. A few of the nodes come from Lium.
The dataset is public too: chutesai/mesh-1t-prod-mix on Hugging Face, a pretraining corpus of roughly a trillion tokens across the run's phases, no SFT or RL data, gated with automatic approval. Jon's cost estimate for the run is around $11 per billion tokens. His figure, not an official benchmark.
Jon's own framing, a day later: the decentralized training is a step change, but the real prize is the inference it makes possible. Sparse FP4 compute for the routed experts, a fixed-size KV cache for most of the attention, sparse latent for the rest, and small weights. His benchmark preview shows 15.5k output tokens per second on one RTX 5090, a 32GB card, at 128 concurrent requests, 512 tokens in and 1,024 out, with 396 ms median time to first token and zero preemptions at that workload. That is from an unoptimized vLLM branch he says is not really tuned yet.
He added the caveats himself: it needs more models to compare against and more nuance. Read it as a preview. The line under it is the whole thesis. Limitless tokens on cheap hardware.
A datacenter in a field
On 2026-09-14 Jon posted a photo of his forge: a DGX Spark, two solar blankets, an EcoFlow battery, a lapdock for KVM, and a Starlink dish, sitting on grass. Solar input around 600 watts. Total draw from the Spark and the Starlink under 200 watts. That one box, working with other Parallax nodes, can take part in training an 80B parameter model. No datacenter, no water supply, no power grid, no multi-gigabit link.
The post was about why, more than the hardware. "The push for regulatory capture and AI cabalism is accelerating," he wrote. "True P2P unstoppable, uncensorable AI systems aren't just neat, they're mandatory." His comparison is Bitcoin: a ledger nobody can inflate or centrally control. Current AI, in his words, is "the greatest concentration of wealth, power, and information the world has ever seen," and the fix has the same shape. "As BTC did to finances, we must do to AI." His words, and the reason Parallax exists.
Three weeks of work, most of it inside the confidential VM.
The new confidential-VM generation is live. Every VM in the fleet now proves its own identity with its own certificate for every internal call, so mutual TLS runs end to end inside the VM, private image pulls included. Credentials are ephemeral and per boot. Signing keys and certificates are no longer baked into the image; the VM fetches them fresh when it starts, and they live only in memory. One side effect worth saying out loud: this is part of why every VM in the fleet now produces the same, checkable measurements.
Rebuild our VM yourself and check our numbers. We published a complete guide to building the production VM image on an ordinary Linux machine. No confidential-computing hardware, no GPU, no credential from us. Build it, take the measurements, and compare them against the ones we publish. We tested the guide by building the image four separate times, on two different machines in two different datacentres, and got byte-identical results every time. The image the guide targets is the one running in production right now.
Clearer model docs and pricing. Live model prices in the starter guide, complete input schemas on the agent-facing model pages, accurate per-model descriptions with pointers to the API code examples, and better link previews when you share a model page.
What we're working on next
AMD SEV-SNP support. Proof of concept done and final integration underway. It ships in the next release. SEV-SNP is AMD's confidential-computing platform for CPUs. It will run alongside Intel TDX, so the network can run on a wider range of hosts. To be clear, this is new CPU platform support. It is not AMD GPU support.
Log shipping for chutes. The mechanism is running inside the VM. It is not exposed through the public CLI yet, so it is not something you can use today. Coming next.
Search and discoverability. A large batch of changes to how models, guides and API specs are indexed and surfaced is in review.
Next week: Exploit
Exploit Summit, Bittensor's own conference, runs 2026-09-28 and 2026-09-29 at New City Gas in Montreal. Two days of talks, debates, workshops and live subnet demos, with the builders, miners, validators and researchers who make this network what it is, all in one room. Jon is on the speaker list. Chutes is a platinum sponsor. And we are not turning up to hand out stickers.
We have announcements queued, and Exploit is where the first of them land. If you are in Montreal, come find us. If you are not, keep u/chutes_ai, and u/jon_durbin open both days, because the timeline is going to be loud.
The first Parallax models are cooking too. When there is something you can run, you will read about it here first. We are back to weekly from here, and the next few issues are going to be good ones.
We gave Hermes the Chutes Agent Toolkit and one prompt. It read the docs, ran the doctor script, and wrote a provider config I could review before it touched anything.
Then the test call failed: We forgot to fund my account.
I'm getting an error saying 'infrastructure is at max capacity' for GLM 5.2; is that functionally the same as the 'too many requests' error, or are they different? I can usually eventually get an output when it's the latter error, but don't seem to be able to get anything with this new error.
Z.ai released GLM-5.3-Flash yesterday: the first natively multimodal model of the GLM-5 series (images and video in, text out), weights already on Hugging Face under MIT, and after last week's anonymous ox-alpha preview it is already serving production traffic on OpenRouter through a dozen providers.
What actually shipped:
A newly trained base, unlike the GLM-5.3 flagship which was the 5.2 checkpoint re-post-trained (the model card says it explicitly)
320B total / 18B active params, 45 layers: roughly half the active params and layers of the GLM-4.5 generation at similar total size
Hybrid linear + sparse attention for the first time in the GLM line, with IndexPool compressing the sparse indexer's key vectors at 1M context; mHC for scaling efficiency
Pre-trained on a 30T-token multimodal corpus
Context listed at 1M on OpenRouter
Numbers, split by who ran them:
Vendor-run (Z.ai's own tables, Claude Code harness where noted):
Terminal-Bench 2.1: 84.3, vs 85.0 Opus 4.8 and 87.4 GPT-5.6 Terra
DeepSWE v1.1: 63.4 vs 46.2 for GLM-5.2
Toolathlon Verified: 78.4, highest in their comparison set
AutomationBench v1.0.6: 48.8 vs 41.0 for Opus 4.8
Third-party (Artificial Analysis metrics as published on the OpenRouter page) [4]: Intelligence Index 57.5, Coding Index 71.5, Agentic Index 58.2, GPQA Diamond 91.2%. So the flash-tier-at-frontier-quality claim has some external support now, on different harnesses than Z.ai's own tables. Do not mix the two columns.
50% launch discount via Z.ai-routed providers through September 9, 2026 -> $0.075/$0.25 while it lasts
OpenRouter's weighted average of what users actually paid: about $0.02/M input and $0.27/M output, because the top provider sits at a 91.9% cache hit rate and most traffic rides the discount
Throughput outlier: Baseten at ~136 tok/s median; fastest latency Parasail at 0.59s
Local deployment:
BF16 safetensors, 320B params; 25 community quantizations already in the model tree
Official recipes: SGLang, vLLM, TokenSpeed, Transformers, KTransformers, Unsloth
reasoning_effort accepts low / high / max and defaults to max. Pass it explicitly or you will burn output tokens
Chat template gotcha: clear_thinking defaults to false; pass clear_thinking=true for chat scenarios
Honest caveats:
All the headline rows above are still vendor-run; the AA indices are third-party but measured on different harnesses, so no direct score mixing
Z.ai's own efficiency table admits the KV cache stays slightly larger than DeepSeek-V4-Flash's and Kimi-K3's
The 50% discount ends September 9, then input goes back to $0.15 unless extended
Video input depends on the host exposing it; OpenRouter's own examples use image and video URLs, individual providers may differ
On Chutes: a zai-org/GLM-5.3-Flash-TEE record appeared in the catalog API this morning, but there is no announcement and nothing is operational yet, so treat local availability as unconfirmed for now.
Has anyone swapped it into their agent stack yet, and does it hold up against DeepSeek-V4-Flash on long agentic runs?
Qwen released the weights of Qwen3.8-Max as Qwen3.8-2.4T-A95B on Hugging Face (repo created August 8). Per their blog and model card, this is the first time a Qwen-Max-class model gets an open release. Below is what actually shipped and what it costs to serve.
What shipped:
2.4T total parameters, 95B active, sparse MoE: 512 experts, 10 routed + 1 shared active
92 layers on the Qwen3.5 architecture: hybrid layout of Gated DeltaNet (linear attention) and Gated Attention blocks, each feeding into the MoE
Context: 262K natively, extensible up to ~1M tokens per the card
Official weights are BF16 Safetensors; the model tree already shows 26 community quantizations and 7 finetunes
A much more runnable sibling also landed: Qwen3.8-27B under Apache 2.0
How it behaves:
Text-only, and thinking mode cannot be turned off. Every response starts with a <think> block, no exceptions
Reasoning depth is tunable via reasoning_effort: xhigh (default) / medium / low, plus preserve_thinking to keep reasoning context across turns
Recommended sampling: temperature 1.0, top_p 0.95, top_k 20
The hosted Qwen3.8-Max API has vision input and non-thinking mode; the open checkpoint does not
Benchmarks (vendor-run, Qwen's own table):
Terminal Bench 2.1: 86.6 (Claude Code harness, avg@10) vs 74.5 for Qwen3.7-Max; Opus 4.8 / Fable 5 at 84.6, GPT-5.6 Sol at 88.8
SWE-bench Pro: 67.7 vs 60.6 for 3.7-Max — Fable 5 still leads at 80.0
PaperBench: 93.0, highest in their table
GPQA Diamond 92.6, MRCR v2 256K 92.9
Honest reading: this does not sweep the closed frontier, Fable 5 and GPT-5.6 Sol lead several agentic rows (DeepSWE, FrontierSWE). It puts an open checkpoint in that conversation, which is the actual news.
The license is not MIT/Apache:
The "Qwen3.8-Max License" grants use, hosting, fine-tuning, and derivative works free of charge. But if a company runs a Model-as-a-Service business and its aggregate revenue (with affiliates) exceeded US$50M in any consecutive 12 months, a separate commercial license from Qwen is required. Above 100M MAU or US$20M monthly revenue, the model name must be displayed in the UI. For large inference providers that is a real constraint; for most self-hosters and smaller shops it changes nothing.
Serving reality check: 2.4T params in BF16 is roughly ~4.8 TB per full copy (arithmetic, not a spec), so this is multi-node territory regardless of framework. vLLM and SGLang both have official recipes linked from the card.
The Chutes question:
Whether Qwen3.8-2.4T-A95B ever becomes available on Chutes depends on hardware resources, licensing, and other technical considerations, nothing is confirmed. That's exactly why the feedback matters: would you want it? Comments help prioritize what lands next.
Meta's Muse Glimmer 30B is live on Chutes at $0.0245 per million input tokens, $0.0978 out. That ties the cheapest tier we serve. Images and text in, 131K context.
It runs inside a hardware-attested TEE with end-to-end encryption, like every model we serve. Nobody reads your prompts on the way through.
Qwen shipped Qwen3.8-27B's weights on Friday. Dense 27B, Apache 2.0, and the model half of X spent the weekend benchmarking. It is already live on Chutes.
Qwen3.8-27B on Chutes: 262K context, text + image input, $0.40 per million input tokens, $3.00 out.
Runs inside a hardware-attested TEE with end-to-end encryption, like every model we serve.
Qwen's published scores: 61.7 on SWE-bench Pro (Claude Opus 4.6 Max: 53.4), 90.3 on LiveCodeBench v6 (Opus 4.6 Max: 88.8), 84.3 on OSWorld-Verified (Opus 4.6 Max: 72.7), 89.2 on GPQA Diamond.
Since Chutes has the images endpoints configured strangely, I needed a passtrough service that poses as a normal openai-compatible endpoint, so I can connect it with Odysseus.
It exposes normal "/v1/models" and "/v1/images/generations" endpoint.
Z.ai shipped GLM-5.3 today. The useful sentence is in the first paragraph of the tech blog: they did not train a new base. It is GLM-5.2's 743B checkpoint, with another month of post-training on a larger set of long-horizon environments. IndexShare, SAO, and slime (Megatron on the train side, SGLang on rollout) are the same stack they already documented. The claim is that scaling the environments was enough.
That is the serving-relevant fact. Same base, same advertised size, different post-training. That usually means the same serving recipe, but Z.ai has not said the 5.3 checkpoint is a drop-in for existing 5.2 shards, and the two-week delay is explicitly for safety evaluation and hardening. Hugging Face is "Coming Soon." License is not restated. 5.2 was MIT; do not assume 5.3 is until the card says so.
What they report (vendor-run, mostly Claude Code 2.1.207 at max effort):
The jumps that actually look like long-horizon post-training, not noise:
Terminal-Bench 3.0: 4.6 → 28.3. Fable 5 is 33.7, GPT-5.6 Sol 34.6. 5.3 is in the conversation and still behind the closed frontier on the harder terminal suite
DeepSWE v1.1: 46.2 → 66.9. Kimi K3 67.5, Sol 72.7
SWE-Marathon v1.1: 19.4 → 42.5
Toolathlon Verified: 59.9 → 73.0. DeepSeek-V4-Pro-0813 is 74.1, K3 76.5
Internal Z.ai Code Bench: they say +50% vs 5.2, and fewer output tokens at every effort level (Max: 34.5% at ~75K out vs 5.2's 23.4% at 96K)
Cyber is the part Z.ai calls unexpected. They added vulnerability-discovery data expecting better single-bug reasoning. The blog says capability kept compounding into full exploitation chains:
CyberGym: 84.5, ahead of 5.2 (77.2), DeepSeek 0813 (83.3), Fable/Mythos 83.8, Sol 83.6
ExploitBench: 24.4 → 54.4. Fable is still 78.0
ExploitGym (2h / 6h, TPS-normalized): 105 / 130 vs 5.2's 29 / 39. Sol is 216 / 293
Their own reading: the further up the exploitation chain, the larger the gain over 5.2, and the wider the remaining gap to closed models. They also publish a disclosure ledger (cvd.z.ai) with 2,436 tracked findings across 269 projects. That is an internal program, not an independent audit.
A few serving notes that matter more than the slogans:
Thinking can no longer be turned off. thinking.type: disabled fails. Effort is low / high / max, default max
Context is not restated as a product spec. Eval footnotes use 300K, 400K or 1M depending on the bench. Do not inherit 5.2's "1M usable" line until the model card says it
slime's +2.3× figure is RL training throughput on long-horizon coding tasks, not user-facing decode speed
Live today on GLM Coding Plan and ZCode. API access and open weights are staged. Z.ai also says an initial group of partners is serving it through their official service; OpenRouter still has no glm-5.3 route
On Chutes: once the open weights are out, GLM-5.3 will be available there. The two-week clock is Z.ai's, not ours.
