What I learned:

The 30-day story is MLX pulling ahead on the Mac while llama.cpp stays the "runs everywhere" default - The engine resolved this as a clean two-way split. llama.cpp is the incumbent by a mile - 121K stars, 1,914 open issues, and a stated goal of "LLM inference with minimal setup and state-of-the-art performance on a wide range of hardware." MLX is the Apple-Silicon-native challenger, and the sharpest framing came from an r/MacStudio thread on MLX-Serve (93 upvotes, 26 comments) where a commenter nails the tradeoff: "llama.cpp is simply optimized for Cuda/Nvidia, and not much you can do about it - llama.cpp is about compatibility across architectures, OS's, GPU's." That's the whole comparison in one line: portability vs peak-Apple speed.

MLX's momentum this month is the ecosystem, not just the core - The activity clustering around MLX is people building fast Apple-Silicon tools on top of it. @ivanfioravanti shipped a Mage-Flow PR for mflux (image gen "Powered by Apple MLX") clocking 1024x1024 generation at ~1.6s on an M5 Max and ~2.7s on an M3 Ultra, using ~18-20GB. The recurring theme is "twice as fast on Apple Silicon" - the same pitch behind MTP speculative-decoding projects in the MLX orbit. MLX's rough edge is model coverage: an LM Studio mlx-engine bug shows a new MoE-vision model type failing to load, the kind of gap you rarely hit with llama.cpp's broad format support.

llama.cpp's edge is quantization tooling and the fact that it runs on the hardware you don't own yet - The freshest llama.cpp-adjacent project is TheTom/llama-cpp-turboquant (2.2K stars), pitching "production-grade KV-cache and weight quantization for llama.cpp, with cross-backend kernel support for Apple Silicon, NVIDIA CUDA, AMD ROCm, and Vulkan." That cross-backend reach is exactly why people keep it around even when MLX is faster on their Mac - the same engine covers the CUDA box, the ROCm rig, and prebuilt setups like ai-dock/llama.cpp-cuda.

A wildcard is appearing: third-party runtimes claiming to beat both - A small HN post, "6.4x faster than llama.cpp, 3.9x faster than MLX", is the early signal that the two-horse race may not stay a two-horse race - purpose-built inference runtimes are starting to benchmark against both incumbents at once. It's low-engagement so far (4 points), so treat it as a straw in the wind, not a verdict.

KEY PATTERNS from the research: 1. Portability vs peak-Apple is the real axis - llama.cpp runs on "architectures, OS's, GPU's," MLX squeezes the Mac, per r/MacStudio 2. MLX's momentum is the tool ecosystem (mflux, MLX-Serve, MTP decoding) more than the core framework, per @ivanfioravanti 3. llama.cpp's staying power is quantization + cross-backend reach, per TheTom/llama-cpp-turboquant 4. MLX still trails on model coverage - new model types can fail to load, per the LM Studio mlx-engine bug 5. Watch for third-party runtimes benchmarking against both at once, per basert on HN

Head-to-Head

Bottom line: choose MLX if you live entirely on Apple Silicon and want the fastest local tokens with a growing tool ecosystem around it. Choose llama.cpp if you need a single engine that also targets NVIDIA/AMD and values format breadth over peak-Mac speed. The emerging stack is both at once - llama.cpp as the portable baseline, MLX-based serving on the Mac for speed - while newcomers like basert start benchmarking against both.

What I learned:

The two Chinese open-weight heavyweights are being used for different jobs, not ranked head-to-head - This month's evidence splits cleanly: Qwen 3.6 is the model people trust as their local workhorse, and DeepSeek V4 is the cheap-and-capable engine people wrap in a pipeline. The blunt community verdict on Qwen came from @AstraiaAI (386 likes): "Qwen 3.6 27B is by far, and beyond any doubt, STILL the best open model under 200B parameters right now. Nothing I have tested even comes close, except for its own finetunes." That "STILL" is the tell - it has held the local crown for a while.

Nobody trusts DeepSeek V4 end-to-end; they orchestrate it - The most useful thread was "Deepseek V4 Pro is AMAZING" (403 upvotes, 79 comments), where the praise is immediately qualified: "I find it very cheap however the output sometimes is not so great... I have to rely a lot on skills in order to polish the way I really want." The pattern people actually run is a tiered pipeline, best captured by u/enterme2: "Plan it with v4-pro high, then have the plan reviewed by a stronger model like gpt-5.6 or kimi k3, then use v4-flash max to execute the plan. Saves you a ton while having higher quality output." DeepSeek's value is being the cheap tier in a multi-model workflow, not the single brain.

Qwen wins the local-on-Apple-Silicon race because the tooling targets it - The highest-scored item on the Qwen side was youssofal/MTPLX (1.1K stars): "3x decode TPS increase on Qwen 3.6 27B... Native MTP Speculative Decoding on Apple Silicon with no external drafter," under the banner "run local LLMs on Apple Silicon, around twice as fast." There's even a 16GB-friendly path - Luke's Dev Lab benchmarks a Qwen 3.6 14B A3B variant pruned down from 35B via REAP for smaller Macs. DeepSeek V4's dense/Pro tiers simply ask for more machine.

The practical gotcha with Qwen is the chat template, not the weights - A grounded "I ran Qwen 3.6 locally for 45 days" writeup (297 upvotes, 118 comments) surfaced the real-world snag: "the worse tool calling is because of a few bugs in the standard chat template. On huggingface froggeric has some patched templates. I use those." The comments hammer that your quant version matters as much as the model. And a meta-note from @jukan05 (258 likes): the flood of Chinese open weights actually reinforces NVIDIA's dominance, since they're trained and shipped optimized for NVIDIA hardware. Open weights are closing the gap on frontier coding models - @antirez notes even a small specialist like Laguna S2.1 beats DeepSeek V4 Flash on some coding tasks - but the frontier keeps moving.

KEY PATTERNS from the research: 1. Qwen 3.6 27B is the community's "best open model under 200B" - the local default, per @AstraiaAI 2. DeepSeek V4 is used as the cheap tier in a plan / review / execute pipeline, not trusted solo, per r/DeepSeek 3. Qwen wins on Apple Silicon because the speedup tooling (MTP speculative decoding) targets it, per youssofal/MTPLX 4. Qwen's real-world snag is chat-template tool-calling bugs - use patched templates and mind your quant, per r/LocalLLM 5. Open weights keep closing in on frontier coding, but specialist models can already beat DeepSeek V4 Flash on narrow tasks, per @antirez

Head-to-Head

Bottom line: choose Qwen 3.6 if you want the strongest self-hostable open model and you run on Apple Silicon - the ecosystem is built around making it fast and small. Choose DeepSeek V4 if you want cheap, capable tokens and you're willing to wrap it in a plan/review/execute pipeline. The emerging stack isn't either/or - people orchestrate DeepSeek as the cheap draft-and-execute tier, hand review to a stronger model, and keep Qwen as the local workhorse.

Note on evidence: "Astro" is a crowded name - the engine's social pull for it was swamped by the K-pop group ASTRO and by astrology accounts, so the framework's live social signal was thin this run. The Astro-side signal here leans on the Astro 7.0 release (Hacker News) plus GitHub project data rather than a rich social debate; the Next.js side came through clean.

What I learned:

Next.js is still the gravitational center, and the fresh energy is about escaping its orbit - The raw scale gap is stark: vercel/next.js sits at 141K stars (with 4,244 open issues), shipping as Next.js 16 on an Active LTS line. But the most interesting 30-day item isn't from Vercel - it's cloudflare/vinext (8.5K stars), "a Vite plugin that reimplements the Next.js API surface - deploy anywhere," built to "run Next.js applications on Vite, with Cloudflare Workers as the primary deployment target." Cloudflare literally titled the announcement "How we rebuilt Next.js with AI in one week." The subtext: people love the Next.js API but want off the Vercel-coupled rails.

Astro's move this month is a major version, positioned as the HTML-first alternative - Astro 7.0 landed (211 points, 60 comments on HN) - the clearest fresh signal that Astro is still executing on the content-first, ship-minimal-JS pitch that makes it the natural pick when a full React app is more than you need. It doesn't have Next.js's raw mass, but the release cadence and HN attention show a healthy, distinct lane rather than a Next.js clone chasing the same use case.

The recurring complaint about Next.js is churn, and even its fans say it out loud - The framing from a widely-viewed Next.js 16 course captures the sentiment perfectly: "How many times have you finally wrapped your head around Next.js only for them to drop another version that renames half the features, breaks the other half, and promises to simplify everything?" The verdict is still "this time it's worth it," but the fatigue is real - and it's exactly the opening Astro and vinext are walking through.

The ecosystem is consolidating around "pick the right tool per surface," not one framework to rule them all - Boilerplates like ixartz/Next-js-Boilerplate (13K stars, Next.js 16 + Tailwind 4 + TypeScript) show Next.js entrenched for app-shaped, data-heavy products, while Astro owns content, docs, and marketing. The 2026 shape is teams running both - Astro for the static/content surface, Next.js for the interactive app - with a growing "Next.js without Vercel" escape hatch via vinext.

KEY PATTERNS from the research: 1. Next.js dominates on mass - 141K stars, Next.js 16 LTS - and stays the default for app-shaped products, per vercel/next.js 2. The freshest movement is "Next.js API without Vercel" - Cloudflare's vinext reimplements it on Vite/Workers 3. Astro 7.0 just shipped, holding the HTML-first, ship-less-JS lane, per astro.build 4. Version churn is Next.js's recurring knock - "renames half the features, breaks the other half," per the Next.js 16 course 5. The consensus is per-surface tooling - Astro for content, Next.js for the app - not one winner

Head-to-Head

Bottom line: choose Astro if you're shipping content and want fast HTML with little JavaScript to maintain. Choose Next.js if you're building an interactive, data-heavy app and want the largest React ecosystem behind you. The emerging stack pairs them - Astro for the marketing/docs surface, Next.js for the app - and a "Next.js without Vercel" path is now open via Cloudflare's vinext.