Category: News Dossier

Model launches now ship with a chart before they ship with a changelog. Artificial Analysis Intelligence Index here, Chatbot Arena score there, SWE-bench percentage in the keynote slide. Most readers treat the number as a verdict. Operators who have shipped agents know better: the same model can top a composite index, tie on coding benchmarks, and still lose on your frozen traces. This dossier teaches chart literacy for 2026: what the Artificial Analysis Index measures, how LMSYS Arena scores relate to Elo, why OpenAI stopped reporting SWE-bench Verified, and why Fireworks’ Kimi K3 + Fable oracle routing is a ceiling, not a product spec. If you evaluate RAG or agents in production, pair this with Your RAG Benchmark Is Lying to You and our Kimi K3 routing dossier.

The Artificial Analysis Index: composite, not crystal ball

One number hides weighted benchmarks, token burn, and provider pricing.

Artificial Analysis publishes an Intelligence Index: a composite across multiple evaluations (methodology updated over time; v4.1 includes suites such as GDPval-AA v2, Terminal-Bench v2.1, and others listed on their site). Models are compared on intelligence, speed, and price, with explicit definitions for blended token pricing and cost per task weighted by benchmark mix in the Index.

“Cost per Task: The weighted-average cost (USD) to complete one Artificial Analysis Intelligence Index task. This is calculated by multiplying input, cached, and output token prices by tokens consumed across the workload, weighted by the relative weights of each benchmark in the Intelligence Index, then dividing by task count.” – Artificial Analysis, Benchmarking Methodology

How to read the chart: Treat Index score as a y-axis for broad capability under AA’s harness. Look sideways at cost per task and time per task before you celebrate a +2 point move. A flat Index score with halved time per task is a win for agents, not stagnation.

Merits of the argument: Composite indices reduce arguments at launch time. They cannot replace workload-specific eval without becoming your workload.

Case study: Gemini 3.6 Flash and flat intelligence

Google cites Artificial Analysis; AA’s pre-release testing shows unchanged Index score with better efficiency.

Google’s July 2026 Gemini launch leans on Artificial Analysis for token efficiency claims. On the Index, Google states 3.6 Flash consumes 17% fewer output tokens than 3.5 Flash.

“For example, on the Artificial Analysis Index, we see 3.6 Flash consuming 17% fewer output tokens than 3.5 Flash. It also takes fewer reasoning steps and tool calls to accomplish multi-step workflows.” – Google, Introducing Gemini 3.6 Flash

Artificial Analysis’ own pre-release article reports Gemini 3.6 Flash (high) at 50 on the Intelligence Index, matching Gemini 3.5 Flash, with more than 50% reduction in average time per task (1.3 vs 2.7 minutes) and ~18% lower cost per task ($0.50 vs $0.59).

“Gemini 3.6 Flash scores 50 on the Artificial Analysis Intelligence Index, matching Gemini 3.5 Flash, and just below recently released models Muse Spark 1.1 (xhigh, 51) and GPT-5.6 Luna (max, 51).” – Artificial Analysis, Gemini 3.6 Flash and 3.5 Flash-Lite

Merits of the argument: Vendor blogs will highlight sub-benchmark gains (GDPval-AA, DeepSWE). The Index may stay flat whilst operations improve. Read the release notes table, not the headline badge alone.

Chatbot Arena: Bradley-Terry scores and style control

Crowdsourced pairwise battles; confounding by length and markdown.

LMSYS Chatbot Arena ranks models from anonymous pairwise human preferences. The leaderboard now publishes an Arena score from Bradley-Terry maximum likelihood estimation (formerly described as Elo-like). Scores use a 400-point scaling so win rates between models remain interpretable.

“To improve the quality of our rankings and their confidence estimates, we are adopting another widely used rating system called the Bradley–Terry(BT) model. This model actually is the maximum likelihood (MLE) estimate of the underlying Elo model assuming a fixed but unknown pairwise win-rate.” – LMSYS, Chatbot Arena Elo system update

Arena rankings correlate with capability but confound style: longer answers, headers, and lists win votes. LMSYS added style-controlled regression (length, markdown headers, lists) so model coefficients better reflect substance.

“By doing this, we expect that the Arena Score of each model will reflect its strength, controlled for the effect of length.” – LMSYS, Does style matter?

Merits of the argument: Arena is unmatched for open-ended chat preference at scale. It is a weak sole metric for tool-using agents, compliance-bound workflows, or exact citation tasks.

SWE-bench Verified: contamination and broken tests

OpenAI stopped reporting Verified; recommends SWE-bench Pro for frontier launches.

In February 2026 OpenAI documented two failures: flawed tests rejecting correct solutions, and training contamination on public repo problems. On a hard subset audit, at least 59.4% of audited problems had material test or specification issues.

“In our analysis we found that all frontier models we tested were able to reproduce the original, human-written bug fix used as the ground-truth reference, known as the gold patch, or verbatim problem statement specifics for certain tasks, indicating that all of them have seen at least some of the problems and solutions during training.” – OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities

“This is why we have stopped reporting SWE-bench Verified scores, and we recommend that other model developers do so too.” – OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities

Merits of the argument: A rising Verified percentage may measure memorisation and bad graders, not engineering skill. Prefer Pro or, better, your private frozen traces with independent tests, as argued in our RAG eval guide.

Oracle routing ceilings: Kimi K3 and Fable

93% is not your router; it is the best possible model pick per task with hindsight.

Fireworks benchmarked ~1,030 agentic tasks across SWE, terminal, algorithmic, multi-language, and legal families. Headline SWE scores for Kimi K3 and Fable 5 were nearly tied (92.4% vs 92.6%). The lesson is routing: oracle selection beat either model alone.

“Oracle routing is a method for measuring the best theoretical performance by running the task through each model and then picking the cheapest correct option (the cost/performance ceiling). In a practical router, you don’t get to run your task against multiple models.” – Fireworks AI, Kimi K3 is competitive with Fable

“We achieved 93% accuracy with routing between K3 and Fable.” – Fireworks AI, Kimi K3 is competitive with Fable

Oracle routing sent 72–96% of tasks to K3 in their study. Production routers must predict that split without running every task twice. See our Kimi dossier for cache-hit economics and harness constraints when you implement routing for real.

Merits of the argument: Leaderboards rank single models. State of the art for cost-aware agents is increasingly mixtures. Quoting 93% without the oracle caveat misleads procurement.

Failure cases

Case 1: Procurement by Index rank alone

You standardise on “whatever scores 50+” whilst your workload is 90% cheap retrieval QA. You overpay and add latency. Fix: weight benchmarks that mirror task mix; read cost per task on AA charts.

Case 2: Quoting SWE-bench Verified in 2026

Vendor slide still shows Verified at 80%+. OpenAI explicitly recommends stopping. You compare apples to contaminated oranges against competitors on Pro or private harnesses.

Case 3: Arena win rate as agent SLA

Chat preference rewards helpful tone on open questions, not correct SQL against your warehouse schema. Agents need tool-grounded eval, not voter applause.

Case 4: Treating oracle routing results as shipped product

Engineering plans assume 93% because a blog post said so. Production router without labelled traces lands far below oracle. Budget measurement for router training and fallback models.

Migration: build a leaderboard reading habit

1. For each launch, write down three axes: Index or task score, cost per task, time per task (AA definitions).
2. Check benchmark version strings (AA v4.1, SWE Pro vs Verified, Arena style-controlled table).
3. Map vendor claims to primary URLs in a claim audit table before internal slides reuse numbers.
4. Freeze 100 production traces per critical workflow; never migrate on public leaderboard alone.
5. Separate chat preference eval from agent eval (tools, permissions, escalation).
6. When comparing open vs closed, include routing economics (K3 default, premium model on tail) not single-model hero picks.

When headline leaderboard order is enough

• Early exploration when failure is cheap and no production traffic exists.
• Qualitative chat UX trials where Arena-like preference matches user delight.
• Vendor selection shortlists before you invest in private harness build-out.

Once agents touch customer data or money, headline order is insufficient.

What to check right now

• Do internal slides still cite SWE-bench Verified without a contamination footnote?
• When someone cites AA Index 50, do they also cite cost per task and time per task from the same card?
• Is Arena score labelled style-controlled or raw?
• Do routing proposals distinguish oracle ceilings from production routers?
• Does your eval programme include harness integrity checks (see RAG benchmark post)?
• Are Gemini or other vendor AA citations linked to the AA primary article, not recap blogs alone?

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Artificial Analysis – Benchmarking Methodology – Intelligence Index, cost per task, performance definitions
• Artificial Analysis – Gemini 3.6 Flash and 3.5 Flash-Lite – flat Index 50, time/cost per task deltas
• Google – Gemini 3.6 Flash launch – 17% token reduction claim on AA Index
• OpenAI – SWE-bench Verified analysis – contamination, 59.4% flawed hard subset, stop reporting recommendation
• LMSYS – Bradley-Terry Arena update – Arena score methodology
• LMSYS – Style control in Arena – length/markdown confounding
• Fireworks AI – Kimi K3 + Fable routing study – oracle routing definition, 93% ceiling, 72–96% K3 traffic
• SudoAll – Your RAG Benchmark Is Lying to You – harness and governance complement to public leaderboards
• SudoAll – Kimi K3 cost per task and routing – production routing economics and harness reality

nJoy 😉

Microsoft Build 2026 was billed as an agentic platform story. Underneath the keynotes sits a sharper move: seven in-house MAI models, led by MAI-Thinking-1 for reasoning and a coding model rolling out through GitHub Copilot (Microsoft’s Build live blog names MAI-Code-1-Flash; the official Microsoft Build blog post calls it MAI-Code-1). Microsoft states these were trained from scratch on enterprise-grade data without distillation from third-party frontier models. That is Copilot independence as architecture and routing economics, not an overnight divorce from every OpenAI endpoint. This dossier reads the primary Microsoft sources carefully and separates verified claims from launch-stage benchmark marketing.

MAI-Thinking-1: mid-size MoE aimed at daily enterprise load

35 billion active parameters, 256K context, private preview on Foundry.

MAI-Thinking-1 is Microsoft AI’s first reasoning model. Microsoft positions it as strong in its weight class on software engineering benchmarks, mathematics, and blind human side-by-sides, whilst keeping inference footprint smaller than much larger dense models.

“MAI-Thinking-1 is a 35B-active, ~1T-total parameters, sparse Mixture of Experts model, a smaller inference footprint than much larger models. Despite this, our model is toe-to-toe with Claude Opus 4.6 on SWE-Bench Pro.” – Microsoft AI, Introducing MAI-Thinking-1

Enterprise features emphasised on the model page include a 256K token context window, function calling, multi-layer instruction following, and Chat Completions API compatibility via Microsoft Foundry security and compliance boundaries.

Merits of the argument: MoE at 35B active is a plausible daily-driver shape for document-heavy agents and long traces without Opus-class cost on every request. The SWE-Bench Pro claim is vendor-reported; treat it as a hypothesis until your repo harness confirms it.

Training story: learned, not distilled

Provenance and steerability as product claims, not footnotes.

Microsoft repeats a clear training constraint across the MAI-Thinking-1 post and the Azure Foundry blog: models trained from the ground up on clean, traceable, enterprise-grade data, without distillation from third-party frontier models.

“We don’t distill from other labs and we don’t rely on opaque data. Our datasets are clean, traceable, and enterprise-grade.” – Microsoft AI, Introducing MAI-Thinking-1

The Foundry blog adds the economic framing: MoE selectively activates only parts of the model per request, so “capability scales without compute scaling linearly,” aimed at high-volume, always-on workloads.

“MAI-Thinking-1 uses a Mixture-of-Experts (MoE) architecture that selectively activates only the parts of the model needed for each request. The result: capability scales without compute scaling linearly.” – Microsoft, New MAI models in Microsoft Foundry

Merits of the argument: For regulated customers, provenance beats leaderboard points. Distillation-free training is a procurement question auditors can ask; independent verification still requires eval on your data, not trust alone.

Copilot routing: MAI-Code alongside the catalog

Independence starts where Microsoft controls default model pickers and margin.

Microsoft’s Build blog states MAI-Code-1 is an inference-efficient coding model now available in Copilot and VS Code. The Build live blog adds that MAI-Code-1-Flash is purpose-built for GitHub Copilot and VS Code to deliver high performance and lower cost, with image, transcription, and voice models generally available on Foundry.

Crucially, Microsoft is not shrinking the catalog to MAI alone. The same keynote promises MAI models on Fireworks AI, Baseten, and Open Router, and Fireworks generally available on Foundry for governance with Azure data residency.

“Developer choice doesn’t stop at our catalog. MAI models will also be available on Fireworks AI, Baseten and Open Router.” – Microsoft, Microsoft Build 2026 blog

Merits of the argument: Copilot independence is partial and strategic: a first-party coding route for high-volume completions, whilst Foundry remains a multi-vendor marketplace. Operators should watch default routing in VS Code, not only model availability lists.

Failure cases

Case 1: Treating SWE-Bench Pro parity as your monorepo proof

Microsoft’s Opus 4.6 comparison is on a public benchmark harness. Your private codebase, test flakiness, and CI secrets will differ. Shipping MAI-Thinking-1 on benchmark faith alone invites regressions on internal frameworks.

Case 2: Assuming “no distillation” means “no OpenAI dependency anywhere”

MAI models do not require OpenAI weights, but Microsoft’s stack still integrates external models and OpenAI remains in the broader Azure/Copilot ecosystem. Independence is model lineage, not single-vendor isolation.

Case 3: Private preview confusion

MAI-Thinking-1 is private preview on Foundry whilst Copilot coding routes may be GA for individual tiers. Teams procuring “MAI everywhere” hit access walls if they never requested preview enrolment.

Case 4: Ignoring naming drift (MAI-Code-1 vs MAI-Code-1-Flash)

Primary Microsoft sources use both names. Automation that pins model IDs from blog posts alone may target the wrong endpoint. Confirm IDs in Foundry/Copilot docs at deploy time.

Migration: evaluate MAI without betting the fleet

1. Request Foundry private preview for MAI-Thinking-1 if you need long-context reasoning agents.
2. Enable MAI coding model in Copilot/VS Code picker for a pilot team; keep incumbent model as fallback.
3. Run frozen traces from your agent logs on both models; measure pass rate, tokens, and wall time.
4. Map compliance boundaries (Foundry region, logging, content filtering) before routing customer data.
5. Document model IDs explicitly in repos; do not rely on marketing names alone.
6. Revisit routing policy quarterly as Microsoft expands MAI across M365 Copilot and Foundry.

When staying on third-party models is fine

• Preview access unavailable and timelines are fixed.
• Your harness already tuned for Claude/GPT tool schemas and refusal behaviour.
• Benchmark-sensitive launches where external independent evals matter more than first-party claims.
• Multi-cloud strategy deliberately avoids Azure-native model lock-in.

What to check right now

• Which Copilot tier exposes MAI-Code / MAI-Code-1-Flash in your tenant’s model picker?
• Is MAI-Thinking-1 preview approved for your Foundry subscription and region?
• Do you have side-by-side SWE or agent traces logged for A/B testing?
• Are procurement contracts still OpenAI-weighted on inference spend despite MAI options?
• Who owns model ID pins in CI and local dev configs?

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Microsoft AI – Introducing MAI-Thinking-1 – architecture, SWE-Bench Pro claim, training constraints, enterprise features
• Microsoft – New MAI models in Microsoft Foundry – MoE economics, modality lineup, preview/GA status
• Microsoft – Build 2026 official blog – seven-model family, Copilot availability, multi-provider routing
• Microsoft – Build 2026 live blog – MAI-Code-1-Flash naming (secondary corroboration only; not used for blockquotes)

nJoy 😉

Cohere’s pitch for years was enterprise NLP you could run inside your boundary. With Command A+, released May 2026, they consolidate reasoning, multimodal document work, tool use, and 48-language coverage into one Apache 2.0 mixture-of-experts model that claims to fit on as little as two H100 GPUs at W4A4 quantisation. That is a different trade from “download weights and figure out infra later.” It is a sovereign-agent workhorse spec: 218 billion total parameters, 25 billion active, 128K input context, and a score of 37 on the Artificial Analysis Intelligence Index among open models. The question for operators is not whether the blog chart looks good, but whether your security, GPU, and eval stack can absorb it.

One model to replace a scattered Command fleet

North customer deployments drove consolidation; Command A+ unifies capabilities that used to ship as separate SKUs.

Cohere built Command A+ from a year of deploying North, its enterprise agent workspace. Previous Command variants split reasoning, vision, and translation across separate models. Command A+ merges those capabilities: reasoning, multimodal input, tool use, and multilingual support in one sparse MoE architecture.

“Command A+ is an efficient, versatile, and privately deployable LLM built for high-performance agentic tasks with minimal compute overhead.” – Cohere, Introducing Command A+

Internal North evaluations cited in the launch post show double-digit gains on agentic question answering (+20% vs Command A Reasoning), spreadsheet analysis (+32%), and memory usage quality (54% vs 39%). Treat those as vendor-internal harness scores, not independent leaderboard truth, but they signal design targets: MCP-connected file systems, uploaded spreadsheets, and cross-session memory.

Merits of the argument: Enterprises drowning in model SKUs pay integration tax on every new endpoint. A unified MoE with Apache 2.0 weights reduces vendor lock-in at the model layer while keeping Cohere’s managed path (Model Vault, API) optional.

Hardware honesty: two H100s, not a laptop

W4A4 quantisation is the enabler; ignoring the floor guarantees a science project.

Cohere publishes explicit hardware minima: BF16, FP8, and W4A4 quantisations on Hugging Face, with “imperceptible” quality differences at 4-bit in their testing. At W4A4, Command A+ is specified to run on as little as two NVIDIA H100s or one Blackwell B200.

“In practice, this enables Command A+ to run on as little as two NVIDIA H100s or a single NVIDIA Blackwell GPU, with virtually no quality degradation.” – Cohere, Introducing Command A+

Efficiency claims are concrete: up to 63% higher output tokens per second and up to 17% lower time to first token versus Command A Reasoning at matched quantisation and concurrency; W4A4 adds another 47% speed and 13% latency improvement in their measurements. Speculative decoding tuned for MoE adds a further 1.5–1.6× inference speedup.

Merits of the argument: Sovereign AI fails when procurement hears “open weights” and budgets zero GPUs. Cohere’s published floor gives capacity planners a number to challenge or accept.

Benchmarks and the AA Index 37

Public open-model positioning; verify on your workload, not on marketing tables alone.

On public agentic suites, Cohere reports τ²-Bench Telecom rising from 37% to 85% versus Command A Reasoning, and Terminal-Bench Hard from 3% to 25%. Multimodal scores include MMMU Pro at 63% and MathVista improvement to 80.6%.

“Command A+ achieved a score of 37 on the Artificial Analysis Intelligence Index , outperforming other leading open models, reflecting its strength as a general-purpose model for enterprise agentic workflows [3].” – Cohere, Introducing Command A+

Language coverage expanded from 23 to 48 languages, with tokenizer efficiency gains (20% fewer tokens for Arabic, 16% for Korean, 18% for Japanese versus predecessors). That matters for bill size on long multilingual agent traces.

Merits of the argument: AA Index 37 is a composite, not a guarantee on your RAG corpus or tool schema. It is still a useful cross-vendor anchor when comparing open weights against closed APIs at similar price tiers.

Failure cases

Case 1: “Sovereign” without network and weight governance

Teams download Apache 2.0 weights but serve them from a public endpoint with open ingress. Sovereignty requires checksum verification, private networking, egress allowlists, and audit logs, not just a licence header.

Case 2: Planning for one H100 because the headline said “efficient”

Minimum spec is two H100s at W4A4 (or one B200). Undersized clusters mean queue latency that kills agent loops, then blame on “MoE doesn’t work.”

Case 3: Treating North-internal +20% gains as your production SLA

Cohere’s North evaluations use LLM-as-judge on connected cloud file systems and spreadsheets. Your documents, MCP tools, and auth model will differ. Re-benchmark on frozen traces before migration.

Case 4: Ignoring quantisation ops

W4A4 is attractive on paper; vLLM tensor parallel setup, calibration, and regression tests against BF16 on your prompts are not free. Skipping validation invites silent quality drift on long-horizon tool calls.

Migration: from split Command endpoints to Command A+

1. Inventory current Command endpoints (reasoning, vision, translate) and map each to Command A+ modality support.
2. Size GPU footprint against published minima; budget B200 or 2× H100 per production slice, not peak demo.
3. Pull W4A4 weights from Hugging Face; run parity evals on agent traces you already log.
4. Re-test multilingual prompts that previously needed Command A Translate.
5. Update tokenizer assumptions in cost models (fewer tokens per response in several languages).
6. Keep Model Vault/API as fallback during cutover if self-host SRE capacity is thin.

When Command A+ is overkill

• Single-language FAQ bots with no tools and no document images.
• Batch embedding or rerank jobs better served by Cohere Embed/Rerank SKUs.
• Teams without GPU ops who will not use Model Vault or a managed provider.
• Regulated workloads where Apache 2.0 is fine but your policy mandates a different approved model list.

What to check right now

• Do you have 2× H100 (or B200) per isolated production environment, or a managed inference contract?
• Have you frozen 50–100 real agent traces for before/after Command A+ testing?
• Are MCP/tool permissions scoped per agent, not per “model server”?
• Did you re-price multilingual workloads with the new tokenizer efficiencies?
• Is W4A4 validated on your longest context prompts (128K input ceiling)?
• Who owns weight updates and checksum verification on your artifact store?

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Cohere – Introducing Command A+ – Apache 2.0, 218B/25B MoE, hardware minima, AA Index 37, efficiency and multilingual claims
• Artificial Analysis – Benchmarking Methodology – Intelligence Index and cost-per-task definitions

nJoy 😉

July 2026 is the month open MoE stops being a niche hobby. Kimi K3 (2.8T MoE, weights promised by 27 July), DeepSeek V4 (MIT weights live since April preview), and GLM-5.2 (MIT on Hugging Face, API from Z.ai) all target long-horizon coding agents with 1M context and radically different sticker prices. The mistake is comparing $/MTok in a table and declaring a winner. The correct unit is cost-per-task under your harness, with license and self-host path in the same spreadsheet. Our earlier Kimi K3 routing dossier established that framing; this piece extends it across three open-family flagships.

Three models, three open strategies

Scale vs sparse activation vs MIT drop · same agent buyer, different ops profile

Kimi K3 is Moonshot’s 2.8T-parameter open frontier play with Kimi Delta Attention, 1M context, and API pricing that assumes heavy prefix caching. DeepSeek V4 splits Pro (1.6T total, 49B active) and Flash (284B total, 13B active) with MIT weights already on Hugging Face. GLM-5.2 is Z.ai’s MIT-licensed 753B MoE flagship with 1M context and a mature Z.ai API tier list.

“Kimi K3 is a 2.8T-parameter model built on our Kimi Delta Attention and Attention Residuals, with native vision capabilities and a 1-million-token context window. It is the world’s first open 3T-class model, designed for frontier intelligence across long-horizon coding, knowledge work, and reasoning.” – Moonshot AI, Kimi K3 Tech Blog

“We present a preview version of **DeepSeek-V4** series, including two strong Mixture-of-Experts (MoE) language models — **DeepSeek-V4-Pro** with 1.6T parameters (49B activated) and **DeepSeek-V4-Flash** with 284B parameters (13B activated) — both supporting a context length of **one million tokens**.” – DeepSeek-V4-Pro README

“**Pure Open**: An MIT open-source license — no regional limits, technical access without borders” – GLM-5.2 README (Hugging Face)

Merits of the argument. All three vendors sell agentic coding narratives, but weight availability timing differs: DeepSeek and GLM-5.2 weights are downloadable now; Kimi K3 lists full weights by 27 July 2026. That affects compliance teams choosing self-host today vs wait-and-pin.

License and self-host matrix

MIT across the board · disk and GPU reality is not free

Model family	License (official)	Weights status (Jul 2026)	Self-host note
Kimi K3	Open weights release stated; follow Moonshot license on release	Full weights by 27 Jul 2026 (blog)	Moonshot recommends 64+ accelerator supernode for efficient serving; vLLM KDA cache contribution noted
DeepSeek V4-Pro	MIT (HF README)	Live on Hugging Face (~865 GB class instruct)	Official inference folder + vLLM/SGLang; Think Max needs large context budget
DeepSeek V4-Flash	MIT	Live (~160 GB class instruct per release blog)	Lower active params (13B) → cheaper GPU tier for many loops
GLM-5.2	MIT (HF card)	Live zai-org/GLM-5.2	Docs list vLLM, SGLang, Transformers, KTransformers builds

Merits of the argument. MIT removes licensing friction for commercial fine-tunes and on-prem deployments. It does not remove capex: Pro-class MoE at 1M context is a datacentre decision, not a MacBook one.

Hosted API cost comparison (official list prices)

$/MTok is inputs to cost-per-task, not the final invoice

Provider / model	Input (cache miss) / 1M	Input (cache hit) / 1M	Output / 1M
Kimi API – kimi-k3	$3.00	$0.30	$15.00
DeepSeek – deepseek-v4-flash	$0.14	$0.0028	$0.28
DeepSeek – deepseek-v4-pro	$0.435	$0.003625	$0.87
Z.ai API – GLM-5.2	$1.40	$0.26	$4.40

“Pricing is $0.30/MTok for cache-hit input, $3.00/MTok for cache-miss input, and $15.00/MTok for output. Powered by Mooncake’s disaggregated inference architecture, the official Kimi API achieves a cache hit rate above 90% in coding workloads.” – Moonshot AI, Kimi K3 Availability

Merits of the argument. Sticker miss rates mis-rank Kimi: at 90% cache hits on coding workloads, effective input cost approaches $0.30 + 0.1×$3.00 = $0.60/M blended (before output). DeepSeek Flash is still cheaper on pure API arithmetic for uncached bursts, but may trade off peak agent quality on your hardest tasks. GLM-5.2 sits in the middle on price with strong long-context coding claims on the HF card.

When each model fits (honest trade-offs)

No single “best open MoE” · match model to task class

• Kimi K3: Long-horizon agent loops where Moonshot harness compatibility (thinking history preservation) and cache economics matter. Moonshot notes overall UX still trails Claude Fable 5 and GPT 5.6 Sol on experience, despite benchmark wins in places.
• DeepSeek V4 Flash: High-volume agent workers, chat, and cost-sensitive loops; upgrade to Pro when Flash max thinking fails eval gates.
• DeepSeek V4 Pro: Hard reasoning and agentic benchmarks where open weights and MIT matter; accept higher $/MTok and lower concurrency limit (500 vs Flash 2500 in API docs).
• GLM-5.2: Teams wanting MIT weights plus a mid-price API with 1M context and Z.ai coding-plan optionality; validate Terminal Bench / SWE claims on your harness, not HF footnotes alone.

Cross-link: routing patterns (planner/worker, oracle vs production router) from sudoall.com/kimi-k3-cost-per-task-routing-harness/ apply unchanged across these ids.

Failure cases

Open weights ≠ easy operations

• Kimi thinking-history sensitivity. Moonshot warns quality becomes unstable if harness strips historical thinking content or mid-session model swaps occur.
• Cache-assumed pricing. Kimi’s economic story collapses if your prompts never repeat prefixes (low cache hit).
• Self-host fantasy. Downloading MIT weights without a serving plan (quantisation, expert parallel, 1M KV cache) burns calendar time.
• Benchmark tourism. Each lab cites different harnesses (KimiCode, Claude Code, Codex); leaderboard numbers are not interchangeable.

Migration and fleet design

Start with API ids · add self-host when unit economics cross GPU breakeven

1. Pick two API ids for shadow testing: e.g. kimi-k3 + deepseek-v4-flash, or glm-5.2 + deepseek-v4-pro.
2. Log tokens, cache hits, latency, and task success for 100 production-shaped tickets each.
3. Compute cost-per-successful-task (not cost-per-request).
4. If monthly spend exceeds self-host capex threshold for your security zone, pilot MIT weights on a fixed GPU pool.
5. Keep a closed-model escalation path for tasks where open models fail compliance or quality SLAs.

When open MoE is actually fine

Agent fleets with routing, caching, and fallback

• Engineering orgs with eval harnesses and willingness to run dual-provider routers.
• Regulated environments requiring weight custody (MIT self-host) even if API is cheaper short term.
• Batch overnight coding jobs where latency matters less than $/merged PR.

What to check right now

Checklist for platform leads

1. Build the license/self-host/API matrix for your compliance team (use table above as starter).
2. Measure cache hit rate on your current coding agent prompts (Kimi and DeepSeek both reward repeats).
3. Download GLM-5.2 or DeepSeek-V4-Flash weights only if you have a serving owner; otherwise stay on API.
4. Calendar Kimi K3 weight release (27 Jul 2026) if your policy requires local mirror on day zero.
5. Re-read Moonshot K3 limitations (thinking history, excessive proactiveness) before defaulting agents.

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Moonshot AI – Kimi K3 Tech Blog – 2.8T MoE, 1M context, API pricing, cache hit claim, weight timing, limitations
• DeepSeek-V4-Pro README – MoE sizes, 1M context, MIT license
• DeepSeek API Docs – Models & Pricing – V4 Flash/Pro USD rates
• Z.ai – GLM-5.2 on Hugging Face – MIT license quote, 1M context, benchmark table
• Z.ai – API Pricing – GLM-5.2 $1.4 / $0.26 / $4.4 per 1M tokens
• sudoall.com – Kimi K3 cost-per-task routing harness – cost-per-task methodology

nJoy 😉

DeepSeek V4 is not waiting for you to notice. The API docs already expose deepseek-v4-pro and deepseek-v4-flash with 1M context, flat USD pricing, and a hard retirement date for legacy aliases deepseek-chat and deepseek-reasoner: 2026-07-24 15:59 UTC. If your configs still say “chat” or “reasoner”, July 24 is an outage event, not a deprecation warning. What is harder to verify from primary docs right now is the viral “peak/off-peak 2× Beijing hours” story: the official pricing page lists single off-peak-style USD rates only. This dossier separates verified migration facts from recap noise.

What GA means for V4 (verified)

Same model IDs · legacy aliases retire 24 July 2026 · open weights under MIT

DeepSeek’s April 2026 preview announcement states V4 preview is live and open-sourced, with weights on Hugging Face and API model ids deepseek-v4-pro and deepseek-v4-flash. The first API call docs and pricing table use those ids today. Legacy names map to V4 Flash modes until cutoff, then stop working.

“deepseek-chat & deepseek-reasoner will be fully retired and inaccessible after Jul 24th, 2026, 15:59 (UTC Time). (Currently routing to deepseek-v4-flash non-thinking/thinking).” – DeepSeek API Docs – V4 Preview Release

“The model names deepseek-chat and deepseek-reasoner will be deprecated on 2026/07/24 15:59 UTC. For compatibility, they correspond to the non-thinking mode and thinking mode of deepseek-v4-flash, respectively.” – DeepSeek API Docs – Your First API Call

“This repository and the model weights are licensed under the [MIT License](LICENSE).” – DeepSeek-V4-Pro README (Hugging Face)

Merits of the argument. MIT-licensed weights plus stable API ids give you three exit ramps: hosted API, self-host, or hybrid. The alias deadline is the only date you must calendar today; everything else is optimisation.

Official API pricing (flat USD, July 2026 docs)

Per-million-token table · cache hit rates matter for agents

DeepSeek’s Models & Pricing page lists per-1M-token USD charges for both tiers. Both support 1M context and up to 384K max output in the published table. Thinking mode is toggled per request rather than via separate model names after migration.

Billing item	deepseek-v4-flash	deepseek-v4-pro
Input (cache hit) / 1M	$0.0028	$0.003625
Input (cache miss) / 1M	$0.14	$0.435
Output / 1M	$0.28	$0.87
Context length	1M	1M
Concurrency limit (docs footnote)	2500	500

“The prices listed below are in units of per 1M tokens. A token, the smallest unit of text that the model recognizes, can be a word, a number, or even a punctuation mark. We will bill based on the total number of input and output tokens by the model.” – DeepSeek API Docs – Models & Pricing

Merits of the argument. Flash is the default economic choice for high-volume chat, classification, and many agent loops; Pro is for harder reasoning when Flash max thinking still misses your bar. Cache-hit pricing at sub-cent per million input tokens rewards repeated system prompts if your harness enables DeepSeek context caching.

Peak pricing: what we could not verify on primary docs

Recap blogs claim Beijing peak windows · official rate card is flat

Multiple third-party July 2026 articles describe GA “peak/off-peak” billing with 2× multipliers during Beijing business hours (often cited as 09:00–12:00 and 14:00–18:00 UTC+8). As of fetches against api-docs.deepseek.com/quick_start/pricing (English and Chinese), those pages show a single USD rate column with no peak multiplier table. We do not quote peak-hour figures as verified facts in this dossier.

Merits of the argument. Operators should watch the DeepSeek platform billing UI and changelog for pricing-structure emails (recap sites mention 24-hour notice) rather than scheduling batch jobs around recap timezone math until DeepSeek publishes peak tables on the official docs domain.

Model ID migration matrix

Replace aliases before 24 July 2026 · map thinking mode explicitly

Legacy id	Current routing (until cutoff)	Target id	Thinking
deepseek-chat	V4 Flash non-thinking	deepseek-v4-flash	disabled / non-think
deepseek-reasoner	V4 Flash thinking	deepseek-v4-flash	enabled (see thinking_mode guide)
(new hard tasks)	–	deepseek-v4-pro	per workload eval

Base URLs remain https://api.deepseek.com (OpenAI format) and https://api.deepseek.com/anthropic (Anthropic format) per first-call docs.

Failure cases

Migration and cost surprises

• Missed alias deadline. Production configs referencing retired ids fail hard after 15:59 UTC on 24 July 2026.
• Assuming reasoner → Pro. Legacy reasoner maps to V4 Flash thinking, not Pro; quality/cost profiles differ.
• Peak pricing hearsay. Capacity plans built on unverified 2× windows may be wrong if your account still bills flat rates.
• Pro concurrency 500. Burst agent fleets may hit rate limits faster on Pro than Flash (2500 in docs table).

Migration steps

Search-replace ids · re-benchmark thinking modes

1. Grep infra for deepseek-chat and deepseek-reasoner (env vars, Helm values, CI secrets).
2. Switch to deepseek-v4-flash or deepseek-v4-pro with explicit thinking flags.
3. Run parallel shadow traffic for 48 hours; compare pass rate and token usage.
4. Enable context caching on stable system prompts where supported.
5. Optional: download MIT weights from Hugging Face collection if self-host is in scope.

curl https://api.deepseek.com/chat/completions 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" 
  -d '{
        "model": "deepseek-v4-pro",
        "messages": [
          {"role": "system", "content": "You are a helpful assistant."},
          {"role": "user", "content": "Hello!"}
        ],
        "thinking": {"type": "enabled"},
        "reasoning_effort": "high",
        "stream": false
      }'

When flat V4 pricing is actually fine

High-volume Flash loops and open-weight optionality

• Batch extraction, L1 support triage, and agent workers where Flash thinking suffices.
• Teams needing MIT weights for air-gapped or cost-cap self-host (accept GPU capex).
• Off-peak batch reprocessing if your contract later adds time-of-day multipliers (monitor official docs).

What to check right now

Operator checklist

1. Inventory every reference to legacy DeepSeek model names; deadline 2026-07-24 15:59 UTC.
2. Confirm current invoice line items against api-docs.deepseek.com/quick_start/pricing.
3. Benchmark Flash max vs Pro on your top 20 agent tasks.
4. Subscribe to DeepSeek API changelog / platform notices for pricing-structure changes.
5. Document fallback vendor if Pro concurrency limits bite.

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• DeepSeek API Docs – Models & Pricing – USD rates, context 1M, model ids, alias footnote
• DeepSeek API Docs – Your First API Call – base URLs, model list, deprecation date
• DeepSeek API Docs – V4 Preview Release – open weights, 1M context, Jul 24 retirement note
• DeepSeek-V4-Pro README – MIT license statement

nJoy 😉

Meta’s Muse Spark 1.1 release is not just a model bump. It pairs a multimodal agentic model with the first public preview of the Meta Model API: OpenAI-compatible, Anthropic-compatible, base URL https://api.meta.ai/v1, model id muse-spark-1.1, and a 1M-token context window. For teams already running OpenCode, Claude Code, or LangChain against other vendors, the migration cost is mostly configuration, not a rewrite. The hard part is deciding whether Meta’s agentic story (computer use, subagents, context compaction) matches your production harness before you route real customer traffic.

Muse Spark 1.1: agentic and multimodal

Planning, tools, computer use, and coding in one model · public preview API

Meta Superintelligence Labs describes Muse Spark 1.1 as a significant upgrade focused on tool and computer use, coding, and multimodal understanding. The model is positioned for personal agentic tasks that require planning across external apps, MCP servers, and custom skills, with explicit training for multi-agent orchestration and 1M-token context management.

“Muse Spark 1.1 is a multimodal reasoning model built for agentic tasks, with major gains in tool and computer use, coding, and multimodal understanding.” – Meta, Introducing Muse Spark 1.1

“Along with this release, we are launching a public preview of the new Meta Model API where developers can access Muse Spark 1.1.” – Meta, Introducing Muse Spark 1.1

Merits of the argument. Meta is shipping API access in the same beat as the model, which reduces the usual “model exists but no stable endpoint” gap. Safety evaluation references (Advanced AI Scaling Framework) are documented in the blog; still run your own red-team suite before customer-facing agents.

Meta Model API: drop-in compatibility

Same auth, three request shapes · OpenAI and Anthropic SDK paths

The developer docs state plainly that Meta Model API is drop-in compatible with OpenAI SDK, Anthropic SDK, and agent CLIs such as OpenCode and Claude Code. You point the client at the base URL, set MODEL_API_KEY, and choose Responses, Chat Completions, or Messages depending on what your harness already speaks.

“Muse Spark 1.1 can actively manage its context window of 1 million tokens.” – Meta, Introducing Muse Spark 1.1

“For the first time, developers can begin building with Muse Spark 1.1 via the new Meta Model API, now in public preview.” – Meta, Introducing Muse Spark 1.1

Parameter	Official value
Base URL	https://api.meta.ai/v1
Model	muse-spark-1.1
Context window	1,048,576 tokens
Auth	Bearer token (MODEL_API_KEY)

Merits of the argument. Tri-format support lowers lock-in for mixed fleets (Codex-style Responses in one repo, Claude Code Messages in another). Docs warn that reasoning continuity requires include: ["reasoning.encrypted_content"] on OpenCode-style setups; skipping that is a silent quality regression in multi-turn tool loops.

Pricing and rate limits

Pay-as-you-go USD · no long-context premium on listed rates

Meta bills per token with no minimum commitment. Listed rates (public preview) are $1.25/M input, $0.15/M cached input, and $4.25/M output. Search grounding adds $2.50 per 1,000 queries on top of token charges. Meta explicitly states there is no long-context premium on the published per-token rates.

Meta Model API docs (client-rendered) list $1.25/M input, $0.15/M cached input, and $4.25/M output, and state there is no long-context premium on those listed per-token rates. Confirm on the live pricing page before budgeting 1M-context agent fleets.

Merits of the argument. For 1M-context agent runs, flat pricing simplifies forecasting versus vendors that surcharge long prompts. You still pay for filled context on every turn unless prompt caching hits; monitor cached_tokens in responses.

Failure cases in agent deployments

Preview API, reasoning replay, and computer-use scope

• Public preview instability. Preview APIs can change rate limits, features, or pricing; pin versions in runbooks and expect changelog drift.
• Broken reasoning replay. Multi-step agents without encrypted reasoning carry-over re-plan from scratch each turn (documented OpenCode tradeoff).
• Computer-use overreach. Models trained for desktop automation may script when a direct click is safer; constrain tools in production.
• Partner quotes ≠ your eval. CEO testimonials on the release blog are marketing signal, not your SOC2 agent scorecard.

Migration: wire your harness in two steps

Dashboard key → provider block → muse-spark-1.1

Official flow: create MODEL_API_KEY, export it, then register a provider with base URL https://api.meta.ai/v1 and model muse-spark-1.1. OpenCode users can paste Meta’s documented provider block (Responses API via @ai-sdk/openai) including reasoning settings and 1,048,576 context limit.

curl -X POST "https://api.meta.ai/v1/responses" 
  -H "Authorization: Bearer $MODEL_API_KEY" 
  -H "Content-Type: application/json" 
  -d '{
  "model": "muse-spark-1.1",
  "input": "What is the capital of France?"
}'

When Muse Spark 1.1 is actually fine

Multimodal agents with existing OpenAI-shaped code

• Greenfield agent stacks already on OpenAI SDK or Vercel AI SDK where swapping base URL is low risk.
• Workflows needing image, PDF, or video in the same agent loop as tool calls (modalities documented in OpenCode config).
• Internal coding agents where Meta Internal Coding Bench directionally matches your repo scale (validate locally).

What to check right now

Checklist before production routing

1. Confirm preview ToS and data handling for your compliance tier.
2. Enable reasoning replay settings if your harness uses multi-turn tools.
3. Benchmark muse-spark-1.1 vs your incumbent on 50 real tickets (coding + tool-heavy).
4. Track cached vs uncached input tokens for cost forecasts.
5. Set RPM/TPM backoff (docs recommend exponential backoff with jitter on 429).

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Meta – Introducing Muse Spark 1.1 – model capabilities, Meta Model API public preview, agentic/computer-use positioning
• Meta Model API – Overview – base URL, model id, context window, SDK compatibility
• Meta Model API – Pricing and rate limits – $1.25 / $0.15 / $4.25 per 1M tokens, search grounding surcharge, rate limits

nJoy 😉

Grok 4.5 lands with a story that is easy to misread. The headline is not “another frontier model” but “a coding model trained with your editor vendor in the loop, priced at $2/$6 per million tokens, and marketed on token efficiency rather than raw benchmark bragging.” If you run agentic coding in Cursor or Grok Build, the operational question is whether the ~2× token-efficiency claim and 80 TPS serving actually change your cost-per-task math, or whether you are still paying for long reasoning traces on hard SWE work.

What Grok 4.5 actually is

SpaceXAI’s default for coding, agents, and knowledge work · not a general chat refresh

SpaceXAI positions Grok 4.5 as its strongest model for real engineering: coding, multi-step agentic work, and knowledge tasks. The release is explicit that training happened alongside Cursor, which matters for harness fit even if it does not guarantee your repo’s edge cases are covered.

“Grok 4.5 is SpaceXAI’s smartest model built for coding, agentic tasks, and knowledge work.” – SpaceXAI, Introducing Grok 4.5

“Grok 4.5 was trained alongside Cursor.” – SpaceXAI, Introducing Grok 4.5

Merits of the argument. Co-training with a major coding harness is a credible signal for tool-use and edit-loop behaviour, not just leaderboard scores. SpaceXAI also publishes DeepSWE figures (66.1% pass@1 on DeepSWE 1.0 in their chart) with a note that competitor numbers come from developers’ own harnesses. Treat that as directional until you rerun on your stack.

Speed, token efficiency, and the real bill

80 TPS and fewer output tokens per SWE task · sticker price is only half the story

Two numbers drive operator economics here: throughput and tokens consumed per task. SpaceXAI claims fast-model serving at 80 tokens per second (TPS) and roughly double the token efficiency of comparable leading models on the same tasks, illustrated on SWE Bench Pro average output tokens.

“Grok 4.5 is served at fast-model speeds of 80 TPS.” – SpaceXAI, Introducing Grok 4.5

“Grok 4.5 is priced at $2 per million input tokens and $6 per million output tokens. The model also achieves roughly 2x the token efficiency of comparable leading models, solving tasks in under half the number of steps.” – SpaceXAI, Introducing Grok 4.5

Merits of the argument. Cost-per-task routing (see our Kimi K3 cost-per-task dossier) applies here: if output tokens halve on your SWE harness, effective output cost drops toward $3/M equivalent even at the listed $6/M rate. You still need to meter thinking traces, retries, and failed tool loops on your workloads.

Metric	Grok 4.5 (official)	What to verify locally
Input price	$2 / 1M tokens	Prompt caching behaviour on your harness
Output price	$6 / 1M tokens	Mean output tokens per merged PR or ticket
Model ID	grok-4.5	Cursor plan vs SpaceXAI console vs Grok Build
Throughput claim	80 TPS	p95 latency under parallel agent workers

Where Grok 4.5 ships today

Grok Build, Cursor, and the SpaceXAI console · one model id across surfaces

Availability is intentionally broad: Grok Build as default, Cursor on all plans, and the SpaceXAI API with model id grok-4.5. SpaceXAI offered limited-time free usage in Grok Build and Cursor at launch; treat promos as time-boxed, not architectural.

“Grok 4.5 is available today in Grok Build, in Cursor on all plans, and from the SpaceXAI console.” – SpaceXAI, Introducing Grok 4.5

Merits of the argument. Same model id across editor and API reduces migration friction. The risk is organisational: teams standardise on Cursor’s Grok default without benchmarking against their existing router (Kimi K3, DeepSeek V4 Flash, Muse Spark, etc.) on ticket mix.

Failure cases that show up in production

When co-trained hype meets messy repos

• Benchmark harness ≠ your monorepo. DeepSWE gains may not transfer if your agent lacks the same tool budget, sandbox, or test oracle.
• Token efficiency claimed on SWE Bench Pro. Frontend polish, Excel modelling, or Office plugin workflows have different token profiles; do not extrapolate the 2× figure blindly.
• Free-period routing debt. Teams that default Grok 4.5 during a promo may forget to re-benchmark when billing normalises.
• Single-model Cursor default. Hard jobs still belong on a stronger reasoning tier if your eval shows regressions on security or multi-file refactors.

Migration and integration

Point API clients at grok-4.5 · keep harness instrumentation

For direct API use, SpaceXAI documents the Responses-style endpoint with model grok-4.5. In Cursor, select Grok 4.5 as the model and keep your existing agent rules (AGENTS.md, tool permissions). Log input/output tokens per task for two weeks before changing fleet-wide defaults.

curl -s https://api.x.ai/v1/responses 
  -H "Authorization: Bearer $XAI_API_KEY" 
  -H "Content-Type: application/json" 
  -d '{
    "model": "grok-4.5",
    "input": "Find and fix the bug, then explain it: function median(a){a.sort();return a[a.length/2]}"
  }'

When Grok 4.5 is actually fine

High-volume coding agents with measurable token budgets

• Daily agentic coding where output token volume dominates cost and SWE-style tasks match the published efficiency story.
• Teams already on Cursor who want one fewer API vendor for the default model.
• Knowledge-work flows inside Grok Build (Excel, PowerPoint, Word plugins) where the product surface, not raw API, is the integration point.

What to check right now

Operator checklist before you flip the default

1. Record baseline cost-per-merged-fix for your current default model (7-day sample).
2. Run the same ticket sample on grok-4.5 with identical tool and timeout settings.
3. Compare mean output tokens, p95 latency, and pass rate on your internal eval set.
4. Confirm billing path (Cursor included vs SpaceXAI API metered).
5. Document fallback model for tasks where Grok 4.5 regresses (security review, rare languages).

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• SpaceXAI – Introducing Grok 4.5 – pricing ($2/$6 per 1M), 80 TPS, token efficiency, Cursor co-training, availability, model id grok-4.5
• sudoall.com – Kimi K3 cost-per-task routing – cost-per-task framing for agent fleets

nJoy 😉

Anthropic’s June-July 2026 release wave is not three unrelated model drops. It is a deliberate split: Sonnet 5 as the default agentic workhorse with cyber safeguards on, Fable 5 as Mythos-class capability wrapped in classifier fallbacks for general users, and Mythos 5 as the same weights with safeguards lifted for trusted defenders. The hype mistake is treating “most agentic Sonnet” and “strongest cyber model” as one product decision. They are opposing deployment postures on a shared capability frontier.

Sonnet 5: the agentic workhorse

BrowseComp · OSWorld-Verified · intro pricing · cyber safeguards default

Claude Sonnet 5 is positioned as the most agentic Sonnet yet: planning, browsers, terminals, and sustained autonomous runs at a price point closer to Opus 4.8 than previous Sonnets. Anthropic reports strict improvement over Sonnet 4.6 on agentic search and computer use across effort levels, with cost-performance curves that sometimes match Opus 4.8 on selected tasks.

“Claude Sonnet 5 is built to be the most agentic Sonnet model yet. It can make plans, use tools like browsers and terminals, and run autonomously at a level that, just a few months ago, required larger and more expensive models.” – Anthropic, Introducing Claude Sonnet 5

Pricing is explicitly time-boxed: $2 per million input tokens and $10 per million output through 31 August 2026, then $3/$15. Anthropic notes an updated tokenizer can map the same text to roughly 1.0–1.35× more tokens, with introductory pricing intended to keep migration roughly cost-neutral. Sonnet 5 is default on Free and Pro; available on Max, Team, and Enterprise; API id `claude-sonnet-5`.

“From today, Claude Sonnet 5 is available across all plans: it is the default model for Free and Pro plans, and is available to Max, Team, and Enterprise users. It’s also available in Claude Code and on the Claude Platform, where it launches with introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026, after which it will be priced at $3 per million input tokens and $15 per million output tokens.” – Anthropic, Introducing Claude Sonnet 5

Safety posture differs from Mythos-class releases. Anthropic did not deliberately train Sonnet 5 on cybersecurity tasks. It shows substantially poorer dangerous cyber performance than Opus 4.8 and Mythos 5 on Firefox exploit development evals (0% full exploits for Sonnet models). Because Sonnet 5 is somewhat stronger than Sonnet 4.6 on partial cyber tasks, it launches with cyber safeguards enabled by default, using the same real-time blocking stack as Opus 4.7/4.8, less strict than Fable 5’s launch safeguards.

“Since Sonnet 5 is somewhat stronger than its predecessor on these tasks, we’ve launched it with cyber safeguards enabled by default.” – Anthropic, Introducing Claude Sonnet 5

For teams building everyday agents, Sonnet 5 is the sensible default in Anthropic’s stack: strong tool follow-through, lower tariff than Opus, safeguards on. Route heavy cyber work to Opus 4.8 with Cyber Verification Programme access, not to Sonnet with safeguards disabled (you cannot). This aligns with tiered routing in LLM routing by task complexity and cost-aware orchestration in cost-per-task harness design.

Merits of the argument. Anthropic’s own evals show Sonnet 5 narrows the Opus gap on agentic tasks without matching Mythos cyber ceilings. The tokenizer caveat is load-bearing for budgets: “$2/$10” is not automatically cheaper per real prompt. The cyber safeguard default is credible given partial-success upticks. Weak spot: introductory pricing ends 31 August 2026; architecture decisions should use post-intro $3/$15 for steady-state TCO.

Fable and Mythos: one model, two postures

Mythos-class · Project Glasswing · classifier fallback · trusted access

Claude Fable 5 and Claude Mythos 5 share one underlying model. Fable 5 is “a Mythos-class model that we’ve made safe for general use” with safeguards that route some cyber, bio/chem, and distillation-flagged requests to Opus 4.8 instead of refusing outright. Mythos 5 is the same weights with cyber safeguards lifted for Project Glasswing partners and expanding trusted access. Footnote naming: Fable from Latin fabula (“that which is told”); Mythos from Greek mythos; safeguards are the product difference.

“Releasing a model this capable comes with risks.” – Anthropic, Claude Fable 5 and Claude Mythos 5

“For a small group of cyberdefenders and infrastructure providers, we’re also launching Claude Mythos 5. It’s the same underlying model as Fable 5, but with the safeguards lifted in some areas.” – Anthropic, Claude Fable 5 and Claude Mythos 5

Fable 5 pricing is $10/$50 per million tokens (under half Mythos Preview pricing). Anthropic states safeguards trigger on average in less than 5% of sessions, with more than 95% of sessions seeing no Opus fallback, but deliberately conservative tuning causes false positives on benign cyber-shaped requests. Mythos 5 is described as the strongest cybersecurity model Anthropic offers, deployed first through Glasswing with US government collaboration.

Merits of the argument. The dual-use split is explicit in primary sources, not analyst inference. Fallback-to-Opus is a product choice to avoid hard refusals whilst limiting Mythos uplift in general chat. Risk: users experience “Fable” branding but sometimes get Opus behaviour without noticing the swap. Mythos access remains gated; do not architect consumer features on Mythos assumptions.

Redeployment, export controls, and safeguard iteration

June 12 suspension · Amazon bypass report · classifier patch · industry jailbreak framework

Fable 5 and Mythos 5 launched 9 June 2026. Access suspended 12 June after US export controls required restricting foreign nationals; Anthropic could not verify nationality in real time. Export controls lifted 30 June; global Fable access restored 1 July with Mythos restored for approved US Glasswing organisations. Parallel safeguard work: Amazon researchers reported a bypass where Fable identified vulnerabilities and, in one case, produced exploit demonstration code. Anthropic tested and found many less capable models could identify the same vulnerabilities; all tested models could produce the same demonstration. They judged the technique a borderline false-positive case, not unique Mythos-level uplift, but still shipped an improved classifier blocking the specific technique in over 99% of cases.

Anthropic’s redeployment post outlines defence-in-depth: training refusals, retroactive misuse analysis, and classifiers with an enlarged “safety margin” that blocks ambiguous cyber requests (row B vs row A in their diagram). Minor jailbreaks may intrude into the safety margin without reaching core harmful behaviours; universal jailbreaks remain the top concern. They propose an industry jailbreak severity framework (capability gain, breadth, ease of weaponisation, discoverability) with Amazon, Microsoft, Google, and Glasswing partners, plus deeper US government pre-release testing.

Merits of the argument. The timeline shows capability launches and governance can collide in the same week. The Amazon bypass was real enough to trigger export controls and classifier retraining, yet Anthropic’s comparative testing downgrades its uniqueness. Operators should treat Fable as high-capability with noisy guardrails, not as “safe because renamed.” For multi-agent stacks, coordinator models must handle fallback notifications and session continuity when classifiers route to Opus; see multi-agent coordination.

Named failure cases

Failure mode	What goes wrong	Mitigation
Assuming Sonnet 5 equals Mythos for cyber	Team picks Sonnet for purple-team automation; hits safeguards or lacks exploit depth	Use Cyber Verification / Opus 4.8 for reduced-guardrail cyber; Mythos only via trusted programmes
Ignoring tokenizer inflation	Budget model built on old Sonnet token counts; August intro expiry surprises finance	Re-benchmark prompts on Sonnet 5 tokenizer; plan at $3/$15 from September
Fable fallback blindness	Users think Fable solved a cyber-shaped task; Opus actually responded	Surface Anthropic fallback notices in logs; tag traces with effective model id
False positive frustration	Legitimate defensive cyber queries fall back or block under conservative classifiers	Apply trusted access programmes; document retry paths; expect iterative narrowing per Anthropic
Single-model agent default	Running Fable for all agent steps when Sonnet 5 suffices at half the tariff	Route planner/worker tiers; Fable only when long-horizon or specialist evals justify cost
Export-control surprise	Global team assumes Mythos/Fable availability; access suspended without nationality verification	Track model availability by region and plan; maintain Sonnet/Opus fallbacks in manifest

Migration steps

1. Default new agent workloads to Sonnet 5 on Claude Code, Platform, and API where Opus was overkill for cost.
2. Re-run token and cost baselines on representative prompts with Sonnet 5 tokenizer; compare intro vs post-August pricing.
3. Reserve Fable 5 for long-horizon coding, research, and vision-heavy tasks where partners report step-change gains; monitor fallback rates in logs.
4. Keep Mythos/Fable cyber split explicit in security architecture: consumer paths on Fable with safeguards; defensive cyber on Mythos/Glasswing or Opus CVP only.
5. After Amazon-class bypass news, retest any automation that depended on borderline cyber-shaped Fable behaviours; expect stricter classifier hits.
6. Implement model routing tables aligned with sudoall cost-per-task patterns: Sonnet for volume agents, Fable for frontier sessions, Opus/Mythos for verified cyber lanes.

When it is actually fine

Sonnet-only shops · Fable without cyber prompts · Opus for cyber CVP

Stay on Sonnet 4.6 or Opus only when: you have not revalidated prompts on Sonnet 5 tokenizer; your workload is short non-agent chat; or compliance requires a frozen model id until a formal change window. Using Fable without touching cyber/bio/distillation-shaped prompts is fine for many coding and knowledge tasks; Anthropic reports >95% of sessions without fallback. Using Opus 4.8 for cyber with Cyber Verification is fine and Anthropic’s own recommendation over disabling Sonnet safeguards. Mythos is not fine for general product features; it is fine inside approved defender programmes.

What to check right now

• Which Claude model id is your agent default today? Should it be `claude-sonnet-5`?
• Have you measured token count delta on top 20 production prompts vs Sonnet 4.6?
• Do logs record when Fable requests fall back to Opus 4.8?
• Is any workflow assuming Mythos availability outside Glasswing/trusted access?
• Calendar reminder: 31 August 2026 intro pricing expiry for Sonnet 5 TCO review.
• For cyber automation, is Cyber Verification Programme enrollment documented with Opus 4.8 as the reduced-guardrail path?
• Multi-agent orchestrators: do sub-agents use mixed tiers or one expensive model for all roles?

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Anthropic – Introducing Claude Sonnet 5 (30 Jun 2026) – agentic positioning, intro $2/$10 through 31 Aug 2026 then $3/$15, cyber safeguards default, Firefox exploit eval comparison, tokenizer note
• Anthropic – Claude Fable 5 and Claude Mythos 5 (9 Jun 2026) – dual-use split, $10/$50 pricing, classifier fallback behaviour, Glasswing/Mythos access, safeguard coverage
• Anthropic – Redeploying Fable 5 (30 Jun 2026) – export control timeline, Amazon bypass report response, >99% classifier block rate, jailbreak severity framework, government collaboration
• sudoall – Kimi K3 cost-per-task routing harness – cost-per-task orchestration economics
• sudoall – LLM routing by task complexity – tier selection for agent roles
• sudoall – Multi-agent coordination 2026 playbook – multi-model agent coordination and fallback handling

nJoy 😉

Google’s Gemini 3.6 Flash launch is not another leaderboard flex. It is a pricing memo dressed as a model card: agent economics are won on output tokens per task, tokens per second at the leaf tier, and whether your orchestrator stops paying flagship prices for sub-agent busywork. Benchmarks still matter for capability floors. In production agents, token efficiency is the product.

3.6 Flash: fewer tokens, lower tariff

Artificial Analysis Index · DeepSWE · GDPval-AA v2 · $/MTok

Gemini 3.6 Flash is explicitly framed as the workhorse for coding, knowledge work, and multimodal agent loops. Google cites Artificial Analysis Index data showing 17% fewer output tokens than 3.5 Flash on aggregate, with DeepSWE (Datacurve) showing up to 65% reduction in some cases, plus fewer reasoning steps and tool calls on multi-step workflows. That is not a cosmetic tweak. If your agent bill is dominated by output tokens on tool-heavy graphs, a mid-teens efficiency gain compounds across every sub-call.

“For example, on the Artificial Analysis Index, we see 3.6 Flash consuming 17% fewer output tokens than 3.5 Flash.” – Google, Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber

Pricing reinforces the story: $1.50 per million input tokens and $7.50 per million output tokens, lower than 3.5 Flash on both sides. Google reports gains on DeepSWE (49% vs 37%), MLE Bench (63.9% vs 49.7%), OSWorld-Verified (83.0% vs 78.4%), and GDPval-AA v2 (1421 vs 1349). Computer use is now a built-in client-side tool via the Gemini API and Gemini Enterprise, which matters for agents that previously paid orchestration tax wrapping brittle UI automation.

“At $1.50/1M input tokens and $7.50/1M output tokens, 3.6 Flash reduces the overall cost per agentic task, making agents more cost-effective to build and run.” – Google, Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber

Merits of the argument. Google ties efficiency claims to named benchmarks and a public price sheet, not vibes. The 17% AA Index figure is an aggregate; workload-specific wins (DeepSWE up to 65%) will not transfer uniformly to your stack. Still, pairing lower $/output with fewer outputs is the correct lever for agent TCO. This is the same operational frame as cost-per-task routing: sticker $/MTok misleads; cost per completed task is the metric that survives finance review.

3.5 Flash-Lite: throughput for the leaf tier

350 tok/s · thinking levels · sub-agent fan-out

Flash-Lite targets high-volume, high-throughput agentic search, document processing, and sub-agent fan-out. Artificial Analysis measures 350 output tokens per second. Pricing is $0.30 per million input and $2.50 per million output, with Google claiming large jumps over 3.1 Flash-Lite on Terminal-Bench 2.1 (54% vs 31%), GDM-MRCR v2 (72.2% vs 60.1%), and GDPval-AA v2 (1140 vs 642). On several agentic and coding evals, Google states 3.5 Flash-Lite even beats 3 Flash, including SWE-Bench Pro (54.2% vs 49.6%) and OSWorld-Verified (74.0% vs 65.1%).

“Priced at $0.3/1M input tokens and $2.5/1M output tokens and with significantly better quality than 3.1 Flash-Lite, 3.5 Flash-Lite offers a strong price-to-performance ratio for developers and customers running high throughput production traffic.” – Google, Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber

Google’s own examples show the pattern: 3.6 Flash as master agent, Flash-Lite instantly generating 25 web design concepts, or scaling receipt translation. That is textbook tiered orchestration from routing by task complexity: one planner with strong tool discipline, many cheap parallel workers with configurable thinking levels (minimal/low for latency, higher for multi-step subagents).

Merits of the argument. Throughput and price are verifiable product claims; benchmark deltas are vendor-selected. Flash-Lite is not a substitute for 3.6 Flash on hard migration or precision coding; Google positions it as scale tier. The mistake is running everything on 3.6 because it is “best,” or everything on Lite because it is cheap. The win is explicit routing.

3.5 Flash Cyber and the dual-use split

CodeMender · CyberGym · government and trusted partners only

Flash Cyber is fine-tuned from 3.5 Flash for vulnerability find-and-fix at lower cost per token than larger models, deployed inside CodeMender with multiple agents producing a combined report. CyberGym scores are cited as competitive at the frontier. Access is deliberately narrow:

“Given the dual-use nature of this technology, we have taken an intentional approach to deploying 3.5 Flash Cyber. The model will be exclusively available to governments and trusted partners via CodeMender soon as part of a limited-access pilot program.” – Google, Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber

3.6 Flash ships with enhanced Frontier Safety safeguards on CBRN and cyber offence misuses, trained to resist jailbreaks whilst minimising refusals on beneficial uses. General developers get safer workhorse models; cyber-offence-shaped capability is gated, not sprinkled into the default API tier.

Merits of the argument. Google mirrors the industry split between general agent stacks and trusted cyber programmes. Flash Cyber is irrelevant to most product teams today, but it signals where Google thinks efficiency gains will also appear in security automation. Do not plan production architecture assuming Cyber API access; plan assuming CodeMender-style partnership gates.

Named failure cases

Single-model agents · ignoring thinking levels · benchmark tourism

Failure mode	Symptom	Fix
Monolithic 3.6 everywhere	High-quality outputs on trivial subtasks; bill looks like flagship routing	Route leaf tasks to Flash-Lite with minimal thinking; reserve 3.6 for planner/reviewer roles
Lite for everything	Cheap runs that loop on tool errors or miss long-context structure	Promote failed subtasks to 3.6; cap Lite to bounded prompts with schema outputs
Sticker $/MTok budgeting	Finance approves Lite pricing; ops sees 4× output tokens on verbose agents	Track cost per task with AA-style output token counts; see sudoall cost-per-task routing
Ignoring thinking level knobs	Paying high-reasoning latency on bulk extraction	Map thinking levels to task classes; document defaults in agent manifest
Benchmark-driven model pick	Choosing 3.6 because DeepSWE headline without measuring your tool graph	Run 50–100 production traces; compare output tokens and success rate, not leaderboard rows alone
Assuming Flash Cyber in prod	Architecture depends on vuln-hunting model users cannot access	Separate red-team/purple-team pipeline with explicit trusted access; keep app tier on 3.6/Lite

Migration steps

1. Baseline current agent spend by role (planner, worker, reviewer) using last 30 days of traces. Split input vs output tokens.
2. Promote planner/reviewer to 3.6 Flash on Gemini API or Enterprise; enable computer use only where UI automation is load-bearing.
3. Move fan-out workers to 3.5 Flash-Lite with minimal or low thinking for search, summarisation, and parallel ideation.
4. Implement retry escalation: Lite failure or tool-loop threshold triggers 3.6 re-run with tighter instructions (pattern from multi-agent playbooks in multi-agent coordination).
5. Re-measure output tokens per successful task after two weeks; compare to pre-migration, not to Google’s benchmark table.
6. Track Gemini 4 pretraining note as planning horizon only. Google states its “most ambitious pre-training run yet” for Gemini 4 is underway; do not defer migration waiting for it. Efficiency discipline compounds now.

When it is actually fine

Low-volume prototypes · single-step tools · non-agent chat

Staying on one Flash tier is reasonable when: traffic is low enough that routing complexity exceeds savings; tasks are single-shot without tool graphs; or you are still proving product fit and need one model ID for simpler telemetry. Flash-Lite alone is fine for batch document pipelines with fixed schemas and no planner. 3.6 alone is fine for small teams running dozens of agent sessions daily, not thousands.

Google also notes 3.5 Pro testing with partners and Gemini 4 pretraining in parallel. None of that invalidates shipping tiered Flash routing today.

What to check right now

• Pull output tokens per successful agent task for your current default Gemini model.
• Identify sub-agent calls that never need computer use or high thinking; candidate list for Flash-Lite.
• Confirm Gemini API model IDs and thinking level parameters in your orchestrator manifest.
• Compare $7.50/MTok 3.6 output vs $2.50/MTok Lite on your top five recurring workflows with real prompts.
• If cyber automation is in scope, verify whether you are in CodeMender trusted access; if not, remove Flash Cyber from architecture diagrams.
• Read 3.6 Flash and 3.5 Flash-Lite model cards for safety/refusal changes that affect your domain (finance, health, code execution).

Sources and references

Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.

• Google – Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (21 Jul 2026) – pricing, AA Index 17% output token reduction, 350 tok/s Flash-Lite, CodeMender/Flash Cyber access model, Gemini 4 pretraining note, benchmark tables
• sudoall – Kimi K3 cost-per-task routing harness – cost-per-task vs sticker token pricing
• sudoall – LLM routing by task complexity – planner/worker tier selection
• sudoall – Multi-agent coordination 2026 playbook – orchestration, escalation, and containment patterns

nJoy 😉