【AIニュース】グッドフライデー

We covered this yesterday, but positive Gemma reviews keep streaming in.

Early analytics from our Marc Andreesen pod are already pointing towards it being one of the top Latent Space pods of all time. We’ll hear more from the creators of both OpenClaw and Pi (and many other top Europe-origin AI tools) live from London next week. Livestream links for AIE Europe next week is now up, including a great OpenClaw song. Hit the bell to help promote it in the algorithm please and thank you!

AI News for 4/3/2026-4/4/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 Apache-licensed launch, local inference performance, and day-0 ecosystem support

Gemma 4 is the day’s defining open-model release: Google launched Gemma 4 under Apache 2.0, with multiple posts emphasizing its positioning for reasoning, agentic workflows, multimodality, and on-device use. @fchollet called it Google’s strongest open model yet and recommended the JAX backend in KerasHub; @demishassabis highlighted efficiency, claiming Gemma 4 outperforms models 10x larger on Google’s chart. Community reaction centered on the license shift: @ClementDelangue, @QuixiAI, and @googlegemma all stressed that this is a “real” open-weights release with broad downstream usability.

The ecosystem was unusually ready on day 0: Support landed immediately across vLLM (GPU, TPU, XPU simultaneously), llama.cpp (@ggerganov), Ollama (new models available), Intel hardware (Xeon, Xe GPU, Core Ultra), Unsloth (local run/fine-tune support), Hugging Face Inference Endpoints (one-click deploy), and AI Studio / Google AI Studio collateral (article link). For architecture-oriented readers, both @osanseviero and @MaartenGr shared deep visual guides covering MoE design, vision/audio encoders, and per-layer embeddings.

Local inference benchmarks were the main practical story: multiple builders showed Gemma 4 running on consumer hardware, with particular attention to the 26B A4B MoE. @basecampbernie reported 162 tok/s decode and 262K native context on a single RTX 4090 at 19.5 GB VRAM, while @Prince_Canuma showed TurboQuant KV cache cutting memory from 13.3 GB to 4.9 GB at 128K context for the 31B model, with some decode-speed penalty. There were also examples on weaker local devices: @measure_plan reported 34 tok/s for 26B-A4B on a Mac mini M4 with 16 GB, @kimmonismus argued the E4B tier brings useful AI directly to phones/laptops, and @anemll got the model onto an iPhone with Swift MLX.

Early benchmarking discourse was positive but not uncritical: @arena noted large ranking gains over Gemma 3 and 2 at similar parameter scales, suggesting progress beyond pure scaling; later, @arena put Gemma 4 31B on the Pareto frontier against similarly priced models. Some users pushed back on presentation choices: @stochasticchasm argued comparisons should be more clearly FLOP/active-parameter normalized, and @reach_vb urged the field to move beyond Arena Elo as the default score.

Hermes Agent’s rapid adoption, memory/plugin architecture, and the “harness matters” shift

Hermes Agent appears to be the breakout open-source agent harness of the day: across user reports, many developers explicitly said they had switched from OpenClaw/Openclaw to Hermes and found it more stable or more capable on long tasks. Examples include @Zeneca, @Everlier, @erick_lindberg_, and @AnomalistG. A detailed Korean thread from @supernovajunn crystallized the narrative: the edge is not just the model, but the harness + learning loop, especially autonomous skill creation, reusable procedural memory, and higher reliability floors on real tasks.

Nous shipped meaningful infrastructure, not just hype: @Teknium announced a reworked, pluggable memory system with support for Honcho, mem0, Hindsight, RetainDB, Byterover, OpenVikingAI, and Vectorize-style backends. Follow-up posts detailed the architectural cleanup: memory providers are now a dedicated plugin type, the core is more maintainable, and users can add their own providers more easily (details). Hermes also added inline diffs in the TUI (post) and provider credential pools for cycling between accounts/keys (post).

The larger theme is that agent performance is becoming a harness-engineering problem: @Vtrivedy10 described a “model-harness training loop” where teams combine harness engineering, trace collection, analysis, and fine-tuning to build domain-specific frontier performance. In a companion tweet, he argued the key raw material is massive trace data, mined by agents for failure modes and converted into training or harness improvements (trace loop). This complements Hermes’ popularity: if open models are now “good enough,” better memory, tools, evals, and self-improvement loops may dominate application quality.

There is also visible demand for open harnesses rather than closed product shells: @michael_chomsky argued Anthropic should open-source Claude Code, partly because 2025 was “the year of mediocre harnesses”; @hwchase17 made the memory angle explicit, saying memory cannot remain trapped behind proprietary APIs or proprietary harnesses.

Coding agents, rate limits, and the cognitive bottleneck of parallel agent work

The strongest user sentiment was not about raw model IQ but about operational friction: @gdb lowered the barrier to trying Codex at work by removing up-front commitment, and later said the Codex app is growing super fast (post). But at the same time, discussion around Claude Code rate limits was intense: @theo said “we need to talk about the Claude Code rate limits,” with follow-up user complaints from @kimmonismus and @cto_junior suggesting that users are hitting caps faster than expected.

A growing theme is cognitive saturation, not just compute scarcity: one of the most-engaged technical tweets was @lennysan quoting @simonw: using coding agents well can require every inch of senior engineering experience, and orchestrating four agents in parallel is mentally exhausting by mid-morning. That view showed up elsewhere: @kylebrussell praised Claude Code’s ability to drive many browser tabs for verification work, but later noted scaling gets “weird” and that 2–4 sessions still seems optimal for his brain (post).

Developers are adapting by externalizing context and observability: @jerryjliu0 described a practical setup where agents emit .md/.html artifacts to preserve context across sessions, with Obsidian as a local viewer and LiteParse replacing generic PDF parsers for better extraction from complex documents. On the observability side, LangChain shipped a Claude Code → LangSmith tracing plugin that logs subagents, tool calls, compaction, token usage, and enables org-level analysis (announcement).

There’s also growing evidence that “good enough local fallback” matters: several posts framed Gemma 4 and Hermes together as a hedge against hosted-product friction. @gregisenberg emphasized that a model this capable now runs locally and can be swapped into Claude Code, Cursor, Hermes, or OpenClaw. @kimmonismus similarly highlighted a fully local assistant on a MacBook Air M4 with 16 GB, no API keys required.

Research signals: time horizons, recursive context management, and self-distillation

METR-style “time horizon” results continue to trend upward: @LyptusResearch applied the METR time-horizon methodology to offensive cybersecurity, reporting that capability has doubled every 9.8 months since 2019, or 5.7 months on a 2024+ fit, with Opus 4.6 and GPT-5.3 Codex reaching 50% success on tasks taking human experts ~3 hours. Related commentary from @scaling01 extrapolated METR horizons to roughly 15.2 hours “today” and ~87 hours by year-end under continuation assumptions.

Long-context handling remains an active systems/research problem: @DeepLearningAI highlighted Recursive Language Models (RLMs) from MIT researchers Alex Zhang, Tim Kraska, and Omar Khattab: rather than stuffing everything into a monolithic prompt, the system offloads prompt management to an external environment, managing context programmatically. This idea resonated with practitioners: @raibaggy joked that after moving workflows to RLMs, “you have to put the harness into the harness.”

Post-training without labels/verifiers got notable attention: @BoWang87 summarized Apple’s Simple Self-Distillation (SSD) result for coding models: sample the model’s own outputs and fine-tune on them without correctness filtering, RL, or a verifier. The strongest cited gain was Qwen3-30B-Instruct: 42.4% → 55.3% pass@1 on LiveCodeBench, with especially large gains on hard problems. If robust, this suggests many code models are underperforming their latent capability due to decoding/post-training gaps rather than missing core competence.

Additional research worth flagging: @jaseweston shared a 70-page paper on reasoning over mathematical objects, spanning training data, on-policy reward models, and on-policy inference methods; @AnthropicAI published a “diff” method for surfacing behavioral differences between open-weight models; and @AndrewLampinen discussed test-time thinking as a way to retrieve and use latent knowledge from training data.

Enterprise and production AI: speech, security, access control, and real-world deployments

Microsoft’s MAI-Transcribe-1 looks competitive on STT: @ArtificialAnlys reported 3.0% AA-WER (#4 overall on its leaderboard) and ~69x real-time speed, with support for 25 languages and preview availability through Azure Speech / Foundry. Pricing was quoted at $6 per 1,000 minutes (pricing post).

Security surfaced in multiple production contexts: @simonw warned maintainers that the Axios supply-chain attack began with sophisticated social engineering aimed at a developer; @gneubig pulled out the practical lessons: stronger credential management, identity verification, and malware detection. Separately, @thinkshiv and @jerryjliu0 highlighted a joint Auth0 FGA + LlamaIndex approach to making authorization structural inside retrieval, rather than bolting it on after the fact.

Inference infrastructure and real deployments got credible examples: Baseten and OpenEvidence both claimed very large-scale production use in clinical settings, with OpenEvidence saying over 40% of U.S. physicians rely on it and Baseten powers inference for that workload (OpenEvidence, Baseten). On serving resilience, @vllm_project highlighted DP-group fault tolerance in Ray Serve LLM for vLLM WideEP deployments, complementing Elastic EP at the engine layer.

Top tweets (by engagement, filtered for technical relevance)

Agent workflow fatigue is becoming a first-class problem: @lennysan quoting @simonw on the mental cost of using multiple coding agents in parallel was the most resonant technical post in the set.

Personal knowledge bases for agents are turning into a serious pattern: @omarsar0 described a highly customized research-paper knowledge base built in markdown with semantic indexing, agent-driven curation, and interactive artifacts; a follow-up shared the system diagram (diagram).

Gemma 4 had both broad mindshare and practical credibility: engagement concentrated not only on the launch itself—@fchollet, @demishassabis—but on practical local-running claims from @ClementDelangue, @gregisenberg, and @kimmonismus.

Hermes Agent’s adoption curve is now visible in the open: the strongest evidence came less from official posts than from user migration reports and usage anecdotes, plus @Teknium’s memory-system overhaul. The pattern is notable: users increasingly credit memory + harness design, not just the base model, for the jump in utility.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. Gemma 4 Model Release and Features

Gemma 4 has been released (Activity: 3412): Gemma 4, developed by Google DeepMind, is a family of open multimodal models capable of processing text, images, and audio, with a context window of up to 256K tokens. The models are available in four sizes: E2B, E4B, 26B A4B, and 31B, supporting multilingual capabilities in over 140 languages. They feature both Dense and Mixture-of-Experts (MoE) architectures, optimized for tasks such as text generation, coding, and reasoning. Notably, Gemma 4 introduces a hybrid attention mechanism combining local sliding window and global attention, enhancing processing speed and memory efficiency for long-context tasks. The models also support native function-calling and structured tool use, facilitating agentic workflows and coding tasks. For more details, see the Hugging Face repository. One comment highlights the significance of Gemma-4’s native thinking and tool-calling capabilities, emphasizing its multimodal nature. Another provides practical guidance on running the models, including specific parameters like temperature = 1.0, top_p = 0.95, and top_k = 64, and mentions its integration with Unsloth Studio.

Gemma-4 introduces several advanced features such as native thinking, tool calling, and multimodal capabilities. It is optimized with specific parameters: temperature = 1.0, top_p = 0.95, top_k = 64, and uses <turn|> as the end-of-sequence token. Additionally, <|channel>thought\n is used for the thinking trace, enhancing its cognitive processing capabilities. More details and guides are available at Unsloth AI.

The release of Gemma-4 is significant for its seamless integration with Unsloth Studio, providing a streamlined environment for developers. All GGUFs related to Gemma-4 can be accessed on Hugging Face, offering a comprehensive resource for those looking to implement or experiment with the model.

There is anticipation for comparative analysis between Gemma-4 and other models like Qwen3.5, highlighting the competitive landscape in AI model development. This suggests a focus on benchmarking and performance evaluation to understand the strengths and weaknesses of each model in practical applications.

You can now run Google Gemma 4 locally! (5GB RAM min.) (Activity: 415): Google has released the open-source model family Gemma 4, featuring four models with multimodal capabilities: E2B, E4B, 26B-A4B, and 31B. The models excel in reasoning, coding, and long-context workflows. The 31B model is the most advanced, while 26B-A4B is optimized for speed due to its MoE architecture. Unsloth has adapted these models for local execution on devices with as little as 5GB RAM. The models can be run via Unsloth Studio, with recommended setups ranging from 6GB RAM for smaller models to 35GB RAM for the largest. No GPU is required, but it enhances performance significantly. Installation is streamlined for various OS, and a desktop app is forthcoming. More details are available in the Unsloth documentation. Commenters express excitement about the usability of Gemma 4 on older hardware, noting the impressive performance of the E2B model on a 2013 Dell laptop. There is also a discussion on the complexity of keeping up with model specifications and hardware requirements.

The recommended setups for running Google Gemma 4 locally highlight the memory and performance trade-offs across different model sizes. For instance, the E2B and E4B variants can achieve 10+ tokens per second in near-full precision with approximately 6GB of RAM, while 4-bit variants can operate on 4-5GB RAM. Larger models like the 26B-A4B require around 30GB of RAM for similar performance, with 4-bit versions needing 16GB. The 31B model, which is even larger, demands about 35GB of RAM for 15+ tokens per second in near-full precision.

A user reports that the Gemma4 E2B model performs surprisingly well on older hardware, specifically a 2013 Dell E6440 with an i5 4310 CPU and 8GB of RAM, achieving a reply speed of 8 tokens per second. This suggests that even older systems can handle smaller models of Gemma 4 for basic tasks, highlighting the model’s efficiency and adaptability for less powerful machines.

The 31B model of Google Gemma 4 has a significant memory requirement due to its KV Cache and Mixture of Experts (MoE) architecture, needing up to 40GB of VRAM to load into memory. This indicates a substantial resource demand for running larger models, which could be a limiting factor for users without access to high-end hardware.

Gemma4 - Someone at Google just merged a PR titled “casually dropping the most capable open weights on the planet” (Activity: 471): Google has merged a PR in the HuggingFace Transformers repo for a new model, Gemma 4, described as the ‘most capable open weights on the planet.’ The model includes four sizes: ~2B and ~4B dense models for on-device use, a 26B sparse MoE with 4B active parameters at inference, and a 31B dense model. Notably, the 26B/4B MoE offers large-model quality with small-model inference cost. Gemma 4 is trimodal, supporting text, vision, and audio natively, with a conformer architecture for audio and a 2D spatial RoPE for vision. It features 128K context for small models and 256K for large, using a hybrid attention design. The MoE variant includes both MLP and sparse MoE blocks, summing their outputs, which is an unusual design choice. The code is merged but weights and release date are pending. Commenters are excited about the potential of the 31B model and the 26B/4B MoE for VRAM-constrained environments. There’s a discussion on how MoE models manage weights in VRAM, with a focus on inference efficiency. Another comment notes that llama.cpp support is ready, enabling immediate local inference upon weight release.

The Mixture of Experts (MoE) model architecture allows for the performance of a larger dense model without the computational overhead by activating only a subset of the model’s parameters during inference. This means that while the Gemma4 26B/4B model has 26 billion parameters, only 4 billion are activated at any given time, potentially reducing the VRAM requirements. However, the entire model’s weights might still need to be accessible, which could be a challenge for VRAM-constrained environments, as the model might need to manage the loading and unloading of weights dynamically to maintain acceptable inference latency.

The llama.cpp repository has already integrated support for the Gemma4 model, as indicated by a recent pull request. This means that once the Gemma4 weights are released, users can immediately convert them to the GGUF format and perform local inference without waiting for additional updates to the llama.cpp repository. This rapid integration highlights the readiness of the community to support new model releases and facilitate their deployment in various environments.

The announcement of Gemma4 by DeepMind and Google includes a detailed blog post and model documentation, which can be found at DeepMind’s official page and Google’s blog. These resources provide insights into the model’s capabilities and potential applications, emphasizing its status as one of the most capable open weights available.

1. Gemma 4 Performance and Issues

Gemma 4 is good (Activity: 429): The post discusses the performance of the Gemma 26b a4b model on a Mac Studio M1 Ultra, comparing it to Qwen3.5 35b a3b. The user reports that Gemma is faster and more coherent, with better visual understanding and multilingual capabilities, despite having a large KV cache footprint (22GB VRAM for 260K tokens @ fp16). The Q4_K_XL quantized model requires an additional ~18GB. The post also mentions issues with Google’s AI studio version of Gemma, citing tokenizer problems. The user notes that SWA provides some benefits in reducing the KV cache size, and expresses concerns about censorship in the model’s responses, particularly in medical contexts. A comment highlights skepticism about the results due to a known issue with the llama.cpp implementation, which was reportedly broken at the time of the original post. Another comment praises the Gemma 4 E2B model for i