posts · 2026-06-12

This caught my eye because it turns cross-model division of labor into a reusable Claude Code skill. Dan McInerney has Claude Fable 5 act as architect—breaking down tasks and reviewing code—while GPT-5.5 Codex does the actual building, with the repo serving as shared memory. He claims this cuts Fable token usage by 80%, but the repo only has a README and code, no benchmarks or comparison data. I'd discount that 80% figure. It reads like personal experience, not a systematic eval. The cost logic makes sense—Fable 5 isn't cheap, and offloading most calls to Codex would save money—but only if Claude's planning and review are solid enough to avoid rework loops from lost context. That's exactly what we don't have data on. Treat this as a cost-saving template for narrow tasks, not a general solution. It probably works best when the task is well-defined, Codex can handle it independently, and Claude only needs light review. For complex refactors or tasks requiring deep codebase understanding, this split might add more back-and-forth than it saves.

The idea is almost offensively simple: right now every AI agent reading the same document recomputes prefill from scratch, rebuilding an identical KV cache. The authors propose letting publishers precompute it once and sell access. On Qwen3-4B, reuse is 9–50x cheaper than prefill, and token outputs match exactly—zero accuracy cost. The part I found most useful is their math on where the cache lives. Shipping the KV file directly fails because it's nearly incompressible—egress costs more than the prefill you're trying to save. The fix is hosting it provider-side, exactly how production prompt caching works today. They run the numbers: one 3,774-token document accessed by 80 million agents costs ~$1.5M to re-prefill but only ~$30K via reuse, a 49.7x gap. Current API cache-read pricing at roughly 10% of full prefill sits comfortably inside that measured saving, so the 10x discount is a floor—the remaining gap is provider margin, millions per popular document. They frame this as an agent-native prefill CDN and leave lossless KV compression and cross-party payments as open problems. I'd read this as a clean engineering argument, not a product yet, but the direction is sharp: when agents read the same documents at scale, redundant prefill is just burning money.

The number that grabs you is the valuation: nearly doubling from €11.7B to €20B in one round. But the post is literally one sentence from an RSS feed—TechCrunch calls it a rumor themselves. No lead investor, no use of funds, no closing timeline, no official confirmation. I'd discount this until we see more. A raise this size usually leaks with more detail if it's close to closing. For now, it's a sentiment signal that European LLM money is still flowing, but whether the valuation holds up is an open question.

The reason this is worth a look: anyone training models knows the pain of re-running evals after every data tweak or hyperparameter change, then trying to figure out if a 2.4pp shift is real. olmo-eval turns that into a pipeline—add benchmarks, run them across checkpoints, analyze per-prompt, with multi-turn and agent eval built in from the start. It's built on OLMES and open on GitHub. I'd treat this as dev-loop infrastructure, not another leaderboard tool.

This one's worth opening because it tackles a pain every model builder knows: you're running evals constantly during development, but existing tools are either for final benchmark scores on finished models or for sandboxed agent tasks — nothing handles the messy middle where you're swapping checkpoints, tools, and prompts every few hours. olmo-eval breaks everything into swappable modules — models, tools, environments, helper models — so you can run lightweight scores or containerized complex scenarios. Results come with standard errors and minimum detectable effects, so you can tell real improvement from noise. The division of labor with Harbor is clean: Harbor handles release-day evaluation, olmo-eval handles fast dev-loop iteration, including question-by-question diffs between checkpoints. Code and docs are on GitHub now; Allen AI used it internally for OLMo and Tulu. Whether the community builds enough task and tool plugins to make the modular design pay off is still an open question.

This caught my eye because someone finally attacked 1M-context inference at the attention level—not via MoE or quantization. MiniMax added a lightweight index branch on top of GQA: it scores KV blocks, picks a top-k subset per query group, then runs exact attention only on those. With a custom GPU kernel, their 109B multimodal model hits 14.2× prefill and 7.6× decoding speedups on H800 at 1M context, matching full GQA quality. I'd discount this in two ways. One, the post is a single Reddit thread and the source link returns a 403, so I can't verify the paper details or benchmarks directly. Two, those speedups are on H800—the poster asks whether this runs on consumer GPUs, and the post doesn't answer. A 109B model is heavy regardless, and sparse kernel behavior on consumer cards is an open question. The concrete part: code and inference kernel are open-sourced, along with a model called MiniMax-M3. If weights drop too, this stops being a paper and becomes something you can actually try.

The reason to click: MiniMax finally open-weighted M3. The architecture is unusual — 428B total params but only 23B active per forward pass, with their own sparse attention pushing context to 1M tokens, plus native multimodal. Scores look solid for code and agent work: 59.0% on SWE-Bench Pro, 66.0% on Terminal Bench 2.1, 74.2% on MCP Atlas. But the post doesn't disclose training data, inference cost, or license terms, and the tech report won't land for another ~10 days. I'd hold off on any usability judgment until then. What's real right now: the weights are on HuggingFace, you can download them, but whether you can use them commercially or how expensive inference gets — nobody knows yet.

The headline is that MiniMax put M3 weights on Hugging Face — 428B total params, ~23B active per forward pass. That MoE ratio sounds compute-friendly, but the Reddit post itself is 403-blocked, so all we have is the title and summary. No training data, no benchmarks, no minimum VRAM. If you're thinking about running it locally, I'd wait until someone posts real memory numbers and token/s before downloading.

The reason this story lands hard: it connects a casual game directly to military drone navigation. Niantic had players scan real-world locations—parks, landmarks, streets—and used that data to train a geospatial AI that understands physical spaces. That model later ended up in drone projects with the U.S. Army and other defense partners, helping machines recognize and navigate real environments. Players never knew their scans could feed military applications. The post doesn't spell out how much player data was used, the contract value, or whether anyone can retroactively opt out. I'd watch two gaps: what Niantic's privacy policy actually said at the time, and the scope of those military contracts—both are blank right now.

Kimi's moving fast on code models — K2.6 barely landed and K2.7 is already here with solid jumps on their own benchmarks. The 30% token reduction is the part I'd pay attention to: same task, fewer tokens, lower API cost. That's real if it holds. I'd discount the benchmark numbers a bit. All three are in-house — Kimi Code Bench v2, Program Bench, MLS Bench Lite — and we don't have external baselines to compare against. No parameter count, no training data details, no license. The 6x speed mode is just a teaser for now. If you're already on Kimi API or Kimi Code, try it. The token savings might show up on your bill. If you're shopping for an open-source code model, wait for the license and some third-party evals.

This one's worth opening because it nails a specific MTP speculative decoding trap: pick the wrong assistant model and your speedup goes from 2x to basically nothing. The author ran Gemma 4 Heretic in llama.cpp. A 26B Q8 jumped from 30 t/s to 62 t/s; a 12B Q4 went from 12 t/s to 54 t/s. The useful bit: two GGUFs with the same filename aren't necessarily the same file, unquantized assistants consistently beat Q4/Q8 by about 10 t/s, and a draft count of 1 gave the best results across the board. One practical tip: always check the logs to confirm MTP actually initialized. If it didn't, you're benchmarking the base model by accident. The post body returned a 403, so I can't see the exact test setup or model sources, but the takeaways are solid for anyone running local MTP.