[AINews] Muse Spark 1.3 matches GPT-5.6-Sol, confirming Meta Superintelligence as the newest Frontier Lab, >90% discount for training

Launch season continues from yesterday, with Gemini 3.8 Flash as rumored today, but Muse Spark 1.3, promised in Zuck’s big comeback letter last month, definitely deserved the title story win today. Per AAII it is now the #3 model in the world (!?!)

Just look at the confidence displayed finally putting up comparable numbers to the frontier models from OpenAI and Anthropic (Opus, not Fable)… and promising that it will be open weights as well(!!!):

They have an interesting pricing model where it is 90%+ cheaper if you opt in to training:

AI News for 8/22/2026-8/24/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 of email frequencies!

AI Twitter Recap

Agent Engineering Courses, Curricula, and Developer Practice

• Stanford is formalizing AI-native software engineering as a discipline: @mihail_eric announced a new edition of The Modern Software Developer centered on what he calls the “2026 metamorphosis” of software engineering. The notable signal is not just the course itself, but the curriculum reset: 85% of Fall 2025 material is being replaced with topics like agent skills, context engineering, MCP portals, agent-ready codebase design, agentic code review, security, parallel background agents, and software factories. The course also requires students to ship PRs into real OSS repos with support from partners including Browserbase, OpenHands, Semgrep, Milvus, Marimo, CrewAI, Warp, Vercel, Unsloth, and Anyscale, among others.
• A second Stanford course focuses on first-principles agent construction: @Diyi_Yang and @michaelryan207 announced CS329Z: Engineering AI Agents, explicitly framed around building agents “from scratch.” Alongside Mihail Eric’s course, this suggests a broader shift from “prompting” pedagogy to systems-oriented agent engineering: harnesses, evaluation, memory, tooling, orchestration, and production constraints rather than model usage alone.
• Practitioner discussion is converging on stateful intelligence allocation, not simple routing: In a panel prompt, @HarryStebbings highlighted @EnoReyes’s argument that getting the most out of models requires more than routing—agents need to understand task state, what just happened, and what comes next in order to allocate intelligence dynamically. That lines up with @jerryjliu0’s point that vendor-neutral startups can outperform frontier labs on narrow tasks by optimizing the harness end-to-end and selectively using both frontier and open-weight models.

Model Architecture and Inference: Astra Rumors, Looped Transformers, and Real-Time Serving

• The “Astra is a looped transformer” rumor is probably less novel than headlines suggest: @rasbt unpacked reporting around OpenAI’s rumored Astra architecture and argued that the cited “recurrent depth” or “looped transformer” concept is a fairly modest architectural tweak rather than a breakthrough on its own. He points to Nanbeige 4.2-3B as an open-weight precedent: a 22-layer transformer stack reused twice, effectively behaving like a 44-layer model without doubling parameter storage. The tradeoff is straightforward: similar memory footprint, roughly ~2x compute, and only partial token-efficiency retention versus a standard stack. The more substantive historical reference is Mixture-of-recursions, where a learned router adaptively determines how many passes a token gets, allowing easy tokens to exit early and hard tokens to receive more compute.
• Hidden reasoning is not a necessary implication of recurrence: A second important clarification from @rasbt is that layer reuse does not inherently “obscure chain-of-thought”. It simply moves more computation into latent activations before token emission. If recurrent depth reduces visible reasoning traces, that’s because the model may need to emit fewer intermediate tokens, not because looped transformers intrinsically suppress textual CoT.
• Serving infra updates continue to target realtime multimodal workloads: @vikhyatk announced Photon 2.1, adding text-to-speech models and NVIDIA B200 support to a realtime multimodal inference engine. Separately, Baseten announced hosted availability of GLM-5.3 Fast, emphasizing higher TPS and real-time deployment positioning via @baseten.

Agent Harnesses, Skill Retrieval, and RL Post-Training Tooling

• ByteDance Seed’s HarnessDev reframes agent evaluation around the harness, not just task completion: @omarsar0 highlighted a new paper on HarnessDev, which asks models to start from a weak but runnable seed and build an execution harness, then improve it in a second stage using downstream feedback. Both stages are scored on capability and execution-token cost, making efficiency part of the objective. Across six creator LLMs, four domains, and 2,207 held-out downstream instances, generated harnesses still lag mature human-engineered systems on code, search, and research, but match or exceed them on writing and ML experimentation. The key nuance is that self-evolving harnesses help, but gains are unstable, model-dependent, and only partially transferable.
• Related ecosystem signal: exo and recursive self-improvement tooling: @omarsar0 also called out the exo harness as a useful entry point for understanding recursive self-improvement workflows, indicating a growing interest in frameworks where agents improve not just outputs but their own scaffolding.
• Skill retrieval may look good in aggregate while hurting the tasks that actually trigger it: @dair_ai summarized a paper proposing Retrieval-Invoked Actual-Use Effect, a matched-evaluation method that runs the same task twice, with and without skills enabled, and only counts tasks where retrieval actually fired. Across 17 LLMs on coding and math, the paper finds cases where retrieval improves overall scores while having a negative same-task effect on the subset of tasks where it was used. For teams maintaining skill libraries or tool directories, this is a practical warning against over-interpreting aggregate lift.
• RL post-training infra is becoming more productized: The SGLang team promoted an event with Baseten and NVIDIA Dynamo around Miles, an RL training framework that uses SGLang as the rollout inference engine for faster, more reliable RL post-training @sgl_project. @AravSrinivas separately described Miles as open-source RL-as-a-service, reinforcing the trend toward reusable post-training stacks rather than bespoke internal pipelines.

Google Gemini 3.8 Flash Cyber and Production Friction Around Google Tooling

• Google introduced a specialized cybersecurity model with strong benchmark claims: @sundarpichai announced Gemini 3.8 Flash Cyber, positioned as Google’s most capable cybersecurity model while retaining Flash-level speed and pricing. Reported numbers include 86.2% on CyberGym, 47.2% on CWE-Bench for patching, and 70%+ success on an internal vulnerability-discovery benchmark across 20 programming languages.
• At the same time, developer sentiment points to harness and account-risk concerns: @theo argued that Google currently has weak developer ergonomics around harnesses, code apps, third-party integration, and especially aggressive bans tied to core Google accounts. @QuinnyPig sharpened that concern, noting the blast radius can extend beyond Gmail/Workspace to Google Cloud accounts associated with the same identity. Theo’s later complaints about slow, tool-call-heavy coding behavior on Gemini tasks (1, 2, 3) are anecdotal, but they underline the gap between benchmark performance and production developer UX.

Meta Muse Spark 1.3 and the Video/Multimodal Release Cycle

• Meta launched Muse Spark 1.3 for agentic and coding workloads: @shengjia_zhao introduced Muse Spark 1.3 as the strongest model in the Spark line for agentic and coding tasks, with emphasis on longer-horizon work and more reliable compliance with complex instructions. Community reactions emphasized its price/performance envelope, including @alexandr_wang calling out what it can do “for a single dime,” while other users compared it favorably on speed and token efficiency versus competing “xhigh” offerings.
• Alibaba’s Wan 3.0 is posting strong third-party leaderboard results in video: @ArtificialAnlys reported that Wan 3.0 ranks #1 on Video Editing with Audio, #2 on Text-to-Video with Audio, and #5 on Image-to-Video with Audio on Artificial Analysis leaderboards. The release is positioned as an all-in-one generation and editing model that accepts text, images, video, audio, documents, and web pages as references, supports native audio, and generates up to 30 seconds at 1080p. Pricing in public preview starts at $0.05/s for 480p, rising to $0.20/s for 1080p.
• Reference-heavy multimodal UX is also improving: @imagine announced support for up to 14 references per video, spanning images, voices, and character references via @-tagging in prompts, a small but practical interface improvement for multi-asset creative control.

Open Models, Robotics, and Top Tweets

• Open model efforts continue to scale up: @percyliang shared that Marin 535B-A23B is 13% through training, with compute funded via the Jen-Hsun and Lori Huang Foundation and run on CoreWeave. The post is notable less for a benchmark than for the continued viability of large-scale open-model training backed by philanthropic compute support.
• Physical AI and open robotics platforms are inching forward: @maze_rapid announced the Palmimo DevKit, a tabletop AI robot platform with open-source software and swappable AI “brains,” designed so developers can control robot applications from a few lines of Python without deep robotics expertise. It’s early, but relevant as an example of agent frameworks extending into embodied systems.
• Top tweets (by engagement):
  • @mihail_eric: Stanford’s revamped AI-native software developer course with major curriculum turnover and OSS collaboration.
  • @sundarpichai: Gemini 3.8 Flash Cyber launch with strong cybersecurity benchmark claims.
  • @rasbt: Detailed architectural breakdown of looped transformers and why Astra rumors may be overstating novelty.
  • @Diyi_Yang / @michaelryan207: New Stanford course CS329Z: Engineering AI Agents.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Muse Spark and Spark-X2.5 Open-Weight Models

• Muse Spark open weights coming soon (Activity: 902): The image is a screenshot of a Mark Zuckerberg/X post announcing Muse Spark 1.3 rollout, claiming major improvements in coding, agentic workflows, and long-context tasks, with Muse Spark open weights “coming soon.” The included benchmark table positions Muse Spark 1.3 above Muse Spark 1.2 and competitive with models labeled GPT 5.6 Sol and Opus 5 across agent, long-context, and coding evaluations, though the Reddit post’s author notes Spark may be too large for their hardware and says they are waiting for Llama 5 or an intermediate model between Glimmer and Spark. Commenters frame the results as evidence that multiple leading labs are converging technically, with one saying there is “no secret sauce” and that frontier gaps may only be a few months. Another commenter argues Muse Glimmer is underrated and claims it outperforms Qwen 3.8:27B on non-coding tasks.
  • Commenters highlighted an unusually high reported long-context result: MRCR 512k–1m at 98.1%, with one user asking whether this implies Muse Spark has effectively solved “context rot” at million-token scale. If accurate, that benchmark would be the most technically notable claim in the thread because sustained retrieval/reasoning quality across 512k+ contexts is still a major weakness for many open and closed models.
  • One user reported that Muse Glimmer is “pretty good” and subjectively superior to Qwen 3 8/27B for non-coding tasks, suggesting Muse’s smaller/previous model may already be competitive outside programming benchmarks. The comparison is anecdotal, but it points to task-dependent strengths rather than blanket leaderboard performance.
  • Several commenters questioned the likely parameter count behind the displayed scores, with speculation that Muse Spark could be trillion-parameter scale if the benchmarks are accurate. That raised practical deployment concerns: it may not be locally runnable for hobbyists, but open weights could still be useful for organizations needing non-Chinese model options for policy/compliance reasons.
• New Model: Spark-X2.5-4B, Spark-X2.5-1.7B (Activity: 301): XHToken released Spark-X2.5 1.7B and 4B, apparently a custom architecture rather than a simple fine-tune, with model cards claiming native 1M token context, multilingual support, and training on roughly 20T tokens plus long-context/post-training stages. The architecture reportedly uses a mix of full attention and sliding-window attention to reduce long-context KV/compute cost, and the 4B benchmark claims are framed as competitive with much larger models such as Qwen-class ~9B models. Runtime support is not yet upstreamed in llama.cpp; it depends on a pending llama.cpp PR #27868 or XHToken’s custom fork, with GGUFs available for 1.7B and 4B. Commenters were mainly impressed by the reported 20T-token pretraining scale and especially the claimed native 1M context at sub-5B parameter sizes. There was cautious interest in whether the benchmark claims—particularly 4B matching a ~9B model—hold up in independent testing.
  • Commenters highlighted the reported 20T training-token scale for Spark-X2.5, which is unusually large for the 1.7B/4B parameter range and could explain the claim that the 4B variant matches a 9B model if benchmarks reproduce. The other standout spec was native 1M context at this model size, which readers viewed as more technically notable than raw benchmark parity.
  • One tester reported early qualitative behavior using a “pi harness”: when asked “what model are you,” the model appeared to use tools to inspect/analyze the harness name before answering, suggesting agentic/tool-use tendencies but also “overthink[ing] a lot.” In a quick reasoning check, it failed the “car wash” test, and the tester planned further comparison against Qwen3.5 9B for daily-use quality.

2. Qwen3.8 Benchmarks and GGUF Speedups

• Qwen will be the king? (Activity: 732): The image shows an Arena AI Code Arena WebDev leaderboard where Qwen3.8-Max-0902 ranks #1 with a score of 1,691, narrowly ahead of Claude Opus 5 Max at 1,688 and Kimi K3 Max at 1,674. In context of the post, the result is being used to argue that Qwen’s extended reasoning/post-training scaling may be closing the gap with much larger frontier systems, potentially before a future Qwen 4 release or possible open-weight update. Commenters were notably optimistic about local/open-weight Qwen variants, with one claiming Q3.8-27B running locally outperformed their paid ChatGPT coding experience. Others questioned whether the top-performing Max model will become open-weight, while one commenter praised extended reasoning but noted the tradeoff: hours of latency for difficult tasks.
  • A user reports strong local coding performance from Q3.8-27B used with PI, claiming it outperformed their prior paid ChatGPT 5.1 access for coding tasks. They emphasize practical task-following: when supplied with relevant context such as wiki pages in .txt files, the model generated working code with few fixes while running fully on a local PC and preserving data privacy.
  • Several commenters focus on extended reasoning as a major differentiator: one says Qwen 3.8 Max is “100% correct” on their challenge set but can take hours to arrive at an answer. This frames the tradeoff as accuracy/reliability versus very high inference latency for reasoning-heavy workloads.
  • There is skepticism about the presented benchmark graph, with one commenter saying the numbers look “very massaged” and another asking why Fable 5.1 is absent from the comparison. The concern is that model-ranking claims may depend heavily on benchmark selection, reporting methodology, or omitted competitors.
• MTP released for Qwen3.8-Flash-Next-GGUF (Activity: 671): ****Unsloth released MTP support/files for Qwen3.8-Flash-Next-GGUF, with test instructions tied to an Unsloth llama.cpp branch/PR (unslothai/llama.cpp#144) and GGUF usage paths targeting local runtimes/OpenAI-compatible endpoints. A commenter points to a newly merged upstream llama.cpp optimization (ggml-org/llama.cpp#28123) reporting MTP throughput improvements from 123 tok/s → 183 tok/s on code and 83 tok/s → 144 tok/s on prose, versus 108 tok/s without drafting; before the patch, prose MTP was reportedly slower than no draft at all. Comment discussion is mostly practical: users ask whether SSD offload is stable/“ironed out” and note that the MTP files may have already been available for a few days.
  • A commenter cites a newly merged llama.cpp optimization PR (ggml-org/llama.cpp#28123) showing major MTP throughput gains for Qwen3.8-Flash-Next-GGUF: baseline without draft was 108 tok/s, pre-change MTP was 123 tok/s on code but only 83 tok/s on prose, and post-change MTP improved to 183 tok/s code / 144 tok/s prose. The key technical point is that before the merge, MTP could be slower than normal decoding on prose workloads, but the patch appears to make drafting consistently beneficial.
  • Several commenters are tracking unresolved runtime/support details in llama.cpp, including whether SSD offload is stable and what the -shared option changes versus non-shared mode for MTP files. Another user notes they believed the required llama.cpp feature support was still not fully merged, and reports low local performance of only about 9 tok/s, implying hardware/configuration sensitivity remains significant.