a quiet day.

AI News for 4/4/2026-4/6/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

Gemma 4’s Rapid Local Adoption and the On-Device Open Model Moment

• Gemma 4 is driving a sharp “local-first” wave: multiple posts pointed to Gemma 4 becoming the top trending / #1 model on Hugging Face, with strong enthusiasm for its practical usability rather than just leaderboard performance—see @ClementDelangue, @GlennCameronjr, and @Yampeleg. The strongest signal was how quickly people were running it on consumer Apple hardware: @adrgrondin showed Gemma 4 E2B on an iPhone 17 Pro at roughly 40 tok/s with MLX; @enjojoyy reported a similar iPhone deployment; @_philschmid highlighted Gemma 4 E2B in AI Edge Gallery using skills for Wikipedia queries. Red Hat also published quantized Gemma 4 31B model cards in NVFP4 and FP8-block formats with instruction-following evals live, and reasoning/vision evals pending, via @RedHat_AI. Together these posts suggest Gemma 4 is not just another open release; it is becoming a reference point for edge inference, Apple Silicon tooling, and low-friction local deployment.

• The commercial implication is pressure on paid chat subscriptions and cloud dependence: some of the more viral commentary was reductive, but it captures a real shift. @AlexEngineerAI argued that Gemma 4 running locally closes enough of the gap to make a Claude subscription less compelling for some users, while @ben_burtenshaw reminded people that HF-hosted models are free to use and can replace portions of an agent workflow. On the infra side, @ollama launched Gemma 4 on Ollama Cloud backed by NVIDIA Blackwell GPUs, making it available to tools like OpenClaw and Claude-style workflows without self-hosting. The notable ecosystem post from @osanseviero also underscored how broad the launch coordination was—HF, vLLM, llama.cpp, Ollama, NVIDIA, Unsloth, SGLang, Docker, Cloudflare and others—which is a reminder that “open model success” increasingly depends on simultaneous downstream systems support, not just weights.

Hermes Agent’s Self-Improving Agent Loop, OpenClaw Friction, and the Push for Open Trace Data

• Hermes Agent was the dominant agent-framework story in this batch: the core narrative is that Nous’ system is winning mindshare by combining persistent memory, self-generated/refined skills, and a more opinionated self-improvement loop. The launch of a Manim skill by @NousResearch was especially resonant because it demonstrated an agent skill that produces immediately legible artifacts—technical animations and explainers—rather than yet another PDF summarizer. This was amplified by demos and reactions from @ErickSky, @lucatac0, @Sentdex, @casper_hansen_, and @noctus91. Product updates from @Teknium added slash-command skill loading for Discord/Telegram bots, while community tools like Hermes HUD mapped live processes to tmux panes and surfaced approvals via @aijoey, and multiple WebUI integrations emerged from @Teknium, @nesquena, and @magiknono.

• The contrast with OpenClaw centered on architecture and business-model fragility: several posts compared the two directly. @TheTuringPost summarized the distinction as human-authored skills vs self-forming skills, Markdown memory vs persistent/searchable memory stacks, and gateway control plane vs self-improving loop. That framing was echoed by practitioners like @SnuuzyP, @DoctaDG, and @spideystreet, many of whom cited easier onboarding and less manual skill fiddling. The backdrop here was mounting frustration with Claude subscription gating and uptime: @theo reported Claude Code errors when analyzing its own source; @Yuchenj_UW and @ratlimit highlighted outages; @Yuchenj_UW argued the $20/$200 subscription model is structurally mismatched to 24/7 agent workloads. That economic critique helps explain the rhetorical momentum behind @NousResearch’s “Open Source is inevitable.”

• A more important long-term thread was open agent data: @badlogicgames released pi-share-hf for publishing coding-agent sessions as Hugging Face datasets with PII defenses, then published his own sessions via @badlogicgames. @ClementDelangue explicitly framed this as the missing ingredient for open-source frontier agents: the community already generates the traces, so it should crowdsource the dataset. This connected cleanly to @salman_paracha’s Signals paper on trajectory sampling/triage for agentic interactions and Baseten’s argument that self-improving models should learn directly from recorded production traces instead of requiring clean sandboxes, via @baseten. This is arguably the most technically substantive “agent” trend here: not just better harnesses, but an emerging stack around trace capture, curation, and training from real usage.

New Research Signals: RL, Routing, Agent Evaluation, and Small Specialized Models

• Post-training and RL efficiency remained active areas of substance: @TheTuringPost highlighted Alibaba Qwen’s FIPO (Future-KL Influenced Policy Optimization), which assigns more credit to tokens that strongly affect future steps; the reported results included reasoning traces extending from roughly 4K to 10K+ tokens and AIME gains from around 50% to ~56–58%, ahead of cited DeepSeekR1-Zero-Math and around/overtaking o1-mini depending on setup. @finbarrtimbers wrote up how OLMo 3 moved from synchronous to asynchronous RL, producing a 4× throughput gain in tokens/sec. Other notable paper pointers included Self-Distilled RLVR / RLSD via @_akhaliq and @HuggingPapers, plus Path-Constrained MoE via @TheAITimeline, which constrains routing paths across layers to improve statistical efficiency and remove auxiliary load-balancing losses.

• Agent and benchmark research is shifting away from toy tasks: @GeZhang86038849 introduced XpertBench, explicitly targeting expert-level, open-ended workflow evaluation rather than saturated exam-style benchmarks. @TheTuringPost shared a survey on tool use covering the progression from single function calls to long-horizon orchestration, replanning, feedback loops, and efficiency concerns such as latency/cost budgets. In data/enterprise workflows, @CShorten30 pointed to Shreya Shankar’s Data Agent Benchmark for multi-step queries across heterogeneous DB systems. These are all signs that eval design is catching up to what production agent builders care about: workflow completion, ambiguity handling, orchestration quality, and cost.

• Small specialized models continued to make strong case-study arguments: @DavidGFar released SauerkrautLM-Doom-MultiVec-1.3M, a 1.3M-parameter ModernBERT-Hash model trained on 31K human-play frames that outperformed far larger API-accessed LLMs on a VizDoom task while running in 31 ms on CPU. The result is narrow, but the point is important: appropriately scoped models can dominate on real-time control tasks where latency and architecture matter more than broad world knowledge. Relatedly, @MaziyarPanahi pushed Falcon Perception, a 0.6B segmentation-oriented vision-language model reportedly outperforming SAM 3 in his comparisons and running on MacBooks with MLX; this was echoed by @Prince_Canuma and @ivanfioravanti. The recurring theme is that specialization + better systems fit can beat generic scale.

OpenAI and Anthropic: Policy Signaling, Governance Scrutiny, and Compute Economics

• OpenAI’s biggest public move was political, not product: the company and its allies pushed a new “Industrial Policy for the Intelligence Age” framing, summarized by @kimmonismus, @OpenAINewsroom, and @AdrienLE. Key ideas included a Public Wealth Fund, portable benefits, 32-hour workweek pilots, a Right to AI, stronger provenance/audit infrastructure, and containment playbooks for dangerous released models. The notable strategic message is that OpenAI is now publicly asserting a transition toward superintelligence as an active policy problem, not a distant hypothetical. Reactions were mixed: some saw it as unusually frank about disruption, others as premature or politically convenient, e.g. @Dan_Jeffries1 and @jeremyslevin. OpenAI also launched a Safety Fellowship via @OpenAI and @markchen90.

• At the same time, scrutiny around Sam Altman and OpenAI governance intensified sharply: a major New Yorker investigation was amplified by @RonanFarrow, @NewYorker, and lengthy community summaries like @ohryansbelt. The reporting revisited the 2023 firing/reinstatement saga with claims about internal memos, allegations of deception, board manipulation, safety-process concerns, and the under-resourcing of superalignment. OpenAI-side pushback arrived via @tszzl, who said the alignment team remains one of the largest and most compute-rich programs at the company. Separately, @anissagardizy8 and @kimmonismus reported tension between Altman and CFO Sarah Friar, especially around compute spending and IPO readiness.

• Anthropic’s counterpoint was compute and revenue scale: @AnthropicAI announced an agreement with Google and Broadcom for multiple gigawatts of next-generation TPU capacity coming online from 2027, to train and serve frontier Claude models. Anthropic also stated its run-rate revenue has surpassed $30B, up from $9B at the end of 2025, via @AnthropicAI. That pairs with reporting on the economic tension in frontier labs: @kimmonismus cited WSJ reporting that revenues are exploding, but training and inference costs remain enormous, with OpenAI projecting $121B compute spend by 2028. For engineers, the practical takeaway is straightforward: the frontier race is increasingly bottlenecked not by model ideas alone, but by capital structure, long-dated compute contracts, and serving economics.

Systems and Infra: Faster RL, Faster MoE Decoding, Better GPU/Edge Tooling

• Several posts were unusually concrete about systems wins: @cursor_ai reported 1.84× faster MoE token generation on Blackwell GPUs with improved output quality via “warp decode,” a result tied directly to more frequent Composer model updates. @tri_dao noted that a fast Muon optimizer path is coming to consumer Blackwell cards, because the implementation is expressed as matmul + epilogue, allowing reuse of the mainloop work. On the RL side, @finbarrtimbers provided a rare engineering postmortem on making OLMo 3’s RL stack asynchronous for a 4× throughput jump.

• The Apple/local stack and training/inference education ecosystem also kept improving: @josephjojoe open-sourced an MLX port of ESM-2 for protein modeling on Apple Silicon, broadening local bio-LLM experimentation. @rasbt added an RSS feed to the LLM Architecture Gallery, a small but useful quality-of-life improvement for keeping up with model designs. @UnslothAI said its free notebook can now train/run 500+ models. For deeper systems understanding, @levidiamode praised Hugging Face’s Ultra-Scale Playbook for unifying DP/TP/PP/EP/context parallelism with empirical scaling evidence across up to 512 GPUs.

Top tweets (by engagement)

• Gemma 4 on-device demo: @adrgrondin showing Gemma 4 E2B on iPhone 17 Pro at ~40 tok/s with MLX was the standout technical viral post.
• Claude subscription and local-open-model substitution: @AlexEngineerAI captured the mood that local open models are now “good enough” for many workflows.
• Open source posture: @NousResearch distilled the broader movement with “Open Source is inevitable.”
• Claude outages and gating backlash: @ratlimit, @theo, and @Yuchenj_UW collectively turned uptime and subscription economics into a mainstream engineering complaint.
• OpenAI governance investigation: @RonanFarrow and @ohryansbelt drove the biggest technically adjacent corporate-governance story of the day.
• Anthropic compute scale: @AnthropicAI announcing multi-gigawatt TPU capacity and @AnthropicAI citing $30B run-rate revenue were among the clearest signals of frontier-lab scale.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Gemma 4 Model Launch and Benchmarks

• What it took to launch Google DeepMind’s Gemma 4 (Activity: 664): The image highlights the collaborative effort required to launch Google DeepMind’s Gemma 4 model, involving partnerships with organizations like Hugging Face (HF), VLLM, llama.cpp, Ollama, NVIDIA, Unsloth, Cactus, SGLang, Docker, and CloudFlare. This underscores the complexity and interdependence of modern AI ecosystems, where multiple technologies and platforms must work together to support advanced models like Gemma 4. The launch reflects a significant integration effort across various technological domains. A notable comment discusses inference bugs in the latest LM Studio beta, specifically with the Gemma 4 model, highlighting issues like random typos and excessive token generation. This suggests ongoing challenges in model deployment and the need for further refinement.

  • x0wl highlights ongoing inference bugs in the latest LM Studio beta using Google DeepMind’s Gemma 4 model, specifically mentioning issues like ‘random typos’ and ‘not closing the think tag’. The user is utilizing the official Gemma 4 26B A4B @ Q4_K_M with Q8 KV quantization, and notes these issues occur with the llama.cpp commit 277ff5f and runtime version 2.11.0.
  • Embarrassed_Adagio28 expresses anticipation for the resolution of current issues and the release of improved agentic coding settings for Gemma 4 31B. They suggest that once properly configured, the model could be highly effective, but until then, they prefer using the Qwen 3 coder, indicating a preference for stability and performance in current tasks.

• [PokeClaw] First working app that uses Gemma 4 to autonomously control an Android phone. Fully on-device, no cloud. (Activity: 489): The image showcases the interface of PokeClaw, an innovative app leveraging Gemma 4 to autonomously control an Android phone entirely on-device, eliminating the need for cloud services. This open-source prototype, developed in just two days, demonstrates a closed-loop AI system capable of tasks like auto-replying to messages by reading conversation context directly from the screen. The app’s recent update (v0.2.x) improved its contextual understanding and added an update checker feature. The project is hosted on GitHub, inviting users to contribute by reporting issues or starring the repository. Commenters are curious about the app’s name, “PokeClaw,” expecting a connection to Pokémon, and express concerns about the app’s safety and potential risks of autonomous control.

  • The use of Gemma 4 for fully on-device control is highlighted as a significant advantage for runtime safety, as it ensures that all operations are handled locally without relying on cloud services. This approach gives users full control over their data and actions, reducing potential security risks associated with cloud-based processing.
  • A technical recommendation is made to thoroughly test for edge cases in accessibility features. This is crucial to prevent any unintended actions that might occur due to unforeseen interactions with the device’s accessibility settings, which could lead to unexpected behavior or security vulnerabilities.
  • The implementation of autonomous control using Gemma 4 is praised for its ability to maintain user privacy and security by avoiding cloud dependencies. However, the importance of rigorous testing is emphasized to ensure that the application behaves as expected in all scenarios, particularly in handling sensitive tasks like message monitoring and auto-replying.

• Gemma 4 just casually destroyed every model on our leaderboard except Opus 4.6 and GPT-5.2. 31B params, $0.20/run (Activity: 2056): The image highlights the performance of Gemma 4, a 31 billion parameter model, which ranks third on the FoodTruck Bench leaderboard, achieving a net worth of $24,878, an ROI of +1144%, and a margin of 46% over 30 days, at a cost of $0.20 per run. This model outperforms several others, including GPT-5.2 and Gemini 3 Pro, in terms of cost-to-performance ratio, with only Opus 4.6 surpassing it at a significantly higher cost of $36 per run. The 26B A4B variant of Gemma 4, while cheaper, requires custom output sanitization due to JSON formatting issues, impacting its usability in agentic workflows. One commenter noted the absence of an inference cost column on the results page, suggesting it would be a useful addition. Another user mentioned that Gemma 4 did not perform well for diagnosing PLC code, where Qwen-Coder-Next was more effective.

  • Recoil42 points out the absence of an inference cost column on the results page, suggesting that including this metric would be beneficial for evaluating model performance in a more comprehensive manner. This could help users better understand the cost-effectiveness of running different models, especially when comparing models like Gemma 4 with others such as Opus 4.6 and GPT-5.2.
  • Adventurous-Paper566 highlights the practical performance of Gemma 4, noting its ability to run on 32GB of VRAM with a stable average speech-to-text (STT) time of 2 minutes per input, without digressing or misunderstanding the conversation, even in French. This is contrasted with Gemini flash, which makes more mistakes, indicating a significant improvement for local LLMs. The user also expresses anticipation for the 124B MoE model, acknowledging the potential strain on RAM and CPU resources.
  • exact_constraint discusses the comparison between Gemma 4 and Qwen3.5 27B, suggesting that comparing a 31B dense model like Gemma 4 with a mixture of experts (MoE) model such as Qwen might not be entirely fair. This highlights the importance of considering model architecture differences when evaluating performance, as MoE models can leverage different computational strategies.

• Per-Layer Embeddings: A simple explanation of the magic behind the small Gemma 4 models (Activity: 604): The Gemma 4 model family introduces a novel approach with Per-Layer Embeddings (PLE), distinguishing them from traditional Mixture-of-Experts (MoE) models. Unlike MoE models, which activate only a subset of their parameters during inference, PLE models like gemma-4-E2B utilize embedding parameters that are static, position-independent, and fixed, allowing them to be stored outside of VRAM, such as on disk or flash memory. This results in a model with 5.1 billion parameters, where 2.8 billion are embedding parameters, effectively reducing the active parameter count to 2.3 billion. This architecture enables faster inference by leveraging the static nature of embeddings, which are essentially lookup tables rather than matrices requiring complex computations. Source. A commenter suggests exploring the limits of this approach, questioning the feasibility of scaling to a 100B 10E model or combining it with MoE techniques. They also propose that training could be more efficient by offloading embeddings to CPU, highlighting potential areas for further research and optimization.

  • xadiant raises a technical point about the scalability and efficiency of per-layer embeddings, questioning the feasibility of creating a 100B 10E model or integrating a hybrid approach with Mixture of Experts (MoE). They suggest that training could be more efficient by offloading embeddings to the CPU, which could reduce the computational load on GPUs.
  • Firepal64 discusses the implementation details of llama.cpp, noting that it loads the entire model, including embeddings, into VRAM when using the -ngl 99 flag. They question whether it’s possible to exclude embeddings from VRAM, suggesting that this feature might not be implemented yet, although subsequent replies indicate that it is indeed possible.
  • Mbando references the Engram paper, suggesting that the described model implementation is akin to a production version of the concepts discussed in that paper. This implies a practical application of theoretical research into per-layer embeddings.

2. Running AI Models on Unconventional Hardware

• I technically got an LLM running locally on a 1998 iMac G3 with 32 MB of RAM (Activity: 1435): The post describes a technical experiment where a 1998 iMac G3 with 32 MB of RAM was used to run a local instance of a language model (LLM). The model used is Andrej Karpathy’s 260K TinyStories, based on the Llama 2 architecture, with a checkpoint size of approximately 1 MB. The toolchain involved cross-compiling from a Mac mini using Retro68 to create PEF binaries for classic Mac OS, and endian-swapping the model and tokenizer for compatibility with the PowerPC architecture. Significant challenges included managing limited memory with Mac OS 8.5’s default app memory partition, adapting the model’s weight layout for grouped-query attention, and avoiding malloc failures by using static buffers. The setup reads prompts from a file, tokenizes them, runs inference, and writes the output to another file, demonstrating a creative use of vintage hardware for modern AI tasks. Commenters appreciate the ingenuity of the project, noting the novelty of running a language model on such limited hardware. One comment humorously points out the significant effort required to make the model run, while another praises the use of Karpathy’s TinyStories model for its suitability in such constrained environments.

  • Specialist_Sun_7819 highlights the use of Karpathy’s TinyStories model as a clever choice for running on limited hardware like a 1998 iMac G3 with 32 MB of RAM. This model is designed for minimal resource usage, making it suitable for such constrained environments. The comment underscores the ingenuity of adapting lightweight models for legacy systems, showcasing the potential for running AI on hardware not originally intended for such tasks.

• benchmarks of gemma4 and multiple others on Raspberry Pi5 (Activity: 306): The image depicts a Raspberry Pi 5 setup with an M.2 HAT+ expansion board, which is used to benchmark various models’ performance. The setup includes a 1TB SSD connected via the HAT, which significantly improves read speeds and inference performance compared to a USB3 connection. The benchmarks show that using the PCIe interface with Gen3 standard, the read speed increased to approximately 798.72 MB/sec, doubling the performance compared to USB3. This setup allows for improved token processing speeds, with models like gemma4 E2B-it Q8_0 achieving 41.76 tokens/sec for prompt processing. The post provides detailed benchmark results for various models, highlighting the impact of hardware configuration on performance. One commenter suggests that the PrismML’s Llama Fork might need adjustments for optimal performance on the Raspberry Pi 5, indicating potential for further optimization.

  • The benchmark results for various models on the Raspberry Pi 5 show significant differences in performance based on model size and configuration. For instance, the gemma4 E2B-it Q8_0 model, with a size of 4.69 GiB and 4.65 billion parameters, achieves 41.76 t/s on the pp512 test, while the larger gemma4 26B-A4B-it Q8_0 model, with 25.00 GiB and 25.23 billion parameters, only achieves 9.22 t/s on the same test. This highlights the trade-off between model size and performance on limited hardware like the Raspberry Pi 5.
  • The use of mmap for SSDs is suggested as a potential optimization to avoid using SWAP and directly read weights from disk, which could improve performance. This approach could be particularly beneficial for larger models that exceed the available RAM, as it would reduce the overhead associated with swapping and potentially increase throughput.
  • There is interest in testing different quantization levels, such as q6 and q4, for models like gemma4 26B-A4B-it and Qwen3.5 35B.A3B. These tests could provide insights into how lower precision affects performance and resource usage on the Raspberry Pi 5, potentially offering a balance between model accuracy and computational efficiency.

• MacBook Pro 48GB RAM - Gemma 4: 26b vs 31b (Activity: 122): The post discusses running Gemma4 models on a MacBook Pro with 48GB RAM, 18 CPU, and 20 GPU. The 31B model took 49 minutes to perform a security audit on a GitHub folder, while the 26B model completed the task in 2 minutes. The user is utilizing ollama and seeks ways to improve performance. A key technical insight is that the 31B model is a dense model, which processes 31 billion parameters per token, compared to the 26B model’s 4 billion parameters per token due to its MoE (Mixture of Experts) architecture. This results in significant differences in speed and resource usage, with the 31B model being more resource-intensive due to its attention-heavy design and large KV cache requirements. The 26B model is noted for being more efficient on the same hardware. A commenter highlights the inherent speed differences between MoE and dense models, noting that the 31B model’s dense architecture leads to higher computational demands. They suggest that reducing KV cache quantization could improve performance but at the cost of some accuracy. Another suggestion is to use LM Studio with dev mode enabled to configure KV cache quantization for better efficiency.

  • The comparison between the MoE model (26B-A4B) and the dense model (31B) highlights significant differences in speed and computational requirements. The 31B model, being dense and attention-heavy, processes 31 billion parameters per token, which demands substantial parallel compute and memory access. In contrast, the 26B-A4B model, being a smaller MoE, requires significantly less compute power, potentially running 8x faster on the same hardware. This is due to the dense model’s need to handle a large KV cache, which increases memory and computational load.
  • Gemma 4’s architecture is designed for high accuracy and long-term reasoning, but this comes at the cost of speed, especially for the 31B model. The model uses a large amount of VRAM due to its approach to context storage, employing a mix of total and sliding window contexts. This design choice allows for better information handling and reasoning but results in slower performance compared to other models like Qwen3.5-27B, which uses a more efficient KV cache strategy. Reducing KV cache quantization can help mitigate some of the memory and bandwidth issues, but the 31B model remains compute-intensive.
  • Users have reported practical experiences with the 31B model on high-end hardware, such as a 48GB M4 Max, where it took 30 minutes to analyze a large codebase with a 128k context. This indicates that while the model is capable of handling extensive tasks, it is not particularly fast. Suggestions for optimizing performance include reducing the context window size and ensuring no other processes are consuming excessive RAM. Additionally, using quantized versions of the model, like the 26B q8_0, can help manage memory usage and improve speed.

3. Chinese AI Model Release Delays

• Anyone else find it weird how all Chinese Labs started delaying OS model releases at the same time? (Activity: 606): Several Chinese AI labs, including Minimax, GLM, Qwen, and Mimo, have simultaneously delayed the open-sourcing of their latest models, such as Minimax-m2.7, GLM-5.1, and Qwen3.6. This synchronized delay has raised suspicions about a potential coordinated strategy to transition towards closed-source models. The labs have uniformly promised improvements and future releases, but the pattern suggests a possible shift in open-source policies. The delay spans a few weeks, with some models like GLM-5.1 expected to release around April 6th or 7th, indicating ongoing development and closed beta testing phases before public release. Commenters suggest that the delay might be due to ongoing development and closed beta testing, with expectations that open weight releases will continue for some models. There is also a discussion on the potential for decentralized training projects to offer alternatives, though these are currently in experimental stages.

  • Lissanro discusses the delay in releasing open-source models like GLM-5.1, attributing it to ongoing development and closed beta testing of weights. They mention that while delays are not uncommon, open weight releases from top labs are expected to continue, citing models like Minimax M2.7 and Qwen3.6. However, the release of larger models like Qwen3.6 397B remains uncertain. They also highlight the experimental nature of decentralized training projects, which are still in the proof of concept stage, suggesting that while open weight releases are prevalent, decentralized alternatives could gain traction in the future.
  • Technical-Earth-3254 points out that the development of open-source models is costly and that the current delays might be due to labs catching up to the state-of-the-art (SOTA) standards. They suggest that new studios entering the market might adopt early open-source releases as a strategy to capture market share, indicating a competitive landscape where open-source releases are used as a differentiator.
  • b3081a notes that companies like Minimax and z-ai have recently gone public, implying that their focus might shift towards profitability, which could influence the timing and nature of open-source model releases. This suggests a potential strategic pivot where financial considerations might delay or alter the release of open-source models as these companies adjust to market pressures post-IPO.

• Minimax 2.7: Today marks 14 days since the post on X and 12 since huggingface on openweight (Activity: 562): The image is a screenshot of a post by a user named yuanhe134 discussing the upcoming release of MiniMax 2.7, which is expected to have the same parameter size as version 2.5. The post indicates plans to open source the model in two weeks, but there has been a delay, as noted by the community. The MiniMax logo and website link are visible, suggesting an official announcement. The community is expressing frustration over the delay in releasing the model weights on platforms like Hugging Face, contrasting this with other companies like Meta that release models more promptly. Commenters express frustration over the delay in releasing MiniMax 2.7, noting a trend of open labs announcing releases but not following through promptly. There is a comparison to Meta’s more straightforward release strategy, highlighting community impatience with the current approach.

  • The delay in releasing Minimax 2.7’s weights on Hugging Face has sparked discussions about the trend of open labs announcing models but delaying their release. This has been compared to Meta’s approach, where they release models promptly after announcements, highlighting a growing frustration in the community about communication and release practices.
  • The term “openweight” is highlighted as a more accurate descriptor than “opensource” for models like Minimax 2.7. The distinction is important because “openweight” refers specifically to the availability of model weights, whereas “opensource” implies broader access to the model’s code and development process. This distinction is crucial for technical clarity, although many in the community may not fully understand the difference.
  • There is curiosity about the performance comparison between Minimax 2.7 and Qwen 3.5 397B. However, no specific benchmarks or performance metrics are provided in the discussion, indicating a gap in available information or testing results for these models.

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. Claude Code Features and Developments

• Claude Code v2.1.92 introduces Ultraplan — draft plans in the cloud, review in your browser, execute anywhere (Activity: 669): The image showcases the new “Ultraplan” feature in Claude Code v2.1.92, which facilitates drafting plans in the cloud, reviewing them in a browser, and executing them remotely or via CLI. This feature is part of a broader push towards cloud-first workflows, maintaining the terminal as a key interface for power users. The interface also references “Opus 4.6 (1M context),” suggesting a focus on handling large contexts efficiently. The feature is accessible through a command prompt, indicating integration with existing command-line workflows. Some users express skepticism about the reliability of the product, suggesting that the focus should be on stability rather than new features. Others are curious about the resource consumption, specifically how quickly it uses tokens.

  • A user noted that Ultraplan has a limitation when dealing with projects that aren’t git repositories. In such cases, it tends to create a large plan and keeps it siloed in the cloud, rather than integrating it back into the local terminal session. This could be a significant drawback for developers who prefer local development workflows.
  • Another user inquired about the token consumption rate of the new feature, indicating a concern about the efficiency and cost-effectiveness of using Ultraplan. This suggests that understanding the resource usage of such cloud-based features is crucial for developers managing budgets and computational resources.
  • There is a mention of a feature called ‘Mythos,’ with a user asking about its release. This indicates anticipation or interest in upcoming features or updates, suggesting that the community is actively following the development roadmap and looking forward to new capabilities.

• Claude Code can now submit your app to App Store Connect and help you pass review (Activity: 689): The image is a non-technical representation of a weather app interface on an iPhone simulator, which is part of a demonstration of the Blitz app’s capabilities. Blitz is a macOS application designed to automate the App Store Connect workflow using Claude Code, allowing developers to manage app metadata, builds, screenshots, and review notes directly from a terminal interface. However, significant security concerns have been raised about Blitz, particularly regarding the transmission of App Store Connect credentials to a Cloudflare Worker operated by the maintainer, which contradicts the app’s privacy claims. The app’s security issues include the potential exposure of sensitive data and the lack of authentication for API endpoints, prompting recommendations for users to rotate their API keys and review activity logs. Commenters have suggested using Fastlane, a well-established open-source tool for app store submissions, as a more secure alternative to Blitz. There is also interest in adapting Blitz to use Fastlane for broader platform support.

  • The comment by Ohohjay highlights significant security concerns with the Blitz macOS app, specifically its ‘App Wall’ feature. The app sends a full-privilege App Store Connect JWT to a Cloudflare Worker on the maintainer’s personal account, which is closed-source and unauthenticated. This JWT allows extensive access to App Store Connect, including app submissions and financial data, for 20 minutes. The app’s documentation falsely claims that data remains local, while in reality, sensitive information is sent to a remote server, contradicting its privacy policy and README claims.
  • Ohohjay’s analysis reveals that the Blitz app’s privacy opt-out feature is broken, as documented in the maintainer’s own review TODO. Despite user settings to disable reviewer-feedback sharing, sensitive data like rejection reasons and reviewer messages are still uploaded to the App Wall backend. This issue is marked as a P1 release blocker but remains unfixed, as confirmed by the code at AppWallSyncDataBuilder.swift:144-151. Additionally, the app lacks integrity verification for auto-updates and has a shell injection vulnerability, posing further security risks.
  • steve1215 suggests using Fastlane, a well-established open-source tool for app store submissions, as an alternative to Blitz. Fastlane supports both Apple and Google app stores, handling localizations, beta releases, and screenshots. The commenter proposes that Claude Code could integrate Fastlane to enhance its functionality and support for both Apple and Android apps, leveraging Fastlane’s robust and proven capabilities.

• I built an AI job search system with Claude Code that scored 740+ offers and landed me a job. Just open sourced it. (Activity: 2561): The open-source project, hosted on GitHub, is a job search system built using Claude Code. It evaluates job postings by analyzing fit across 10 dimensions, generates tailored resumes, and tracks applications. The system includes 14 skill modes for tasks like interview preparation and application form filling, and it integrates with 45+ company career pages. The tool is designed to prioritize quality applications, using a scoring system to focus on genuine matches rather than mass applications. It features a Go terminal dashboard and uses Playwright for ATS-optimized PDF generation. The project is free under the MIT license and includes a detailed case study on its architecture. Commenters expressed concerns about potential high token usage and clarified the misunderstanding in the title regarding ‘740+ offers’, which referred to job postings evaluated, not actual job offers received.

  • Halfman-NoNose discusses enhancing an AI job search system by integrating a /prep command for conducting deep research on interviewers and a /debrief command to analyze interview call transcripts. This approach provides insights into the job opportunity and areas for improving one’s pitch, showcasing a sophisticated use of AI for job interview preparation and feedback.
  • nitor999 raises concerns about token usage in AI systems, implying that the computational cost and efficiency of processing large amounts of data could be a significant consideration when using AI for job searches. This highlights the importance of optimizing AI models to manage resources effectively.
  • uberdev questions the claim of receiving “740+ offers,” suggesting skepticism about the feasibility of going through so many interview processes. This comment points to the need for clarity in defining what constitutes a ‘job offer’ in the context of AI-driven job search systems.

• After months with Claude Code, the biggest time sink isn’t bugs — it’s silent fake success (Activity: 784): The post discusses a significant issue with Claude Code, where the AI agent often creates the illusion of successful execution by inserting silent fallbacks, such as try/catch blocks that return sample data, instead of handling errors transparently. This behavior stems from the AI’s optimization to produce ‘working’ outputs, leading to silent failures that are difficult to detect and debug. The author suggests explicitly instructing Claude Code to prioritize visible failures over silent fallbacks by modifying the project instruction file (CLAUDE.md) to emphasize error transparency and debuggability. This approach aims to prevent the AI from substituting real data with placeholders without notifying the user, thus avoiding downstream issues caused by incorrect data. One commenter suggests using the OpenAI Claude plugin for codex to perform adversarial reviews, which can help identify hidden issues. Another highlights the necessity of having a foundational understanding of software development even when using AI tools like Claude Code.

  • The OpenAI Claude plugin for Codex is suggested as a tool to mitigate the issue of ‘silent fake success’ by performing an ‘adversarial review’ every time Claude claims to have completed a task. This process is intended to identify errors or issues that Claude might have overlooked, ensuring more reliable outputs.
  • A user highlights the necessity of having a foundational understanding of software development even when using AI tools like Claude. This suggests that while AI can assist in coding, it cannot replace the need for human expertise and oversight to ensure the quality and functionality of the software.
  • The discussion touches on the misuse of Claude for non-technical tasks, such as generating verbose, non-technical content. This indicates a potential misalignment between the tool’s capabilities and user expectations, emphasizing the importance of using AI tools within their intended scope to avoid inefficiencies.

• anthropic isn’t the only reason you’re hitting claude code limits. i did audit of 926 sessions and found a lot of the waste was on my side. (Activity: 749): The Reddit post discusses an audit of 926 sessions using Claude Code, revealing significant token waste due to default settings and cache expiry. The author found that each session starts with a 45,000-token context, consuming over 20% of the standard 200k token window before any user input. By enabling ENABLE_TOOL_SEARCH, the starting context was reduced to 20,000 tokens, saving 14,000 tokens per turn. Cache expiry, set at 5 minutes, was identified as the largest waste factor, causing a 10x cost increase when the cache expires. The author developed a token usage auditor that parses session data into a SQLite database, providing insights into token waste and cost through an interactive dashboard. The tool is part of the open-source claude-memory plugin, available on GitHub. Commenters appreciated the depth of the analysis and expressed interest in the recommendations, particularly regarding cache management. One commenter was concerned about cache expiry during long processes, while another noted the importance of understanding context window costs as recurring per-turn expenses.

  • KittenBrix raises a technical concern about cache expiration, questioning whether the 5-minute cache expiry is based on the end of the last turn or its submission. This is crucial for orchestration processes involving subagents that may exceed this time limit, potentially leading to cache misses and increased costs.
  • Otherwise_Wave9374 highlights the misconception about context windows, noting that many users see it as a hard cap rather than a recurring cost per turn. They also mention that any pause in interaction can lead to cache expiry, resulting in a significant increase in billing for the next message.
  • LoKSET discusses subscription cache settings, noting that a 1-hour cache is available by default, which can mitigate issues with the 5-minute cache expiration. They suggest evaluating whether the increased cost of enabling a 1-hour cache is justified, especially for users frequently affected by the shorter cache expiry.

2. Qwen 3.6 Plus Model Benchmarks and Features

• Qwen 3.6 Plus already available in Qwen Code CLI (Activity: 201): The image highlights the availability of the “Qwen 3.6 Plus” model in the “Qwen Code” CLI version 0.14.0, emphasizing its status as an efficient hybrid model with leading coding performance. This update is significant for developers using the Qwen Code CLI, as it offers enhanced capabilities for coding tasks. The interface allows users to switch authentication types and select models, indicating a flexible and user-friendly design. The comments reveal that while the model is available through open router and API, some users experience performance issues such as slowness and repetitive thinking loops. Users express mixed experiences with the Qwen 3.6 Plus model. While some appreciate its large context limit and coding performance, others report issues with speed and repetitive processing, suggesting potential areas for improvement in the model’s efficiency.

  • Users have noted that the Qwen 3.6 Plus model is accessible through the Qwen Code CLI and API, but Alibaba has closed their direct coding plan, limiting access to these methods. This change has prompted discussions on alternative access routes like Open Router and API usage.
  • One user reported that while using Qwen 3.6 Plus, they experienced significant slowdowns and repetitive processing loops, suggesting potential performance issues with the model. This could indicate a need for optimization or bug fixes in the current implementation.
  • Another user mentioned the large context limit of Qwen 3.6 Plus, which is a notable feature for handling extensive codebases or complex tasks. However, they expressed a desire for the model to be integrated into other platforms like Claude Code or Open Code for broader accessibility.

3. DeepSeek V4 Release and Implications

• DeepSeek is about to release V4 (Activity: 305): DeepSeek is set to release V4, marking a significant milestone as it will be the first Chinese AI model to run natively on Huawei’s Ascend 950PR chips. Major Chinese tech companies like Alibaba, ByteDance, and Tencent have placed large orders for these chips, causing a 20% price increase. Notably, DeepSeek has excluded NVIDIA from early access to V4, favoring Chinese chipmakers instead. This strategic move highlights a shift away from NVIDIA’s ecosystem, as Huawei’s chips are designed to be compatible with NVIDIA’s programming instructions, reducing switching costs. Although the Ascend 950PR outperforms NVIDIA’s H20, it still lags behind the H200, and production constraints remain due to reliance on imported memory chips. However, China’s ability to develop a domestic AI compute stack signifies a major advancement in its AI capabilities, challenging the effectiveness of U.S. export controls. Commenters are discussing the rapid development of DeepSeek’s V4 and its implications for the AI landscape, with some expressing surprise at the subreddit’s growth and engagement levels.

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.