a quiet day.

AI News for 8/12/2026-8/13/2026. We checked 12 subreddits, 544 Twitters and no further Discords. AINews’ website lets you search all past issues. As a reminder, AINews is now a section of Latent Space. You can opt in/out of email frequencies!

AI Twitter Recap

Gemini 3.7 Flash Release and the New Mid-Tier Price/Performance Frontier

• Google’s rapid Flash iteration: Google shipped Gemini 3.7 Flash just three weeks after 3.6 Flash, positioning it as its new workhorse for coding, web development, knowledge work, and agentic workflows. Launch posts emphasize materially stronger coding and autonomy benchmarks plus an introductory 50% price cut through end of year: $0.75 / $3.75 per 1M input/output tokens, rising later to $1.50 / $7.50 per 1M. Reported deltas include DeepSWE 65.3% vs 49.0%, FrontierCode 43.6% vs 34.4%, AutomationBench 30.4% vs 17.0%, and Code Arena Elo 1588 vs 1506/1538 depending on comparison context (Google, @GoogleDeepMind, @OfficialLoganK, @_philschmid, @koraykv).
• Ecosystem rollout was immediate: 3.7 Flash landed across Gemini API, AI Studio, Android Studio, Antigravity, Gemini Enterprise, Managed Agents, Gemini Spark, and quickly propagated into external tooling such as Cline, Devin, VS Code Agents, and other coding stacks (GoogleAIStudio, GeminiApp, code, cognition, cline).
• Independent and semi-independent benchmarking broadly confirmed the jump: Artificial Analysis placed Gemini 3.7 Flash (high) at 56 on its Intelligence Index, a 4-point gain over 3.6 Flash, with ~340 output tok/s, 1M context, and positioning on both intelligence-vs-time and intelligence-vs-cost Pareto frontiers. Arena updates similarly moved it to #8 WebDev Code Arena, #9 Text Arena, and materially up in Agent Arena (Arena, Arena text, Arena agent). Practitioners also highlighted better “discipline” in tool loops: more exploration, more test-running, fewer wasted turns (@_philschmid).

Harnesses, Agent Runtimes, and Long-Running Autonomy

• DeepSeek Harness was the day’s most discussed infra release: DeepSeek open-sourced DeepSeek Harness under MIT as a developer preview (@tianyi). The strongest technical reactions focused less on benchmark scores and more on architecture: multiple harness “modes,” composable plugins, visible trajectories, KV-cache-aware append-only history semantics, and evidence that the project itself was heavily built with agents/Codex (@eliebakouch, follow-up, @bookwormengr). A recurring interpretation was that DeepSeek is treating the harness as an OS/runtime substrate for recursive improvement, not just a Claude Code clone (@0xLogicrw, @teortaxesTex).
• Arcee’s NAC broadened the design space: Arcee open-sourced NAC under Apache 2.0, describing it as an internal harness for long-running, asynchronous, hands-off work that has already powered a significant fraction of code committed to its pretraining, post-training, and data pipelines over the last three months (@latkins, repo). Team members described using NAC for everything from babysitting experiments to cross-repo engineering and auto-research-shaped tasks, often orchestrated from phones or delegated from Codex/Claude via MCP (@stochasticchasm, @code_star, @fujikanaeda).
• Managed and desktop harnesses continue to converge toward production workflows: Cursor announced builds that make cloud agents start 3x faster, fail over to the last good build, and improve resilience/debuggability for long-running autonomous work (Cursor). LangChain’s recent “managed deep agents” messaging similarly frames production agents as file-defined harnesses with schedules, memory, Slack integrations, and governed runtime semantics rather than ad hoc chatbots (@hwchase17, @bromann, @caspar_br).
• Nous keeps expanding Hermes as a programmable agent shell: Nous massively expanded the Hermes Agent plugin surface, then added live sub-agent steering/transcripts and a Bot Mode where profiles become named bots with their own chats, routines, memory, SOUL.md, and bot-to-bot messaging (@Teknium, live transcript control, bot mode).

Inference Speed, Speculative Decoding, and Kernel-Level Optimization

• OpenAI + Cerebras introduced GPT-5.6 Sol “Ultrafast”: OpenAI previewed Ultrafast mode for GPT-5.6 Sol, powered by Cerebras, at up to 750 tokens/sec and 14x faster than standard mode, initially for a select set of API customers. Use cases called out were low-latency voice, support, commerce, coding, finance, and security workflows (OpenAI, details, Cerebras). This triggered a broader discussion that tool latency, not model latency, is about to become the bottleneck in agentic systems (@random_walker).
• Open-source inference work kept pace: Red Hat AI released DSpark, a speculator for Kimi-K3, claiming ~4x faster decoding, from roughly 110 tok/s/user to ~435 tok/s/user on math reasoning, with ~3.5x throughput under load and stable acceptance to 20K context via sliding-window attention across draft layers (@RedHat_AI).
• Kernel work is getting more specialized: Prime Intellect released Prime Flash MoE, a set of Blackwell-optimized CUDA kernels for MoE inference that fuse routing-aware GEMMs, SwiGLU, quantization, and reductions, with both BF16 and MXFP8 paths benchmarked on B200s (Prime Intellect). The significance is straightforward: as labs ship ever-cheaper MoE endpoints, infra teams are competing aggressively on the serving stack beneath them.

Benchmarks, Eval Platforms, and What They’re Actually Measuring

• Custom benchmark infrastructure is becoming a product category: Artificial Analysis launched Optima, a platform for building and running custom benchmarks on internal workloads, including uploaded datasets, agent traces from tools like Arize/Braintrust/Langfuse, or benchmark generation from natural-language descriptions. It tracks quality, cost per task, time per task, and can use pairwise judging similar to AA’s public benchmarks (Artificial Analysis). The pitch is that enterprises know they need custom evals, but very few can build them well (@grmcameron).
• Vals raised a $40M Series A and expanded benchmark coverage: Vals announced a $40M Series A at a $400M valuation, alongside Vals Smith for custom coding benchmarks from any GitHub repo, a new RSI Index for AI R&D capability, and ReverseEngBench for cyber evaluation (Vals AI, RSI commentary). The core argument is familiar but increasingly important: model labs shouldn’t be the only ones grading their own systems.
• Several papers pushed on agent eval failure modes: notable summaries included Microsoft-related work arguing that skill libraries can actively hurt agents, attributing 307 failures to loaded skills, including 125 functional failures and 182 efficiency regressions (@omarsar0); a paper showing context compactors retain only 17% of persistent session constraints unless augmented with a dedicated extractor (DAIR.AI); and another arguing leaderboard variance is dominated by agent-task interaction, not stable “agent quality,” with the agent main effect under 3% in multiple benchmarks (DAIR.AI).

Model and Multimodal Releases Beyond Gemini

• MiniMax had a strong open-model day: MiniMax-Music3 launched as an open-weights music model; posts describe it as an 8B LLM + 2.7B DiT that turns prompt + lyrics into full songs and runs on consumer hardware via diffusers/ComfyUI/Hugging Face Spaces (MiniMax AI, @multimodalart). On the video side, MiniMax-H3 reached #1 in Video Edit Arena overall and among open models, with 1390 pts and a reported +32 pt lead over the next-best systems (Arena, MiniMax).
• Meta’s local-agent push kept spreading: Meta’s Muse Glimmer 30B continued to draw attention as an Apache 2.0 open-weights agent model that can run locally; Unsloth added free fine-tuning notebooks and GRPO RL support, claiming 1.5x faster training with 50% less VRAM and local training on 24GB VRAM (Unsloth, Ollama).
• Sakana Chat expanded practical code-execution UX: Sakana updated Sakana Chat—powered by Fugu and Namazu—to support code execution with no login and free access, enabling Japanese-language interactive app/game/tool generation and spreadsheet/business-analysis workflows (Sakana AI Labs, use case).

Top Tweets (by engagement)

• OpenAI’s fastest frontier serving announcement: GPT-5.6 Sol Ultrafast, up to 750 tok/s and 14x speedup, powered by Cerebras (OpenAI).
• Google’s major workhorse refresh: Gemini 3.7 Flash shipped with strong coding/agent gains at half the original 3.6 Flash price (@OfficialLoganK, Google).
• OpenAI desktop memory/context expansion: Computer History lets ChatGPT/Codex use opt-in app and website activity as context, with timeline view and user controls (OpenAI, OpenAIDevs).
• DeepSeek’s agent runtime enters the open: DeepSeek Harness open-sourced under MIT, catalyzing broad discussion about harnesses as the substrate for long-running and self-improving agents (@tianyi).
• Hermes Agent keeps leaning into multi-agent UX: Nous shipped Bot Mode, turning agent profiles into persistent named bots with routines and inter-bot messaging (@Teknium).

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Qwen 3.8 Open Release and Local Inference

• Qwen3.8-2.4T-A95B Released (Activity: 2345): Qwen3.8-2.4T-A95B was announced/released as a very large sparse/MoE-style model: the name implies roughly 2.4T total parameters with about 95B active parameters per token. At bf16, storing all weights would require ~4.8–5 TB of memory/disk, making full local inference impractical for typical home labs despite the much smaller active parameter count. Top commenters focused on deployability: one joked it was “finally” a locally runnable model, while others noted that 5 TB bf16 exceeds even extreme homelab setups; a recurring point was that only the 95B active slice feels plausibly local, not the full model.

  • Technical discussion centered on the model’s deployment footprint: one commenter notes a bf16 checkpoint would be roughly 5 TB, making local inference impractical even for high-end homelabs. Another points out the MoE-style distinction between total and active parameters, joking they could run only the active A95B portion, implying compute per token may be closer to ~95B active params while storage still scales with the full 2.4T parameter model.

• Qwen 3.8 release on hugging face (Activity: 490): Qwen 3.8 was reported as released on Hugging Face, with commenters specifically watching for a 27B variant and noting a much larger 95B active configuration. The main technical concern raised is deployability: even with aggressive quantization such as Q1, a 95B active-parameter model would remain impractical or extremely slow on consumer hardware, while users with GPUs like an RTX 3090 are anticipating the smaller 27B release. Commenters are positive that Qwen “promised” and “delivered,” but there is clear skepticism that the 95B active model is usable locally except in highly constrained, very slow setups.

  • Users highlighted that the release appears to include a very large 95B active-parameter model, with one commenter arguing that even aggressive methods like REAP-style pruning/quantization and extreme Q1 quantization would still leave inference impractically slow due to the active parameter count.
  • Several comments focused on the expected 27B Qwen 3.8 variant on Hugging Face, with users specifically waiting to run it on consumer hardware such as an RTX 3090, implying interest in whether the smaller checkpoint will fit and perform acceptably on 24GB VRAM-class GPUs.

• How do you plan to run Qwen3.8-2.4T-A95B locally? (Activity: 608): The post asks whether and how enthusiasts could run Qwen3.8-2.4T-A95B locally, framing it alongside prior very-large local-inference targets such as Llama-70B, Mistral Large, DeepSeek V2/V3, and Kimi K3. No concrete deployment plan, hardware topology, quantization strategy, or inference stack is provided; the only semi-technical estimate in the top comments suggests an impractically low throughput of roughly 0.003 tokens/s for local execution. Top comments are mostly pessimistic/jokey, implying that practical local inference would require extreme capital expenditure—on the order of “$100k”—or impossible amounts of memory rather than a realistic consumer setup.

  • Commenters were skeptical that Qwen3.8-2.4T-A95B is practical to run locally, implying that the memory/compute requirements for a multi-trillion-parameter MoE-scale model would put it far beyond consumer hardware; one estimate joked it would run at roughly 0.003 tokens/s, highlighting expected severe inference bottlenecks without datacenter-class GPUs.
  • One technically relevant concern was adoption/verification: a commenter noted the Hugging Face upload had fewer than 1000 downloads and was not trending, arguing that with so few users attempting to load or benchmark it, the community may have little practical validation of whether the released artifacts are usable or performant.

2. DeepSeek V4 Pro and Agent Harness Launches

• DeepSeek: We’re launching DeepSeek-V4-Pro today! (Activity: 643): DeepSeek announced DeepSeek-V4-Pro via X, with commenters noting both a new API pricing table and a public weights release on Hugging Face: deepseek-ai/DeepSeek-V4-Pro-0813. The main technical follow-up is that the model appears available for both hosted API use and local/self-hosted inference, but the API cost structure has changed enough to affect workload economics. Commenters were negative on the pricing change: one argued the increase removes DeepSeek’s prior advantage because the models were already “token hungry and a little slower” but acceptable due to low cost, making local deployment more attractive.

  • DeepSeek-V4-Pro weights were reported as released on Hugging Face at deepseek-ai/DeepSeek-V4-Pro-0813, shifting the discussion from API pricing to whether third-party inference providers can host it economically if demand exists.
  • Several commenters focused on API economics: one noted DeepSeek had been acceptable despite being “token hungry and a little slower” because it was cheap, but the new pricing removes that advantage and may push users back to local inference or alternative providers.
  • One early user disputed DeepSeek’s claimed parity with Kimi 3, saying DeepSeek-V4-Pro does not match Kimi’s apparent knowledge depth or ability to sustain long, hands-off project work over extended contexts.

• deepseek-ai/DeepSeek-V4-Pro-0813 · Hugging Face (Activity: 594): DeepSeek briefly published deepseek-ai/DeepSeek-V4-Pro-0813 on Hugging Face, with commenters citing unusually strong reported benchmarks for a 1.7T-parameter model versus e.g. Kimi’s 2.8T; one highlighted DeepSWE jumping from 12.8 in V4-Pro Preview to 62.7, reportedly ahead of GLM-5.2 and Opus-4.8. The repo temporarily returned 404/private, apparently due to a packaging/config issue: config.json reportedly declared 43 hidden layers like a “flash” variant, while downloaded weight shards contained 61 layers, suggesting the release may have been pulled for correction before reappearing. Commenters were impressed by the speed and benchmark gains, but some urged caution because the initial Hugging Face artifact appeared internally inconsistent and may have required fixes.

  • A commenter highlighted that DeepSeek-V4-Pro-0813 appears unusually strong for a 1.7T parameter model compared with Kimi’s 2.8T model, citing a large benchmark jump over V4-Pro Preview: DeepSWE 12.8 → 62.7, reportedly surpassing GLM-5.2 and Opus-4.8.
  • Several users observed the Hugging Face model briefly returned 404, with one technical explanation that DeepSeek may have pulled it due to a bad config.json: the config reportedly listed 43 hidden layers like the Flash version, while the downloaded weight shards contained 61 layers, suggesting a packaging/configuration mismatch requiring correction.

• Deepseek Harness is Up! (Activity: 373): DeepSeek AI announced DeepSeek Harness (dsh), an open-source agent harness in developer preview built around an “everything is a plugin” architecture and powered by Cordis, referencing the design from A Programming Paradigm for Spatiotemporal Composability. The project is explicitly unstable—“THERE WILL BE COMPATIBILITY-BREAKING CHANGES”—and directs developers to the DeepSeek Harness Discord; no benchmarks, implementation details beyond the plugin/Cordis model, or API stability guarantees were provided. Top comments were skeptical of the project’s rapid popularity, with one user alleging bot-driven GitHub stars after seeing 20k→30k stars in about an hour. Other technical reactions questioned the apparent TypeScript implementation trend for agent harnesses and asked whether dsh can achieve better cache hit rates than Reasonix.

  • A commenter raises an implementation concern that most agent/harness projects appear to be written in TypeScript, contrasting this with Codex as a possible exception. The technical implication is skepticism about runtime/ecosystem choices for a coding harness, though no concrete benchmark or failure mode is provided.
  • One technical question asks whether DeepSeek Harness can achieve better cache hit rates than reasonix, noting that cache efficiency is increasingly important for agentic coding workloads where repeated context/tool calls can dominate cost and latency.
  • The linked release materials are the GitHub repo deepseek-ai/deepseek-harness and product page deepseek.com/harness/en/, but commenters note that the announcement lacks detailed technical documentation or benchmark data.

3. LLM Transparency: Watermarking and Reasoning-Trace Leaks

• Hidden Reasoning from Claude and GPT are Decoded, and it is interesting (Activity: 447): A cited paper, “Stealing Reasoning Traces from Proprietary LLM APIs”, claims an API-side leakage method can recover hidden reasoning tokens from Claude and GPT models, with published examples in mitkox/stolen-thoughts. The post highlights an AIME example where a decoded Claude trace appears to recognize a benchmark item from memory — “This is a known AIME problem. Answer 60” — raising concerns about benchmark contamination and inflated proprietary-model math scores; commenters also link a related discussion on X/Twitter mirror. The main debate is whether frontier-model reasoning traces reveal any hidden algorithmic “secret sauce”: the poster argues they mostly show ordinary artifacts like memorization, incoherent intermediate tokens, and overthinking, implying open-source models may be closer than benchmark gaps suggest. There is also speculative concern that such leakage may have enabled large-scale distillation of proprietary models and that closing the gap could slow future distillation efforts.

  • A linked repo, mitkox/stolen-thoughts, is referenced as evidence around “decoded” hidden reasoning traces from closed models. The quoted trace is technically interesting because it appears to expose internal chain-of-thought-style behavior including problem recognition, partial memorization of an AIME problem, intermediate geometry computations such as AC = 7√3 and AD = 13√3, and uncertainty/self-correction around the final answer.
  • One commenter argues there is likely no unique proprietary “secret sauce” visible in the reasoning tokens: the gap is framed as primarily data, compute, and engineering, not fundamentally different reasoning mechanisms. They speculate that open-weight models could reach future closed-model capability levels while fitting on a 128G device, though this is presented as prediction rather than benchmark evidence.
  • Another technical point is that hidden reasoning is valuable less as user-facing output and more for post-training and RL optimization: retaining or supervising latent reasoning traces can improve training signals and reduce cost by avoiding longer visible generations. The claim is that hidden reasoning mainly helps optimize post-training objectives and inference economics rather than representing a qualitatively separate capability.

• Anthropic, OpenAI, Google, Meta, Microsoft, and Mistral all signed the EU Code of Practice on Transparency of AI-Generated Content (Activity: 949): The image is a screenshot of an X post claiming Anthropic, OpenAI, Google, Meta, Microsoft, and Mistral signed the EU Code of Practice on transparency for AI-generated content, with OpenAI support text saying it wants to expand provenance signals to all modalities, including text. The Reddit post interprets this as future invisible watermarking of generated code and prose, including local/open-weight models from those vendors, though the image itself is not a technical spec or implementation proof. Commenters largely focused on practical bypasses and workflow risk: one argued watermarking could be learned from ~10M generated tokens and removed by a small adversarial 1.5B model or browser extension, while others worried it could push users toward non-signatory/Chinese models or interfere with agentic code generation and compilers.

  • A commenter argues text watermarking may be technically easy to reverse-engineer: generate roughly 10,000 paragraphs / ~10M tokens per model, train a classifier to distinguish outputs, identify the watermark-correlated features, then train an adversarial 1.5B model to minimally rewrite text and remove the signal. They claim such a remover could run locally on laptop CPUs or as a browser extension modifying streamed LLM output in real time.
  • Several commenters questioned whether invisible watermarking is compatible with functional text generation, especially for code. The concern is that token-distribution perturbations or hidden markers could interfere with agentic scripts, compiler-sensitive outputs, or exact-format generation, unlike watermarking in image/audio/video where imperceptible signal channels are more natural.
  • One technical adoption concern raised was that mandatory EU watermarking could push users toward open-weight or cheaper API models outside the signatory set, particularly Chinese models, if the watermark affects output quality or detectability. A commenter speculated providers might maintain EU-specific watermarking behavior if users in other markets reject it.

Less Technical AI Subreddit Recap

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. SL2T and H3 Multimodal Model Mechanics

• DeepMind just released SL2T, sign language-to-text model, deaf users can now sign into their phones instead of typing, developed with heavy input from the Deaf community (Activity: 3468): DeepMind reportedly released SL2T, a sign-language-to-text system that converts simultaneous hand, body, and facial movements into English text in real time, enabling Deaf users to sign into phones rather than type; details are in the linked DeepMind blog post. The post says pose tracking runs on-device for privacy while translation is performed server-side, supports practical scenarios such as one-handed signing while holding a phone, and is claimed to be “state-of-the-art on academic benchmarks” though no benchmark numbers are provided in the Reddit summary. Top comments are broadly positive, expressing respect for DeepMind and surprise that this accessibility technology had not appeared earlier; there is no substantive technical debate in the provided comments.

• PSA: I’m the creator of Heretic, and I advise you to not use “heretic” models as text encoders for H3 (or any other model) (Activity: 2901): The creator of Heretic warns that substituting a “heretic”/abliterated LLM for an image/video model text encoder—e.g. replacing Minimax H3’s Qwen3-VL encoder—will not reduce output censorship and may degrade prompt adherence or introduce artifacts. Heretic-style methods use directional ablation / ARA / SOMA to perturb residual-stream representations so “harmful” prompts resemble “harmless” ones for LLM refusal behavior; they do not produce richer, more “raw” semantic embeddings for downstream diffusion/transformer generators, and instead shift hidden states away from the distribution the generator was trained on. A possible exception is models/workflows with an explicit refusing LLM stage, such as prompt enhancers or systems like Ideogram-style active refusal, where uncensoring that LLM component could matter. Comments mostly support the PSA as authoritative and worth amplifying. One commenter notes a practical exception: if an image workflow first runs the user prompt through an LLM-based prompt enhancer that itself refuses questionable content, swapping that enhancer to an uncensored model can bypass the refusal before the prompt reaches the generator.

  • One commenter noted a narrow valid use case for Heretic/uncensored models in image-generation workflows: not as the text encoder for H3 or similar models, but as an upstream LLM prompt enhancer that rewrites a user prompt before it is passed to the image model. They reported that some prompt-enhancer workflows refuse “questionable content,” and swapping in an uncensored LLM avoided the refusal, implying the benefit is at the prompt-preprocessing layer rather than in CLIP/T5-style image-model conditioning.

2. Grok 4.6 Benchmarks and DeepSeek API Hike

• DeepSeek just massively increased their API prices (effective August 16, 2026) - up to 1,114% increase for cache hits (Activity: 1597): DeepSeek is changing its API pricing effective 2026-08-16 16:00 UTC, adding peak/off-peak windows where peak pricing is 2× off-peak, per its API pricing docs. The largest increases are for cached input: V4-Pro cache hits rise from $0.003625 to $0.022/$0.044 off-peak/peak per pricing unit, i.e. +507%/+1,114%; output also rises sharply, with V4-Pro output moving from $0.87 to $1.98/$3.96 (+128%/+355%). This materially reduces DeepSeek’s cost advantage for long-context/repetitive workloads that rely on prompt caching, and introduces scheduler/cost-optimization complexity around UTC peak windows. Top comments were mostly non-technical and pessimistic; one commenter said they had “already shifted away” because “DS4 is good but when cheap,” implying the model’s value proposition depends heavily on low API pricing.

  • Some users report already migrating away from DeepSeek’s API, with the view that DS4’s value proposition depends heavily on low pricing; after the announced increases, they consider it less competitive despite acceptable model quality.
  • One commenter notes a timezone-related pricing advantage: in Brazil, the API’s “off-peak” window apparently maps to roughly 7:00–22:00 local time, making discounted usage available during much of the normal workday.

• Grok 4.6 is an equivalent to Sol 5.6 according to artificial analysis arena (Activity: 1475): The image is a benchmark bar chart titled “Artificial Analysis Intelligence Index” showing Claude Opus 5 leading at 63, Claude Fable 5 at 62, and GPT-5.6 Sol tied with Grok 4.6 at 61, supporting the post title’s claim that “Grok 4.6 is an equivalent to Sol 5.6” on this aggregate index. The comments add pricing/model-scale context: Grok 4.6 is described as much cheaper ($2/M input, $6/M output tokens) than GPT-5.6 Sol ($5/M input, $30/M output), while allegedly being a smaller 1.5T model versus 5T+ competitors. Commenters frame the result as surprising frontier-model progress for xAI/Grok, with one noting that Google being “completely out of the frontier” was unexpected. There is also speculation that Grok 4.7 may scale to 2T–2.5T parameters and that future major models will start around “Kimi level.”

  • Commenters highlighted pricing and scale comparisons: Grok 4.6 is cited at $2/M input and $6/M output tokens, far cheaper than GPG 5.6 Sol at $5/M input and $30/M output. One user notes that SpaceXAI compared Grok 4.6 only against Sol and Fable, not Opus or Sonnet, despite claiming Grok 4.6 is a smaller ~1.5T-parameter model versus allegedly 5T+ models.
  • A technical thread debated whether Grok 4.6 is 2T parameters or 1.5T, with one commenter correcting themselves that it is likely Grok 4.5 plus additional RL, analogous to the claimed relationship between GPT 5.5 and GPT 5.6. They argued this implies SpaceXAI may be only ~3 months behind OpenAI, based on inferred OpenAI 5.6 availability around April/May and reports that external testers had access to 5.6 roughly 3 months before release.
  • Several comments framed Grok 4.6’s benchmark position as notable because it is reportedly near SOTA on multiple benchmarks while Google appears “out of the frontier.” Another commenter suggested that if Grok 4.6 and Kimi-level models are now the baseline for large frontier releases, upcoming models like Grok 4.7 may move to 2T–2.5T parameters.

• Grok 4.6 Benchmarks (Activity: 1017): The image is a benchmark table for “Grok 4.6 High” (image) comparing it against Grok 4.5 High, GPT-5.6 Sol Max, and Fable 5 Max. It presents Grok 4.6 as a strong frontier-model result, leading on GDPVal-AA v2, AA-Briefcase, and Harvey LAB, while competitors still lead several other benchmark categories; the table notes results are based on third-party model scores using the best self-reported or public numbers. A commenter also highlights a reported 1.5T scale, implying interest in model size/compute as part of the benchmark context. Comments are mostly light or speculative: one user frames frontier progress as a rotating hype cycle — Grok → Claude → Gemini → ChatGPT — while another calls the reported 1.5T scale “impressive.”

  • A commenter notes that Grok 4.6 is reportedly a 1.5T-parameter model, framing its benchmark result as notable given the scale and apparent rapid improvement. Another commenter highlights price/performance, saying Grok is “very good at coding” and “very fast” for the cost, with benchmark positioning apparently close to Kimi K3—“exactly the same price per task” while scoring 1 point higher.
  • One technically substantive workflow described combines Claude Opus and Grok for coding: Opus handles high-level planning and initial implementation, while Grok performs narrowly scoped edits. The commenter compares this manual setup to a stronger version of Cursor/Composer-style agentic editing and suggests it could be automated with sub-agents.

3. Claude Opus 5 Agent UX and Autonomous Coding

• I asked Opus 5 to build GTA6 on its own in 24 hours (Activity: 1558): The author claims they tasked Opus 5 with autonomously generating a GTA-like open-world game in 24h, letting the model choose city layout, districts, roads, buildings, NPCs, vehicles, and weather without further direction. They later published the orchestration harness, including “skills, agents, tooling, resources, and models,” at ukanwat/aaabench; the linked Reddit-hosted gameplay/trailer video was not accessible from the provided URL due to a Reddit 403 Forbidden block. Comments were mostly speculative: one user asked where the 3D/models/assets came from, while another argued that although the result is “rough,” this kind of autonomous game generation could meaningfully expand indie-game production over the next decade despite likely AI-generated “slop.”

  • A technically relevant question focused on asset provenance: one commenter asked “where did it get the models from”, highlighting that evaluating an AI-built GTA-like demo depends heavily on whether Opus generated meshes/textures itself, used bundled assets, scraped/downloaded third-party models, or relied on existing game-engine asset packs. This distinction matters for judging autonomy, copyright risk, and how much of the result reflects actual model capability versus asset assembly.

• Opus 5 is actually almost rage-inducing to use. (Activity: 1378): The post reports poor usability with Anthropic Claude Opus 5 in coding/workflow contexts despite following Anthropic guidance and modifying global claude.md: outputs allegedly remain overly verbose, buzzword-heavy, and prone to inflating small tasks into multi-step “projects.” The author’s main technical complaint is incomplete code edits / code rot: Opus 5 may change one part of a file, invalidate another part in the same file, then merely note “let me know if you want it changed as well” rather than fixing the induced inconsistency; they contrast this with Fable, which they say has fewer such issues but restrictive weekly limits even on the $200 plan. Top comments strongly agree, characterizing Opus 5 as unusable or “annoying”; one user says a simple request to make a two-page text file concise became an hour-long process with ~10 remaining action items, while another says users must push it repeatedly to complete a single requested change.

  • Multiple users report Opus 5 has a task-following/regression issue versus Opus 4.8, especially for simple transformation tasks like summarizing or rewriting: one user says a request to make a two-page text file concise turned into “walls of text” plus a proposed workflow/system with many follow-up action items after an hour. The recurring technical complaint is excessive decomposition and over-planning instead of directly completing the requested output.
  • Several comments describe Opus 5 as producing convoluted prose and messy reasoning on edge cases, with one user explicitly reverting to Opus 4.8 because “nothing worked with Opus 5.” Another notes apparent “code rot” and says the model requires repeated prompting to complete a single requested coding task, suggesting degraded instruction adherence or persistence compared with prior versions.
  • One commenter compares Opus 5 unfavorably with ChatGPT 5.6, saying they switched back because ChatGPT was “so much more helpful.” While no benchmarks are provided, the thread’s substantive theme is perceived practical usability regression: verbosity, stubbornness, and poor follow-through rather than raw intelligence.

• You never know the good days until they’re gone (unless you’re still using 4.6) (Activity: 1001): The image is a bar chart comparing words per answer across model versions, showing Opus 5 as much more verbose at 510 words/answer versus Opus 4.6 at 234, Opus 4.8 at 259, Opus 4.7 at 276, Fable 5 at 316, and Opus 4.5 at 158. The post uses this to argue that newer models—especially Opus 5—may be less pleasant for practical workflows because they “flood the chat” with unnecessary chatter despite being newer or stronger on paper. Commenters debated whether higher benchmark intelligence translates to better usability: one preferred a slightly weaker model that executes concisely over one that narrates excessively, while another asked for the data source behind the chart. A third commenter said they now use Kimi K3 as a main driver because it is more pleasant and exposes reasoning traces for oversight by other agents.

  • Several commenters argue that higher benchmark or “smarter on paper” performance does not necessarily translate into better developer ergonomics: Opus 5 is criticized for verbose meta-reasoning, excessive caveats, and repeatedly generating new follow-up issues instead of directly completing the requested task. One user says they would prefer a “slightly weaker model” if it more reliably understands the task and executes without long narrative overhead.
  • A workflow comparison highlights Kimi K3 as a preferred “main driver” model, with Claude/Sol used as planner/reviewer agents. The key technical point is that Kimi reportedly exposes reasoning traces rather than hiding them, allowing supervising agents to inspect intermediate reasoning in near real time and catch issues more effectively; Fable is described as better at planning, while Sol is more thorough but less pleasant due to degraded writing style.
  • A small but notable usage signal: one commenter says they still use Claude 4.6 almost exclusively, implying that older models may remain preferable when they provide better task adherence, lower verbosity, or more predictable interaction patterns than newer releases.