a quiet day.

AI News for 7/13/2026-7/14/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

Coding Agents, Harnesses, and the Shift From Chat to Execution

Open Models, Quantization, and Local Inference Compression

  • Aggressive compression is bringing frontier-adjacent models onto consumer devices: PrismML released Bonsai 27B, based on Qwen 3.6 27B, in two compact variants: Ternary Bonsai 27B at 5.9 GB / 1.71 effective bits and 1-bit Bonsai 27B at 3.9 GB / 1.125 effective bits, both under Apache 2.0. The claim is notable not just for size, but for preserving multimodal, tool-using, long-context agentic workflows locally; a demo shows Hermes running it on an RTX 5090, while Locally AI highlighted phone deployment. In parallel, Tencent Hunyuan released 1-bit and 4-bit Hy3, describing a 295B flagship-scale model that can be served on a single GPU via llama.cpp with MTP enabled.
  • Quantization and edge deployment continue to broaden the open-model operating envelope: @danielhanchen announced NVFP4 dynamic quants across the Gemma-4 family and additional large models including Qwen3.5-122B-A10B and GLM-4.7-Flash. @MiaAI_lab’s DGX Spark thread sketched practical multi-node local deployments, including 1M-context DeepSeek v4 Flash and MiMo-V2.5 on 2Ă— DGX Sparks, and GLM 5.2 NVFP4 across four. The common theme across these posts is that local inference is no longer just a toy path: it is becoming viable for serious agentic workflows, especially when paired with low-bit weight formats and optimized harnesses.

Multimodal and World-Model Systems: Video, Realtime VLMs, and Motion

  • Realtime multimodal interaction is moving from “watch then answer” to continuous perception: OpenMOSS released MOSS-VL-Realtime, an 11B vision-language family under Apache 2.0 with 256K context, designed for continuous video streams. Its key systems property is that it can keep watching while generating, revise or interrupt answers as scenes change, and remain silent when evidence is insufficient. A companion technical thread from @Open_MOSS emphasizes a cross-attention architecture, XRoPE for unified temporal-spatial positioning, and unified templates across offline/streaming/realtime settings.
  • Long-video understanding is increasingly framed as active evidence search, not passive frame ingestion: a dense summary from @ZhihuFrontier described OmniAgent, built on Qwen2.5-Omni-7B, which uses an Observation–Thought–Action loop to request only the frames/audio it needs. On LVBench, OmniAgent-7B reportedly scored 50.5, beating Qwen2.5-VL-72B at 47.3, while consuming only ~203 frames vs 768. The training recipe is also notable: passive SFT hurt performance, while 58K agentic trajectories and entropy-weighted RL via TAURA improved it. The larger research pattern here aligns with Andrew Carr’s note that motion is a fundamentally novel data type requiring dedicated collection, infra, and model treatment rather than being reduced to images-with-time.
  • Open world models are inching toward interactive, longer-horizon simulation: @RekaAILabs outlined the data stack behind omni world models, stressing petabytes of video, 6 pipeline stages, and the doubled payoff from data-quality improvements when models both generate and understand video. @omarsar0 summarized LingBot-World 2.0 as one of the first open releases claiming hour-scale, 720p/60fps interactive generation, though still without long-term memory. On the application side, PixVerse Game was highlighted as pursuing the harder problem of real-time interactive video response rather than canned game-like clips.

Research Infrastructure, Benchmarks, and Evaluation Methodology

  • Perplexity open-sourced WANDR, a benchmark for wide-and-deep agentic research: @perplexity_ai described WANDR as a 500-task benchmark built from de-identified production research tasks, requiring 170,495 source-backed records across multiple difficulty tiers. Rather than grading against a static gold set, WANDR re-fetches cited pages and checks claims against underlying evidence, which better matches dynamic web research. @AravSrinivas framed this as the internal benchmark behind Perplexity Computer’s deep-and-wide research harness, while @denisyarats emphasized its additional role as an RL environment synthesized from production traces.
  • Eval design is getting more adversarial and more realistic: Agent Arena highlighted work cutting system costs by 89% while matching the best static config’s accuracy, arguing that full system config > LLM routing alone. Relatedly, Google DeepMind work on model routing argued that routers should be judged not just by accuracy/cost but by behavioral differentiation among experts and stability under paraphrase; otherwise routing may be functionally meaningless. @HamelHusain’s automated evals post landed in a similar place: these systems can spot issues humans miss, but still lack enough domain taste and feedback loops to replace experts.
  • Benchmarks are expanding beyond one-shot SWE tasks toward degradation and search realism: mini-swe-agent marked one year while now powering multiple software benchmarks; SlopCodeBench was cited as measuring how agents erode codebases over sequential tasks rather than just solving one isolated issue. This broadens the benchmark surface from “can it solve a task?” to “can it avoid making the repository worse over time?”

Physical AI, Collective Intelligence, and Robotics

  • Sakana AI pushed collective intelligence from software into physical self-repairing systems: across multiple posts, Sakana introduced “Smart Cellular Bricks”, published in Nature Communications. The system consists of many identical cubes, each running a small neural network and communicating only with physical neighbors, yet able to infer global shape and detect damage without centralized control. A follow-up detail is especially notable: the cells can detect missing neighbors across six spatial directions with 95% accuracy and regrow target structures; in simulation, the method scaled to 18,000+ cubes (detail thread).
  • Physical autonomy is also showing up in much smaller form factors: @alextoussss posted a striking demo of an autonomous micro-drone achieving an air-to-air kill of a flying moth, framed as a step toward mosquito eradication. Separately, @fchollet highlighted Airtap, which turns SMS into a headless agentic execution layer for mobile apps, using text as the control plane and intervening only for authentication. These are different ends of the autonomy spectrum, but both point to interfaces where humans specify goals while systems handle embodied or semi-embodied execution.

Top tweets (by engagement)

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Chinese Open-Weight Models Gain Market Share

  • Chinese AI Models Seize OpenRouter’s Top Five as OpenAI and Google Vanish From the Top 10 (Activity: 637): The image is an OpenRouter “AI Model Rankings” dashboard showing monthly token-usage share, where Chinese models reportedly take the top five spots—DeepSeek V4 Flash, MiMo-V2.5, MiniMax M3, Hy3 preview, and DeepSeek V4 Pro—and seven of the top ten, while OpenAI and Google are absent from the top 10; the source ranking is OpenRouter’s own platform traffic, not global LLM usage. Technically, the significance is less about benchmark superiority and more about cost/performance and deployment economics: commenters frame OpenRouter as a practical routing/prototyping layer for testing cheaper open or semi-open models before deciding whether to self-host or keep paying API rates. Image Commenters emphasized that “it’s hard to compare benchmarks, but easy to compare bills,” arguing that models like DeepSeek V4 Flash and MiMo-V2.5 are attractive because they are “cheap and good enough,” sometimes cheaper via API than the electricity and hardware costs of self-hosting. There is also distrust of closed Western providers such as OpenAI and Anthropic due to pricing, model churn, and the possibility that preferred models may disappear or change unexpectedly.

    • Several commenters framed OpenRouter as a practical model-evaluation layer: test multiple open-source models through the API, then either self-host the best fit or continue using OpenRouter if the unit economics are better. The main technical concern raised was vendor instability from OpenAI/Anthropic—models changing, becoming more expensive, or disappearing—making reproducibility and long-term deployment planning harder.
    • A cost-focused thread argued that models like deepseek-v4-flash and mimo-v2.5 are cheap enough via hosted inference that self-hosting may cost more once electricity and hardware requirements are included. One commenter summarized the benchmarking-vs-cost tradeoff as: “It’s hard to compare benchmarks, but easy to compare bills.”
    • Infrastructure economics were highlighted as a factor in Chinese model/API competitiveness: commenters noted that electricity costs in China are less than half of US costs, which can materially affect inference pricing at scale. The discussion contrasted this with expensive US regions such as California, where high power prices and constraints on new generation could make domestic data-center inference less competitive.

  • FT: Companies Turn to Chinese Open Weight Models to Cut Costs (Activity: 407): The post links to an FT story titled “Companies Turn to Chinese Open Weight Models to Cut Costs,” implying enterprise adoption of Chinese open-weight LLMs as a cost-reduction strategy versus proprietary/API-hosted Western models. However, the archived link (archive.ph/QzSyV) only returned a CAPTCHA/429 Too Many Requests, so no article-level specifics—model names, pricing deltas, benchmarks, deployment patterns, or licensing terms—are verifiable from the provided source. Commenters frame the trend as predictable after perceived restrictions/bans on other models, arguing that policy and IP pressure may push companies toward Chinese open-weight alternatives. There is also optimism that open models will improve rapidly over the next few years, with one commenter citing phone-scale capability as evidence of accelerating local inference potential.

    • Several commenters framed the trend as a cost-structure problem for closed US frontier APIs, not an “AI bubble” broadly: companies that pushed heavy Anthropic/OpenAI-style token consumption are now reportedly asking employees to reduce usage after months of encouraging maximum adoption. One anecdote described internal incentives to use AI heavily despite unclear revenue impact, with the implication that token bills can become material operational spend before product-market fit is proven.
    • A technical theme was optimism around open-weight model efficiency, especially for local or edge deployment. One commenter cited Gemma 4 as an example of models becoming strong enough to run on phones, arguing that open models could increasingly replace paid frontier API calls where latency, privacy, or cost constraints matter.

  • Source: the Trump administration and industry groups discussed streamlining US open model releases of equal or lesser capability to leading Chinese open models (Activity: 451): The post claims the Trump administration and AI industry groups discussed a policy/process to streamline U.S. releases of open-weight/open models whose capability is equal to or below leading Chinese open models, as a response to China’s increasingly competitive local LLM ecosystem. The linked source is not technically verifiable from the provided archive because archive.is/sANZ5 resolves to a CAPTCHA/security interstitial rather than the article content. Commenters debated whether U.S. labs would actually release open models competitive with Chinese systems, arguing that strong local models could cannibalize paid API/SaaS revenue. Others questioned claims about Chinese models as “Trojan horses” or containing CCP-exploitable backdoors, noting that if such backdoors were straightforward to implant and exploit, U.S. actors would likely already dominate open-weight model deployment.

    • Several commenters argued that restrictions or bans on capable open-weight models would be technically unenforceable once weights are available globally: model files can be redistributed via torrents, physical drives, or mirrors, and enforcement would require controlling access to high-memory GPUs/workstations capable of running them. The discussion frames open weights as closer to general data distribution than a controllable service endpoint.
    • A technical skepticism emerged around claims that Chinese open models could contain CCP-accessible “backdoors.” One commenter noted that if reliable model-weight backdoors were practical and exploitable in this way, U.S. labs would likely already be using similar techniques to dominate open-weight releases; another called such backdoors “unlikely at this point.”
    • Commenters supported releasing U.S. open-weight models of equal or better quality as a competitive alternative to Chinese local models, especially for organizations that need on-prem deployment. One technical point highlighted Nvidia Nemotron as a positive example due to relatively transparent training data/process, while noting Nemotron 3 Ultra is strong but “not trained enough,” causing it to underperform relative to its parameter scale.

  • Zhipu founder backs open-source AI as global security debate intensifies (Activity: 298): Zhipu founder Tang Jie defended open-sourcing frontier AI in an internal memo, arguing that model security is better served by “transparency, broad participation, sharing, and oversight” than by restricting access, according to Business Standard. Zhipu has released GLM-5.2 under an open-source license for download and commercial use, while positioning future work around long-horizon tasks, autonomous agents, and self-training AI, amid broader policy debates involving OpenAI, Anthropic, cyber-risk, and national security controls. Comments were largely geopolitical and anti-monopoly in tone: users framed Chinese open-weight releases as a counterweight to closed US labs, while speculating that services like z.ai could face bans on security grounds.

    • A commenter notes that Zhipu/Z.ai’s open-source stance may be market-driven rather than ideological, pointing out that the company was previously more closed before DeepSeek R1 shifted competitive pressure toward open flagship releases. They argue the strategy could reverse if investor incentives begin favoring closed models again, despite recent investor acceptance of dilution.
    • One technically relevant user references prior experience with the GLM series, saying they have been a fan but that its coding-plan quality has historically been questionable. This suggests continued skepticism around Zhipu’s practical coding-agent performance even as its open-source positioning improves.

2. Local AI Inference: Compression, GPUs, and Game Engines

  • Compressed Version of Qwen-3.6-27B coming from PrismML - Khosla-Backed Startup Claims Breakthrough With Largest-Ever AI Model on an iPhone (Activity: 476): PrismML claims it compressed Alibaba’s open-weight Qwen 3.6 27B from roughly 54 GB to < 4 GB and can run it on an iPhone 17 Pro with all 27B parameters active, unlike sparse/on-device architectures such as Apple’s cited 20B-parameter model with only 1B–4B active. The company says the Caltech-derived, patent-licensed compression method preserves performance and enables on-device chat, reasoning, agents, and coding, with a downloadable release promised “next Tuesday,” though no benchmark numbers, tokens/sec, quantization details, accuracy deltas, or demo evidence are provided in the post. Top commenters are highly skeptical, calling the brain-synapse analogy technically meaningless and questioning the plausibility of <4 GB compression with no performance loss while computing all 27B parameters on an iPhone at usable speed. Several argue that credible claims should be accompanied by a live demo, benchmarks, or a technical blog rather than a hype article.

    • Several commenters challenged the claim that a 27B model can be compressed to roughly 4GB and run all parameters on an iPhone at acceptable speed without major quality loss. One technical guess was that this would require something like 1-bit / ternary quantization or BitNet-style quantization; a Q1-level 27B model can land near the 4GB range, but commenters noted it is typically “very damaged compared to fp16.”
    • A more detailed comment identified PrismML’s likely approach as its existing “1 bit” / ternary quantization, previously released for smaller Qwen models such as Bonsai-8B on Hugging Face. The commenter emphasized that prior PrismML benchmarks did not show near-original performance: their 8B quant reportedly performed worse than a BF16 4B, though better than 1.7B, implying the 27B version should not be expected to preserve full Qwen quality.
    • The technically relevant benchmark framing suggested by commenters is not whether the compressed 27B matches the original model, but whether a 4GB ternary 27B outperforms a conventional 4GB 8B Q4 model. One commenter also noted that PrismML appears to be comparing against Qwen3, not newer Qwen 3.5 / 3.6, which affects how claims about relative model quality should be interpreted.

  • I benchmarked 15 “E-Waste” GPUs with Modern Workloads (Activity: 628): The author benchmarked decommissioned NVIDIA Tesla-class GPUs—K80/M10/M40/M60/P40/P100/V100/T40—using a custom Dockerized suite (gpu_box_benchmark) and custom cooling hardware, targeting LLMs, CV, Blender, Whisper, and related workloads; full graphs are in the blog post. Key findings: V100 16GB is the best overall value near <$200 and approaches T40 performance, P40 beats P100 for LLM inference, M60 is unusually strong for Whisper despite ~$50 pricing, and multi-GPU scaling was described as mostly linear within a 4U chassis, with mixed-generation LLM setups bottlenecking on slower cards. The author argues EOL/CUDA-era friction can often be worked around by compiling older software such as llama.cpp from source, and that cheap X99 Xeon platforms provide enough PCIe lanes/CPU throughput for these GPUs in homelab workloads. Top technical pushback focused on whether the benchmark set is sufficiently “modern”: commenters asked for larger contemporary LLMs such as Qwen 3.x 27B/35B MoE, pooled-VRAM tests across multiple V100/P40-class cards, and prompt-processing/token-generation numbers at long context lengths like 150k. Others questioned practical power efficiency and acoustics, noting these systems may only make sense if powered on for batch AI jobs—or if waste heat offsets winter heating.

    • Several commenters argued the benchmark missed the key value proposition of old datacenter/mining cards: cheap pooled VRAM for larger contemporary LLMs. They requested tests with models like Qwen 3.6 27B/31B MoE/35B A3B at deep context lengths such as 150k ctx, reporting both prompt processing (PP) and token generation (TG) across multi-GPU configurations, especially on V100-class setups.
    • There was technical pushback on workload selection: ResNet and very small models were called unrepresentative of “modern” GPU use, because they do not stress the VRAM-capacity advantage of e-waste GPUs. The suggested practical benchmark was whether larger Qwen-class models can run with pooled VRAM at usable speeds, rather than showing good performance on legacy or undersized workloads.
    • One commenter noted the Tesla P100 should outperform the P40 unless a relevant fp32 optimization/patch changed the results, because the P100’s HBM bandwidth is roughly 3Ă— higher than the P40’s memory bandwidth. Another added a data point for the P102-100 mining GPU: about $50, around 10 W idle, easy cooling, and roughly 40 tokens/s generation on Qwen 3.6 35B, but with very slow prompt processing at about 100.

  • I got Gemma 4 running directly inside Godot using only GDScript and Vulkan compute shaders (Activity: 428): The post demonstrates Gemma 4 (gemma-4-E2B-it-Q4_K_M.gguf) running fully inside Godot 4.7 using only GDScript + Vulkan compute shaders, with GDScript handling GGUF loading, tokenization, sampling, KV cache, and UI—no llama.cpp, Python, server, C bindings, or GDExtension. The image shows a Godot editor/debug chat UI generating at about 46.99 tok/s, notably answering that such an implementation would be “not realistic,” despite the project proving a constrained version works. The author notes it is experimental, supports only one model, and is roughly 10Ă— slower than llama.cpp with CUDA; code is available on GitHub. Comments were mostly impressed, with one technical takeaway that the speed penalty is less important than the deployment model: a single Godot export with local inference avoids native-extension ABI issues and sidecar servers, making it plausible for portable local NPC demos.

    • A technically substantive point is that even at ~10x slower performance, the implementation is valuable because it packages GGUF loading, KV cache management, and sampling entirely inside a single Godot export using GDScript/Vulkan compute, avoiding native-extension ABI issues or a separate llama.cpp/sidecar inference server. This could make local LLM-powered NPC demos much easier for end users to run.
    • One commenter framed the main use case as embedded local generation for games, e.g. roguelike/roguelite systems that use an on-device LLM for more emergent randomness. The key technical appeal is removing the deployment burden of bundling or orchestrating an external inference runtime such as llama.cpp.

3. Kimi, DeepSeek, and GLM Release Watch

  • Kimi K3 in the next few hours. Deepseek V4 GA later in the week. New Liquid models. New Mistral models sometime this month. And some rumours suggest GLM 5.5 is coming in August. Openweight AI is eating good. (Activity: 573): The image is a screenshot amplifying rumors that Moonshot/Kimi K3 may launch imminently, following Kimi K2.6’s reported strengths in coding agents, long tool-using sessions, 256K context, vision, and low-cost large-scale sub-agent coordination. In context with the title/selftext, the post frames Kimi K3, DeepSeek V4 GA, new Liquid non-transformer models, upcoming Mistral releases, and possible GLM 5.5 as evidence that open-weight model capability and cost-performance are rapidly improving, while enterprise concerns shift toward governance/control layers rather than raw model intelligence. Commenters are enthusiastic but pragmatic: one user reports running local GLM 5.2 Q4 at only ~0.5 tok/s for multi-day codebase audits that still find useful bugs, while others argue the ecosystem especially needs strong models at 100B parameters and below—ideally not below 35B.

    • A user reports running GLM 5.2 Q4 locally continuously on a workstation for whole-repository static-analysis style prompting: “Read all code in this project and analyze it for bugs.” Throughput is only about 0.5 tokens/sec, with a full run taking roughly 3.5 days, but each run reportedly returns 10–15 bug findings with only 1–2 hallucinations and at least one practically useful issue fixed per run.
    • Several comments emphasize that current frontier open-weight releases are often impractical for enthusiasts because many are 0.5T+ parameter-class models requiring extreme hardware, e.g. multiple RTX PRO 6000-class GPUs or around 1TB ECC DDR5 for CPU/offload setups. Users specifically call for stronger models in the ≤100B range, with one commenter narrowing the useful local target to above 35B but under 100B rather than giant MoE/foundation-scale checkpoints.

  • đź‘€A new GLM model incoming (Activity: 1043): The image is a non-technical teaser screenshot from X, not a benchmark or release note: Ivan Fioravanti says “GLM 5.3 is cooking” while quoting Z.ai / GLM founder Jie Tang’s hint that “5.2 could be better with more RL,” implying an upcoming GLM update likely focused on additional reinforcement learning/post-training. The Reddit post frames this as a possible successor to GLM 5.2, with speculation in comments about variants like GLM 5.3 Flash 20B and broader open-weight model releases; image: i.redd.it/6xkuthwho7dh1.jpeg. Commenters are broadly excited about a crowded open-weight release window, mentioning rumored or expected models such as Kimi K3, DeepSeek V4 GA, Liquid, Mistral, and possibly GLM 5.5. There is no substantive technical debate yet, mostly hype and speculation.

    • Commenters expect a crowded open-weight release window: Kimi K3 reportedly “in the next few hours,” DeepSeek V4 GA later in the week, new Liquid models, new Mistral models this month, and rumors of GLM 5.5 in August. Another commenter speculates the incoming GLM could be GLM 5.3 Flash 20B, implying interest in a smaller/fast variant rather than another very large checkpoint.
    • A technical concern is usability of frontier-scale open models on attainable hardware: one user asks for models that run at reasonable speed on <$100k hardware, rejecting 30 tok/s prompt processing and 5 tok/s token generation as insufficient. They propose roughly 1000 tok/s prompt processing and 40 tok/s generation as a practical target for real-world tasks, while others complain that 700GB models are unusable locally and ask for smaller models like a hypothetical Qwen 3.7 35B.

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. Frontier Models Solving Open Math & Physics Problems

  • Yuji Tachikawa, one of the world’s leading theoretical physicists, reports Claude Fable solved a problem that he and his collaborators had gotten stuck on for the past 6 months (Activity: 3554): Yuji Tachikawa, a leading mathematical/theoretical physicist, reportedly posted that Claude Fable helped solve a technical problem his group had been stuck on for ~6 months (original tweet). He later deleted the tweet not as a retraction, but because he disliked the attention it attracted (follow-up); no reproducible derivation, benchmark, or problem statement is included in the Reddit post, so the technical claim cannot be independently assessed from the linked discussion alone. Top comments debated evaluation standards for AI-assisted research: one commenter argued that dismissing the result because it was not solved “one shot” applies a stricter standard to LLMs than to humans, while another highlighted the significance of an LLM proposing speculative directions such as “I wonder if…” as potentially relevant to frontier reasoning beyond known results.

    • One commenter frames Claude Fable’s contribution as notable because it appears to involve exploratory hypothesis generation rather than just executing a known procedure: they highlight the model saying “I wonder if…” as evidence of asking questions beyond the current solution path. The technical implication raised is that frontier LLMs may be moving toward a capability often cited as missing in AI-assisted research: proposing useful hypotheticals in domains where even experts are stuck.

  • Another 50+ year-old ErdĹ‘s problem falls to GPT-5.6 (Activity: 1144): The post links to X threads by J. D. Lichtman, PrzemysĹ‚aw Chojecki, and SĂ©bastien Bubeck claiming GPT-5.6 solved another 50+ year-old ErdĹ‘s problem. The Reddit body does not include the theorem statement, proof, benchmark setup, or verification details, so from the provided content the technically relevant takeaway is the claim of an LLM-assisted/LLM-generated proof rather than independently assessable mathematical evidence. Top comments mostly frame the result as a rebuttal to common LLM-skeptic claims like “just fancy autocorrect” or “just predicting the next word.” One substantive suggestion was to benchmark models on already-solved problems with long proofs to see whether they can discover shorter or simpler proofs, which would be useful even when the theorem is not new.

    • A commenter raised a methodological question about AI-assisted theorem proving: how much of the result comes from the LLM versus expert human guidance. They specifically asked whether a non-expert prompter, e.g. a high school student unable to verify correctness, could still get the model to solve the problem reliably.
    • Another technically relevant thread suggested benchmarking models on already-solved problems with long proofs to see whether systems like GPT-5.6 can produce materially shorter or simpler proofs. The commenter noted that this could be a useful way to evaluate mathematical creativity or proof compression, even if the practical significance is unclear.
    • One commenter noted that Przemek Chojecki appears to be producing solutions to ErdĹ‘s-style problems faster than they can be fully peer-checked, while Lichtman, described as a Stanford mathematician, reportedly thinks the approach is working. The key technical issue implied is verification throughput: AI-generated proofs may outpace expert validation, making independent checking and formalization important.

2. AI Data Extraction, Distillation & Privacy Incidents

  • Anthropic just told the US Senate that Alibaba ran 25,000 fake accounts and had 28.8 million conversations with Claude — not to use it, but to copy it (Activity: 2021): The post claims Anthropic told the U.S. Senate that Alibaba allegedly used 25,000 fake accounts to conduct 28.8M Claude API conversations over ~six weeks (April–June), not via hacking but by normal API access at industrial scale, to distill Claude’s agentic reasoning and coding capabilities into Qwen. Anthropic reportedly frames this as its largest “distillation attack,” larger than alleged activity by DeepSeek, Moonshot, and MiniMax combined, and the author argues the legal ambiguity explains why Anthropic sent a congressional letter rather than filing suit; they link a longer breakdown on YouTube: youtu.be/g1d3yTR6E2Y. Top comments largely reject Anthropic’s framing as hypocritical, arguing AI labs trained on public/creative output under fair-use theories and now object when their own model outputs are used similarly. One commenter frames mass distillation as analogous to competitive reverse engineering—e.g., automakers or Samsung buying a rival product to study it—while acknowledging the analogy is imperfect.

    • Commenters drew a technical/legal analogy between model distillation via API outputs and conventional competitive reverse engineering, e.g. buying a competitor’s car or phone and studying it to improve an internal product. The implied technical question is whether using Claude-generated outputs as supervised training data is materially different from engineers learning from a competitor’s product behavior.
    • One technically relevant caveat raised was attribution: because Alibaba operates cloud infrastructure, suspicious traffic originating from Alibaba-owned IP ranges or accounts may not prove that Alibaba itself performed the alleged distillation. The commenter compared it to seeing abusive or unusual requests from AWS or Azure, which often implicates customers using the platform rather than Amazon or Microsoft directly.
    • Another thread framed the incident as an API governance failure: if the 25,000 accounts and 28.8 million Claude conversations were paid API usage and not blocked earlier, commenters questioned whether Anthropic’s enforcement, anomaly detection, rate limits, or ToS controls were sufficient to prevent large-scale extraction-like usage.

  • grok build was uploading whole directories to google bucket (Activity: 1074): The image is a screenshot of a claim by International Cyber Digest alleging that xAI’s Grok Build CLI uploaded whole Git repositories—including private code and unredacted secrets—to a Google Cloud Storage bucket. The post claims a 12 GB test repository caused 5.1 GB of uploads, that the behavior was later disabled via a hidden server-side flag, and that the “Improve the model” opt-out allegedly did not prevent the upload; no independent technical evidence is provided in the Reddit excerpt. The comments shown are non-technical and mostly express broad hostility or distrust toward Grok/xAI/Musk rather than debating the implementation or evidence.

3. AI Coding Agents: Workflows, Costs & Reliability Limits

  • Fable + 5.6 is absolute peak (Activity: 1306): The post describes a shell-scripted agent workflow (TRIP-workflow) where Fable acts as a high-level orchestrator rather than primary code generator: it plans, has 5.6 Sol review plans in an approval loop, delegates implementation to 5.6 Luna via Codex/Claude-code-style CLI background workers with persistent threads, then reads diffs, patches issues, runs tests, and handles release tasks such as changelog/tag/merge. The author emphasizes the stack is “just bash around codex cli” with no MCP/framework/agent swarm, and recommends users clone the repo and have an agent explain/review it before trusting it. Top comments discuss using adversarial multi-model workflows: giving both Fable and Sol 5.6 xhigh the same problem statement, letting one design/execute while the other critiques at checkpoints, sometimes with a scorekeeping loop. Others ask for concrete cost/quality comparisons versus Fable alone, thinking-setting choices, and suggest evaluating an omp harness for this kind of orchestration.

    • Several commenters describe a multi-model adversarial workflow: give both Fable and Sol 5.6 xhigh the same problem statement and goal, let each produce a design, then allow the winning design to execute while the losing model performs checkpoint reviews and teardown. One user reports a similar validation pattern where Codex reviews Fable-generated plans and often finds “something crucial missing,” suggesting Fable may need external critique for planning reliability.
    • A commenter recommends using the omp harness for this kind of model-vs-model orchestration, implying there are existing harnesses better suited than ad hoc scripts for evaluating or coordinating multi-agent/model workflows.
    • One user open-sourced a lightweight orchestration daemon, jinn, intended to replace brittle bash glue for Claude Code + Codex workflows. It provides persistent sessions, cross-engine messages, a shared facts file, cron, and YAML personas, but deliberately avoids implementing its own agent loop: *“A bus not a brain, the CLIs still do all the thinking.”

  • [WARNING] Avoid using 5.6 Sol. It can get you banned for even the most harmless task. Used it once for a legitimate Excel task, got flagged for a “cybersecurity threat,” appeal was rejected within 2h. (Activity: 952): A user reports that a single benign Sol 5.6 task—generating an Excel workbook for rental-property accounting—triggered a “cybersecurity threat” flag and warning despite the prompt containing only spreadsheet requirements: monthly utility/rent accounting, printable statements, cash-flow tracking, room-level over/underpayment carry-forward, and capital vs. utility fund separation. During Sol’s Excel workflow it apparently generated/reran code, hit an exception resembling “Could not get source, probably due to dynamically evaluated source code”, then still produced the workbook after review; the user’s appeal was rejected within ~2h. Commenters largely treat this as a likely false positive in OpenAI’s automated safety/appeals pipeline; one notes OpenAI staff monitor the subreddit and may be able to manually investigate, while the OP argues the appeal process appears AI-mediated and ineffective.

    • A commenter shared the full prompt that allegedly triggered the ban: a benign request to generate a multi-sheet Excel workbook for rental-property accounting, including monthly utility allocation, tenant over/underpayment carry-forward, printable statements, and separate capital/utilities cash-flow tracking. The technically relevant detail is that the task likely required workbook generation and formulas/tables, which may have caused the model to invoke a code-execution or file-generation path despite no explicit cybersecurity content.
    • One user hypothesized that GPT-5.6 Sol may have executed code in a cloud sandbox from the ChatGPT client, and that this sandbox activity—not the natural-language prompt itself—could have tripped automated cybersecurity classifiers. They contrasted this with the Codex client, suggesting the same task might not cause the same enforcement issue there because the execution environment or policy pipeline may differ.

  • Well it finally happened: we’re not using models because of cost (Activity: 849): A Fortune 500 “AI First” org reportedly pulled back from broad Claude/Copilot usage after a failed agentic pilot to reverse-engineer a legacy application into a formal specification: agents repeatedly missed subtle business rules and produced unreliable specs, while day-to-day codegen showed correctness/safety issues such as generated SQL that dropped constraints around DML paths. The company has stopped AI training/demos, removed Claude access, and is asking teams to limit usage or use older/cheaper models, with commenters noting Copilot’s move to usage-based pricing as a likely trigger for cost visibility in large enterprises. Commenters split between seeing this as evidence that current LLM ROI is poor for complex software modernization, versus a temporary “sour spot” where capability is almost useful but still too expensive—especially for agent/subagent-heavy workflows. One commenter asked whether the company would resume an AI-first posture if inference costs drop substantially.

    • Several commenters identify usage-based pricing for GitHub Copilot as the trigger that made large organizations re-evaluate AI tooling costs. The implication is that predictable per-seat licensing masked consumption risk, while metered billing exposes high-volume inference and agent workflows as a material operating expense.
    • One technical cost concern is that AI workflows with intense subagent use can multiply inference calls, making otherwise useful models financially unattractive before capability-per-dollar improves. A commenter argues this may be temporary as models improve and become cheaper “per unit of intelligence,” but that current systems sit in a “sour spot” where they are close to useful yet still expensive at scale.
    • A commenter from a very large company claims every AI project failed or was abandoned, not necessarily due to model access limits but because teams did not want to maintain the generated “slop.” The technical takeaway is that AI adoption cost includes downstream maintenance, code quality review, and operational ownership—not just token or subscription spend.

AI Discords

Unfortunately, Discord shut down our access today. We will not bring it back in this form but we will be shipping the new AINews soon. Thanks for reading to here, it was a good run.