Meet Xiaomi and other top Chinese frontier labs at AIE Shanghai!

This is a first for the “Apple of China” phone maker-turned-frontier lab: “The MiMo-V2.6 series includes two natively omnimodal models: MiMo-V2.6-Pro is our most capable model to date, while MiMo-V2.6-Flash strikes the best balance between intelligence, efficiency, and cost. We are also rolling-out MiMo-V2.6-Pro-UltraSpeed, delivering up to 20x faster output speed at the same quality, for users who require extreme generation speed.”

Xiaomi is not traditionally considered one of the six Chinese AI Tigers, so it is very surprising to the established order of names you have come to know and love. And… it is natively omnimodal!

Xiaomi made news a few days ago when Fuli Luo, a former DeepSeek star engineer now at Xiaomi, started publishing their final RL training runs live, which showed an abnormal amount of transparency in their internal metrics.

As they note in their technical report, they scaled RL compute along three axes:

1. Larger batches and higher throughput: large batches on a fully asynchronous architecture, with 1,568 samples per update, training at up to 1M context length, and 3.5 to 3.7B tokens per step.

2. More tasks and richer environments: a multi-task training suite spanning coding, general agents, visual and cyber, mixed across several harnesses so that gains in one capability reinforce the others.

3. More grader compute: relative comparison within each group gives long-horizon RL tasks more precise and more diverse reward signals, closes a self-improvement loop, and steers the model toward shorter paths and fewer tokens per task.

ALL of this tooling, including the environments, will be open sourced.- the environment code and training recipes, but the complete 7k+ task datasets have not yet been released.

• Coding / software engineering: Code recipes, dataset loader and rewards

• Cyber / vulnerability reproduction: ARVO environment and training recipe

• General / knowledge work: General environment, tools and training recipe

• Visual / web development: Web-development environment and grading

• Music generation: Data preparation and music scorer

• Composable mini-harnesses: Agent configurations

• Shared environment adapters: mimoagent environments

AI Twitter Recap

Open Models, Competition, and the China Gap

• Open models remain the central policy and market story: Nathan Lambert shared a congressional briefing on open-model performance, adoption, and U.S.-China competition, followed by a public summary. The broader argument resurfaced elsewhere: @Yuchenj_UW claims frontier coding capability has plateaued since Opus 4.8, while open-source models keep closing the gap at 10–50x lower cost; @ClementDelangue similarly argues APIs are overkill for many real-world use cases and that specialized models will take share. Counterpoint: @teortaxesTex argues frontier has actually split into new higher tiers, with internal models and top closed models still well ahead.

• The release cadence from Chinese labs is now difficult to dismiss: @Thom_Wolf compiled an unusually dense ~10-week run of open releases including Kimi K3, Qwen3.8-Max, DeepSeek V4-Pro, GLM-5.3, Hy4 Preview, Atria Dawn, and more. This is reinforced by a Bloomberg-sourced note via @Polymarket that startups are increasingly building custom models on open weights to cut cost and reduce dependence on OpenAI/Anthropic. The subtext across several tweets: open-weight capability is no longer confined to midsized models; multiple teams are shipping frontier-scale MoEs with credible cost-performance stories.

Xiaomi MiMo-V2.6 and RL as the New Scaling Lever

• MiMo-V2.6 is the biggest open-model release in the set: @XiaomiMiMo launched MiMo-V2.6 Pro and Flash, described as open omnimodal models with weights, technical report, RL environments, and training code. Artificial Analysis says MiMo-V2.6-Pro debuts as the top open-weights model on its Intelligence Index (46), with 1.02T total / 42B active parameters and strong cost efficiency at $0.435/M input and $0.87/M output tokens. @victormustar notes the models are under MIT license.

• What stood out technically was not just the model, but the RL stack: @eliebakouch highlighted Xiaomi’s environment/data-factory paper for generating RL tasks from open repositories with “agents in the loop” for robustness and anti-cheating. Later commentary points to a second paper and unusually high transparency: @xeophon notes Xiaomi wants to release ~7K RL environments, and @eliebakouch emphasizes the team shipped model + tech report less than a week after the final RL run. A recurring interpretation, from @bertgodel and @Thom_Wolf, is that high-quality open RL environments may now be as strategically important as pretraining corpora were in the last cycle.

• RL cost/throughput details drew attention because they compress timelines: @zephyr_z9 cites 130 hours, 75B tokens, and $2.6M for the RL run behind the result; @tianjun_zhang says the MiMo family scales RL on JAX + TPU, where scaling is “mostly a config change, not a code rewrite.” If these numbers hold up, the implication is that post-training/RL is becoming a far cheaper route to frontier-adjacent gains than many assumed.

Decision Models, Jev, and the Return of Specialized Inference

• Jev was the dominant product/theme discussion: Multiple posts converged on the same framing: this is “just” classification/routing, but with modern model intelligence and much better latency/cost. @karpathy calls it a point on the Pareto frontier for “no thinking, single token, low latency acceptable intelligence”. @willdepue describes it as a zero-shot classifier with frontier-ish intelligence, while @ClementDelangue argues the excitement shows there is large latent demand for specialized models rather than ever-larger generalists.

• The ecosystem around Jev expanded quickly: @sarah_edo built a Chrome extension that uses Jev to select and fill relevant WebMCP tools per keystroke. LangChain added Jev-as-a-judge to LangSmith; @hwchase17 and @Hacubu pushed SemIf, an open-source decision model, through the LangSmith Gateway. @omarsar0 reports using Jev to retag ~2.3K papers in 83 seconds for $0.14, with 579 high-confidence changes and manual validation of disagreements.

• The more durable takeaway is architectural: DSPyOSS argues that asking frontier agents is like managing people, while hand-writing decision-model programs is analogous to writing assembly; both extremes are useful, but brittle if overused. Several posts emphasized where these models fit best: routing, approval gates, trace scoring, tool selection, discrete document decisions, and low-cost supervision inside larger agent loops rather than as standalone “smart agents.”

Inference, Tooling, and Systems Optimizations

• Tokenizer and post-training infra both got substantive upgrades: Hugging Face’s tokenizers v1 RC claims up to 30x faster tokenization, improved multithread scaling, lower memory use, and much smaller package size; @art_zucker framed it as a new SOTA tokenization library. Separately, Halo launched as a post-training framework claiming up to 2.8x throughput over stock TRL while keeping models in native Hugging Face format.

• Inference-side engineering remains a major lever: @RisingSayak showed how KV caching is incorporated into QwenImage 2.1, separating fixed context from changing image positions and yielding a 2.55x speedup; the thread cites 50.57s → 19.86s DiT time on a warmed A100 with moderate memory overhead. vLLM published tuned serving configs for Qwen3.8-2.4T on GB300 NVL72, showing a Pareto frontier from 5K total tok/s/GPU at high throughput to 180 output tok/s/user at low latency. In video workloads, vLLM also integrated PyNvVideoCodec/NVDEC, removing CPU decode bottlenecks and reporting 2x+ throughput at 8×H100.

• Compression/quantization is still moving fast: @ZhihuFrontier summarized Tencent Hunyuan’s engineering behind packing Hy4 Preview (770B) into 214 GiB via mixed-precision quantization averaging ~2.38 bits/weight, including custom CUDA kernels in patched llama.cpp. On the edge/local side, @vikhyatk released Parakeet Redux, compressing NVIDIA’s speech model from 1.2GB to 178MB, running at 113x realtime on CPU, while beating the base model on 25-language FLEURS and staying within 0.3 WER on English.

Agents, Security, and Human-in-the-Loop Control

• Computer-use systems are becoming more productionized, but security is now central: Patrick Wardle reported a serious local-hijack flaw in Muse, arguing broad OS access makes such assistants a high-value attack surface. In contrast, DeepLearningAI highlighted Meta’s design philosophy for Muse-like agents: assume prompt injection will happen, keep real credentials away from the model, isolate tools in containers, and use an independent outbound-call gatekeeper.

• Commercial agents are also being pushed deeper into workflows: Cognition introduced Devin Cloud in Terminal and devin ssh, making the model’s VM directly accessible from the CLI and allowing handoff between Devin and the user’s machine. GitHub Copilot teased editable diffs in the desktop app, while @pierceboggan showed a Sentry-integrated canvas for moving from crash report to fix.

• A recurring systems point: inference and agent infra are shifting toward test-time compute: @sarahookr predicts compute moving from pretraining—where marginal FLOPs yield less—to test-time compute, requiring “very different infrastructure.” That theme also showed up in persistent-cache discussions for local serving, e.g. @TheZachMueller on SGLang’s multi-level hiCache (GPU/RAM/disk) for preserving KV cache across model swaps and restarts.

Top tweets (by engagement)

• Grok 4.7 release: SpaceXAI announced Grok 4.7, described as a notable improvement over 4.6 at the same price/speed. Follow-on evals were mixed: Artificial Analysis reported 56 on its Coding Agent Index with gains on DeepSWE/Terminal-Bench/SWE-Atlas-QnA, while Vals saw it rank #24 on its Vals Index, down 5 points from Grok 4.6 despite gains in legal/medical.

• OpenAI’s automated model-training workflow: A widely shared summary from @wallstengine reports that OpenAI has largely automated parts of training experimental models, including GPU kernel writing and code optimization, with internal agents collaborating and compressing some experiments from years to about a week.

• OpenAI mathematics advisory group and claims of solved open problems: OpenAI announced an independent advisory group of mathematicians to guide assessment and communication of AI advances in mathematics. Attention then shifted to the stronger claim, amplified by @AndrewCurran_ and others, that an internal OpenAI model has resolved 100+ long-standing open problems across mathematics. This was among the most consequential but least independently evaluated items in the set.

• Open-sourcing of valuable data assets: @ClementDelangue highlighted Eidon AI open-sourcing 1,274 hours of egocentric robotics data (13,451 recordings) as a rare case of a startup preserving impact for the community after shutdown.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Qwen-Image 2.1 and Tiny Open Image Models

• Qwen-Image-2.1 released! (Activity: 2485): Qwen-Image-2.1 was released with open weights as a unified 7B image generation/editing model, positioned as a faster, lower-cost member of the Qwen-Image series (blog, GitHub, Hugging Face). Key technical additions include native RGBA/transparent image generation and editing, support for up to 10 reference images, multi-image inference acceleration, and localized edit control for tasks like object removal, attribute changes, product/portrait-preserving edits, panoramas, infographics, typography, and virtual try-ons. Comments primarily highlight the native transparency pipeline and local-edit interface; one example uses colored circles to target three regions simultaneously for removal, hair recoloring, and clothing replacement, suggesting interest in more controllable multi-region editing workflows.

  • Qwen-Image-2.1 is reported to add native transparent image generation and transparent-image editing support, which is technically notable because alpha-channel workflows are often handled as post-processing or masking rather than directly by the image model. The linked example shows transparent-output capability: https://preview.redd.it/59fu834idoqh1.png?width=767&format=png&auto=webp&s=5fb81b135b35dac70f9d38a9995d7c1a7a2877dd

  • The model appears to support multi-region local editing via visual annotations, where circled regions can be referenced in the prompt and edited simultaneously. One example asks it to “remove the metal watch in the blue circle, change the hair in the red circle to black, and replace the area in the green circle with gray short-sleeved linen pajamas,” demonstrating combined object removal, attribute modification, and region replacement in a single edit pass: https://preview.redd.it/cvh09tyvdoqh1.jpeg?width=1242&format=pjpg&auto=webp&s=32077f7420def5bec85160e2e982d6aef5efce54

  • Several commenters highlight the model size: Qwen-Image-2.1 is described as 7B parameters, which is significantly smaller than prior Qwen image models that commenters say were over 20B. This size reduction is viewed as important for local inference feasibility, with one user specifically noting interest from the perspective of a 16GB VRAM GPU such as the RTX 5060 Ti 16GB.

• Clarification on the Qwen-image-2.1 license (Activity: 948): The image is a non-meme screenshot of a Qwen Developers X post clarifying that Qwen-Image-2.1 outputs are not considered licensed “Materials”, so users retain rights to generated images/content. This matters because the model license reportedly still contains a non-commercial restriction on use of the Materials, creating ambiguity over whether commercial image generation is allowed even if generated outputs are user-owned. Commenters welcomed the clarification, with one user saying Qwen-Image-2.1 “easily beats all current Flux models.” Another noted they can run it locally via ComfyUI int8 on a 16 GB RTX 5060 Ti peaking around 15.2 GB VRAM, but warned the Hugging Face LICENSE file may not yet reflect the clarified intent.

  • A commenter reports running Qwen-Image-2.1 locally in ComfyUI using int8 quantization on a 16 GB RTX 5060 Ti, with VRAM peaking around 15.2 GB. They describe the model as suitable for local testing but note that licensing uncertainty around generated outputs was the main blocker for broader/client use.

  • Several commenters highlight a legal/implementation mismatch: the Hugging Face README was apparently clarified, but the actual LICENSE file still contains Section 2(b) language prohibiting commercial “use” of the Materials. One user emailed model-business@notice.qwencloud.com asking whether the license text will be updated, because the tweet/README intent may not be sufficient for client or commercial work.

  • The key technical/legal distinction being debated is whether “commercial use not allowed” applies only to serving, redistributing, or monetizing the model/materials, versus also restricting outputs generated by the model. Commenters argue that until the canonical license file is updated, downstream users comparing it with permissive Apache-2.0/MIT-style model licenses may reasonably avoid commercial workflows despite the clarification.

• [MASSIVE RELEASE] Supra2-IMG - a tiny 100M text-to-image model - SOTA quality and open release! (Activity: 380): SupraLabs released Supra2-IMG, a 100M-parameter DiT text-to-image model trained from scratch in under 10 hours on a single H100 via Runpod, targeting 256×256 image generation. The provided non-cherry-picked samples used seed 0, 50 steps, CFG 3.0, and the repo includes a local inference.py workflow with claimed runtime of roughly ~20s/image on CPU and ~2s/image on GPU. Commenters highlighted the unusually strong apparent quality for a 100M-parameter model and noted that small, locally runnable text-to-image models are a welcome contrast to typical large GPU-bound systems. One commenter suggested cross-posting to r/stablediffusion for a more image-generation-focused audience.

  • Commenters highlighted the main technical implication of Supra2-IMG being a 100M parameter text-to-image model: it challenges the assumption that usable image generation requires multi-billion-parameter diffusion models and high-end GPUs. The most substantive reaction was that a model this small could plausibly run locally on low-resource consumer hardware while still producing surprisingly high perceived image quality, though no concrete benchmarks or hardware measurements were provided.

2. JEV-Style One-Token Decision Models

• I gave Jev, Laya, finetuned ModernCE and Qwen3.5 the controls to Doom (Activity: 420): A Doom/ViZDoom control benchmark compared Jev 1.13, Laya English, a finetuned ModernCE-base-nli, and a finetuned Qwen3.5-4B LoRA using text-only state from visible-object labels, bounding boxes, and HUD values, outputting one discrete action at ~5 Hz while the game ran at 35 Hz. Across 8 seeds per controller/scenario capped at 30 s, Jev led on Defend-the-Center-style performance with 5.63 mean kills and 13.03 s survival but had hosted API latency of 117.3 ms p50 / 199.8 ms p95; ModernCE and Laya were much faster locally (7.6–16.2 ms p50) but lower-performing, while Qwen3.5-4B reached 3.63 kills with ~147 ms local latency. The setup was inspired by TypeSafe’s Jev Doom demo, with more implementation detail in the author’s DGX Spark write-up. Comments were mostly skeptical rather than technical: one accused the post of being “obvious astroturfing” for Jev, while another argued Jev is essentially a scaled-up BERT-like/world-model endpoint and predicted major labs such as OpenAI and Anthropic will ship similar low-latency decision endpoints before 2027.

  • One commenter frames Jev as closer to a “glorified BERT model” with stronger world knowledge due to training-scale advantages, arguing that dataset scale is likely the differentiator rather than architecture alone. They predict major labs such as OpenAI and Anthropic will expose similar Jev-like endpoints before 2027.

  • A technical criticism argues that the comparison may rely on outdated open-source benchmarks, specifically noting that Qwen 3.5 has allegedly been available since February. The commenter suggests that using older metrics weakens any claim about relative model quality or control performance in Doom.

  • Another commenter proposes extending this kind of game-control evaluation from Doom to more complex real-time/strategy environments such as Total War or Company of Heroes, where agents would need long-horizon planning, spatial reasoning, resource management, and tactical adaptation rather than only low-level action control.

• You can use any LLM just like JEV (Activity: 381): The post describes using any GGUF model via llama.cpp as a single-token classifier by setting max_tokens/n_predict=1, enabling logprobs/top_logprobs, disabling reasoning, and prompting for constrained outputs like 1=spam / 0=not spam. In the example with Spark-X2.5-4B-Q4_K_M.gguf, the returned token logprobs are logprob(1)=-0.00456 and logprob(0)=-5.395, giving approximately 99.5% vs 0.45% by exp(logprob), with reported latency around 634 ms on a low-VRAM GPU and an estimate of 30–75 ms on H200-class hardware. The author also proposes packing multiple binary labels into one categorical token—e.g. A..P for 0000..1111—then marginalizing over token probabilities to recover per-label probabilities. Commenters noted this resembles pre-tool-call LLM classification using next-token probabilities, not a fundamentally new technique. One commenter speculated JEV may instead be an open-weight transformer with autoregressive decoding bypassed and a trained decision head over internal representations, synthetic soft-label supervision, and calibration—explaining speed and parallel probabilities without requiring a “new class of AI model”; another argued many independent classification queries can exceed the cost of having an LLM emit structured JSON, especially for 20–40 labels under ~100 ms latency constraints.

  • One commenter hypothesizes that JEV may not be a fundamentally “new class of AI model,” but rather an open-weight LLM used as a representation encoder with autoregressive decoding bypassed, followed by a trained decision/classification head. They suggest synthetic classification data generated by agent graders, disagreement preserved as soft labels, and later fine-tuning/calibration could explain the claimed speed, parallel outputs, zero output-token cost, and calibrated probability distributions.

  • A technical objection is that emulating JEV-like behavior with ordinary LLM calls may require many separate requests per input, potentially costing more and adding more latency than having a standard LLM emit structured JSON directly. One user describes a harness that runs an evaluation stage on every turn and needs roughly 20–40 questions answered within about 100ms before constructing the final system prompt, implying that request fan-out and latency dominate practicality.

3. 8GB VRAM Local Model Experiments

• Ternary Bonsai 2 27B, near top performance while fitting entirely in 8GB VRAM (Activity: 492): The image is a benchmark bar chart titled “LLM benchmark scores” (image) showing PrismML Bonsai2 Ternary 27B PTQ1 highlighted near the top of the author’s custom 18-question local-LLM benchmark, second only to Ministral3 14B Q4_K_M. In context, the post’s technical significance is that a ~7GB ternary/PTQ 27B-class model reportedly fits entirely in 8GB VRAM on an RTX 4060, though the author notes it requires PrismML’s fork of llama.cpp rather than stock LM Studio/llama.cpp support. Commenters were split: several argued the benchmark overstates real usability, reporting that Bonsai2 loops, gets confused, and performs poorly in open-ended agentic workflows. A more nuanced tester found it technically impressive on a 12GB RTX 4070—42–50 tok/s, 32K context, vision/tool support—but unreliable as a general-purpose tool-using agent due to “analysis paralysis” and failure to stop.

  • A user testing PrismML Bonsai 2 27B PQ2_0 on a 12 GB RTX 4070 reported strong local runtime characteristics: it fit in VRAM, ran at roughly 42–50 tok/s, supported vision, structured tool calls, multi-step tools, and up to a 32K context. They also noted that with idle sleep enabled, the model released nearly all VRAM when inactive, making it practical on a shared GPU.

  • The main technical failure mode reported was agentic/tool-use reliability rather than raw performance. In broader workflows, Bonsai 2 allegedly found correct answers early but failed to terminate, continuing tool calls until it exhausted the 32K context or degraded into unnecessary probing across processes, Docker, logs, and knowledge bases—described as “analysis paralysis.”

  • Comparative user reports suggest Bonsai 2 is improved over Bonsai 1 and may be usable for bounded tasks, but still trails alternatives like Qwen 3.8 27B Q2 for practical quality. Multiple commenters argued it may be better suited to constrained workloads such as summarization, extraction, classification, or document processing rather than replacing a strong general-purpose agent.

• mini-AGI - dynamically grown (530M params currently and growing) continual learning model trained from scratch on 8GB VRAM laptop from batch-1 stream of data. (Activity: 288): mini-AGI is an experimental byte-level continual-learning LM trained from scratch on a single 8 GB VRAM laptop using batch-1 streaming over 32K-character passages, with a currently reported size of ~530M parameters and a planned 7.8B-character corpus; samples and an early scaling plot are published (samples, scaling.png). The linked repo describes a disk-paged MoE/continual-learning architecture with dense prelude blocks, recurrent adaptive-depth MoE blocks, soft top-k routing, PonderNet-like halting, rotary positions, expert growth/pruning/recombination, and lower LR for shared trunk weights to reduce forgetting (GitHub); weights are not yet released. A commenter with a related MoE growth experiment warned that newly inserted/duplicated layers can under-contribute: in their 63M A16M → 92M A22M model, duplicated layers trained on an additional 2B tokens contributed ~23× less than original layers, suggesting mini-AGI’s dynamic parameter growth may face similar optimization/credit-assignment issues (weights). Other reactions were mostly surprise at the unusual architecture and cautious respect for publishing a scaling-law plot.

  • A commenter compared the project to their own dynamic-growth experiment: a Small MoE inflated from 63M A16M to 92M A22M by duplicating layers. After pretraining the base on 2B tokens, duplicating 50% of layers (8 → 12), and training another 2B tokens with higher LR on inserted layers, tests suggested the added layers contributed roughly 23x less than original layers—possibly because they saw fewer tokens and received weaker error signal. They warned the mini-AGI expansion approach may encounter similar underutilization of newly added parameters; weights were shared at Hugging Face.

  • One technical suggestion questioned whether the setup truly uses effective batch size 1 with no gradient accumulation, since that strongly affects gradient noise and continual-learning dynamics. The commenter proposed adding a multi-token prediction head during training—not necessarily for inference—to extract more gradient signal per streamed sample, potentially improving generalization and acting as regularization while preserving the batch-1 stream constraint.

  • Another commenter noted the presence of a scaling law graph, implying the project is tracking growth/training behavior quantitatively rather than only demonstrating an ad hoc expanding model. A user also expressed interest in reproducing the setup on an RTX 3090, suggesting the method may be practically testable beyond the original 8GB VRAM laptop constraint.

Less Technical AI Subreddit Recap

1. Claude Reasoning Budgets and Usage Limits

• It’s time to cancel your subscriptions - Anthropic is silently nerfing Claude’s reasoning budget while telling you it’s the same model (Activity: 2483): A linked X analysis claims a 65-day sample of 43,000+ Claude Code invocations shows Anthropic is serving much smaller hidden “thinking” budgets than benchmark settings: 39% of Fable 5/Claude calls allegedly used 0 thinking tokens, median invocation used only 123, while public benchmark-style evaluations use 16K–128K. The post further claims August saw an 18–50% drop versus July, with median thinking briefly reaching literal zero around Aug. 22, implying the deployed inference regime may be throttled independently of the advertised model identity/capability. Commenters report subjective regressions consistent with the claim: Opus allegedly making repeated obvious mistakes, forgetting instructions even in fresh conversations, and Claude app models no longer entering “thinking” mode for prompts that previously triggered it. The thread frames this as more important than weekly usage limits because the paid limit is only meaningful if the served inference budget preserves the expected capability.

  • Multiple users report a perceived reduction in Claude app “thinking” behavior: prompts that previously triggered visible reasoning no longer do, and Opus is allegedly making more instruction-following and memory errors even in new conversations. The technical concern is that Anthropic may be reducing the model’s effective inference-time reasoning budget while keeping the same model label, which would change observed capability without a visible model-version change.

  • One commenter references an “audited 43,000-call dataset” allegedly showing a silent capability reduction, framing the issue as measurable rather than anecdotal. If accurate, the key technical claim is not that the base weights changed, but that deployment parameters such as reasoning token budget, routing, or compute allocation may have been altered to reduce datacenter cost.

  • Users also compare the issue to perceived usage/compute reductions at OpenAI, speculating that major cloud capacity constraints involving Amazon or Microsoft datacenters could be driving inference cutbacks. The substantive technical hypothesis is that frontier AI providers may be dynamically throttling expensive reasoning workloads or routing more requests to cheaper execution paths during capacity pressure.

• Something is wrong with usage this week (Activity: 988): The image shows a dark-mode Usage modal for a Pro account where overall weekly usage is reported as 15%, but the current session meter is already at 97% and the product breakdown shows Cowork at 100%, implying a possible quota-accounting or UI inconsistency. The post asks whether Cowork is disproportionately consuming weekly allowance after refresh, with the user estimating only 6–7 similar sessions could exhaust the full weekly limit. Commenters report similar rapid depletion, including one using Claude Code who claims to be at 83% weekly usage after only 5–6 sessions. The tone suggests users suspect either a recent quota change, a bug, or unexpectedly high token/session accounting for Cowork/Claude Code workflows.

  • Multiple users report unusually high Claude/Claude Code usage consumption this week, with one Claude Code user reaching 83% of weekly usage after only 5–6 sessions. Another user on the $100 plan said they were maxed at 100% for current session/week despite normal usage patterns, then after reset hit 85% session usage and 11% weekly usage within 15 minutes.

  • A user on the 20x plan reported that after a weekly reset they hit the 5 hour usage limit twice in the same day, which they said had never happened before in months of use. This suggests either a metering change, backend accounting bug, or a workload/model-routing change causing far higher token/session cost than before.

2. Open-Weight Creative and Image Model Releases

• we made a 27b model for creative writing. performs as good as claude fable 5, at a 40x cheaper price, open weights. (Activity: 978): A Swiss lab announced hemmingway-1, an open-weights 27B creative-writing model targeting essays, dialogue, scripts, everyday texting, and email/text autopilot workflows via apps for macOS, Windows, and Android. They claim “frontier” writing performance with EQ-Bench 4 score 1330, allegedly near “Claude Fable 5” and above “GPT-5.5” / “Opus 4.8,” plus ~40x lower cost; details are said to be on the model card and demo/app at hemmingway.io. Technical commenters asked for deployment-relevant details: model footprint, whether outputs are watermarked, and availability of quantized weights. Another commenter requested hosting on OpenRouter to integrate it into existing inference workflows.

  • Commenters asked for deployment/model-distribution details that were not in the post: memory footprint, whether outputs are watermarked, and whether an official quantized release exists. There was also interest in availability via OpenRouter, suggesting users want API/router access rather than only a first-party interface.

  • One commenter speculated the model may be a Qwen 3.x 27B fine-tune (“i guess qwen 3.6 27b finetune?”), implying readers are trying to infer the base model architecture behind the open weights and evaluate expected behavior/cost from that lineage.

  • A user who tested the writing quality reported good prose but noted factual/local-context hallucinations: when asked to invent a life story tied to their hometown, the model fabricated a non-existent high school and referenced a highway in the wrong part of the state. They argued that if the model is positioned as frontier-level or comparable to Claude, it should handle such grounded geographical details more reliably.

• Qwen-Image-2.1 weights are available on Hugging Face (Activity: 950): Qwen-Image-2.1 model weights have been released on Hugging Face, making the image-generation model available for local or third-party inference workflows. A top technical observation notes that the model supports transparent image generation; one shared example preview is available here. Comments were mostly brief reactions: enthusiasm for Qwen and a question about whether the model permits or can generate NSFW content; no substantive benchmark or implementation discussion was provided.

  • Users noted that Qwen-Image-2.1 supports transparent image generation, which is technically relevant for workflows needing alpha-channel outputs such as product compositing, UI assets, sprites, and layered editing pipelines.

  • A ComfyUI-ready release was linked via Comfy-Org on Hugging Face: https://huggingface.co/Comfy-Org/Qwen-Image-2.1. This is relevant for users integrating the model into node-based local inference workflows rather than using the base Hugging Face weights directly.

  • One commenter raised concerns about the model license, claiming the overview suggests users cannot make fine-tunes and may not own generated images. This is a key deployment consideration for commercial or derivative-model workflows, though the exact terms should be verified against the official license text.

3. Frontier AI Expansion Into Science and Robotics

• OpenAI solved 100 open problems in math (Activity: 1439): OpenAI announced an independent Mathematics and AI advisory group after claiming rapid internal progress: a new internal model has allegedly solved 100+ long-standing open math problems, including the Navier–Stokes Millennium Prize problem. The group is meant to advise on verification, review, communication, dissemination norms, academic standards, and AI-assisted math education/research, but OpenAI explicitly says it will not advise on “how to pace our internal progress on mathematics.” Commenters focused on the significance of OpenAI excluding the advisory group from internal pacing decisions, the presence of high-profile mathematicians/physicists such as Edward Witten, and speculation that the system may be the rumored internal model “Bel”—claimed by commenters to exceed “GPT-6 Astra” and require much higher inference compute. There was also debate/speculation over whether solving many problems reduces the chance of plagiarism or luck, and whether the capability generalizes beyond mathematics.

  • One commenter links this announcement to OpenAI’s prior post on “Ten Advances in Mathematics” and notes the involvement of high-profile mathematicians/physicists such as Edward Witten, suggesting readers are expecting a similarly detailed technical writeup listing the actual solved problems and methods.

  • A technically focused thread questions the lack of specificity: commenters ask whether OpenAI has disclosed which 100 open math problems were solved, what counts as “solved,” and whether the results include verifiable proofs or only internal evaluations. This is especially important because without problem names, proof artifacts, or independent review, the claim is difficult to benchmark or reproduce.

  • One commenter claims the work involves an internal model called “Bel”, described as substantially more capable than GPT-6 Astra and allegedly using more compute at its lowest reasoning setting than Astra at maximum reasoning. They argue that solving multiple problems would reduce the likelihood of a one-off success such as memorization or chance, but also raise deployment concerns due to inference cost and uncertainty about whether the capability generalizes beyond mathematics.

• Aged like milk (Activity: 1133): The image is a non-technical social-media dunk/meme: it contrasts an older X post dismissing AI bioweapon risk as requiring someone to “build an autonomous bio lab” with a newer post claiming Anthropic has set up a Bay Area wet lab for biology research (image). The technical context is AI-biosecurity evaluation: commenters clarify that a wet lab used by humans to validate Claude’s biology-related outputs is not the same as an autonomous lab, but it still raises questions about dual-use biotech workflows and model-assisted wet-lab research. Comments push back on the implied gotcha: one side argues AI does not need a fully autonomous lab to increase bioweapon risk—humans can operationalize model guidance—while another says Anthropic’s lab is likely for controlled verification/evaluation rather than autonomous dangerous experimentation.

  • Several commenters argue the relevant biosecurity risk is not a fully autonomous lab, but human operators using capable AI systems to design or optimize biological agents, then validating the outputs in real wet labs. The key technical distinction raised is that AI-enabled biotech risk can arise from human-in-the-loop workflows rather than from an AI independently controlling laboratory robotics.

  • A commenter references recent Claude work on designing protein binders that were subsequently tested in physical wet labs, reportedly with some successful outcomes. The implication is that AI-assisted protein design with experimental validation is already an active workflow, so the post’s premise may mischaracterize the novelty or autonomy level of the system.

• Open AI robotics hiring is surging up and fast (Activity: 754): The image is a screenshot of an X post claiming OpenAI robotics hiring has expanded to 27 job listings, up from 11 in May, spanning hardware, software, data collection, and prototyping, with advertised base salaries of $177k–$500k before equity. In context, the Reddit post frames this as a possible OpenAI re-entry into robotics after shutting down its earlier robotics group in 2020, but the image itself is a hiring-signal screenshot rather than a confirmed humanoid product announcement. Commenters debate whether this implies imminent humanoid development: some argue LLM/VLM systems plus robot bodies are now technically ready and supply chain is the main bottleneck, while others note 27 roles is still small and may indicate exploratory integration of frontier models into existing robot platforms rather than a full-stack humanoid push.

  • One commenter argued that humanoid robotics may scale faster than expected because modern VLM/LLM systems can potentially support robot design, simulation, and actuator R&D, citing systems like Astra and camera-sharing multimodal assistants as evidence of improving spatial/visual reasoning. They also noted a manufacturing-scaling argument from Bernt Børnich, CEO of 1X Technologies, that humanoids have only thousands of parts versus cars with hundreds of thousands, though supply-chain readiness and safety around children/pets remain major constraints.

  • A technically substantive counterpoint focused on the robotics data bottleneck: unlike LLMs, which benefited from abundant web text, robotic policies need large-scale embodied data such as millions of hours of first-person video showing humans performing actions. The commenter suggested Meta may have an advantage through smart-glasses data collection, and mentioned factories using worker-worn head cameras as an example of the kind of dataset acquisition needed for manipulation training.

  • Another commenter downplayed the hiring number, arguing that 27 robotics roles is not yet a large deployment-scale push and may indicate an exploratory effort to integrate Astra-like/future multimodal models with existing robot platforms rather than build a full humanoid stack immediately. This frames the hiring surge as likely focused on model-to-robot integration and R&D rather than near-term mass production.