Agents in the OS, downloads dropping, and a 2.4T open model

00:00:04 DHH just announced Omarchy Quattro, and it's one of those specifics that makes you stop scrolling for a second. It's a Linux distribution where agents aren't an add-on or a CLI tool sitting on top — they're woven directly into the operating system itself. Every agent is managed through mise, Opencode ships installed by default, and there's a crash watcher built in that uses an agent with a special tracing skill to diagnose issues and report verified problems upstream.

00:00:36 The premise cuts through the usual "AI at the OS level" futurism. DHH isn't proposing agents as a new subsystem or a daemon you opt into. He's arguing that intelligence should be part of the OS fabric, not bolted on afterward. The crash watcher example makes this concrete: instead of waiting for a user to file a bug report, describe what happened, and hope someone reads it weeks later, an agent traces the failure in real time, packages it with diagnostic context, and submits it upstream.

00:01:11 bitslix put it well in the thread — "the next step in AI is not putting agents on top of the OS, but bringing them directly into the OS, so they are the OS itself." Geoffiam pushed back right after: "I don't think you want your OS beholden to datacenter compute." That's the tension.

00:01:30 The model serving lives remotely, the agent runs locally — cloud availability is now a first-class dependency of the operating system. The architecture question is genuine. What happens when an agent that manages crash diagnostics also decides to auto-triage Sentry alerts or manage server processes?

00:01:51 Chad Arimura describes root-level agents on DigitalOcean droplets in his setup post. He runs six of them — admin, ops, development, GTM, research, and infrastructure each with different permissions and tool access. You're giving local intelligence direct access to your system stack.

00:02:11 It's early. The distro is newly released and the threat model for embedded agentic behavior hasn't been stress-tested yet. But it's also one of the more specific proposals we've seen about where intelligence belongs in software.

00:02:27 Nathan Lambert from HuggingFace posted a PSA that caught my attention: pretty much every model on the platform saw a sustained 30% drop in daily downloads starting a few weeks ago. He attributes the dip to new filtering logic that may be suppressing visibility.

00:02:45 That's one possibility. But if it's not filtering, what explains a platform-wide reduction across essentially all models? Three readings surface, none particularly comforting for anyone who built a business on infinite download growth. The first reading is saturation.

00:03:04 We've been at this long enough now that every engineer who needs to evaluate or download models has probably done it multiple times already. The marginal value of a new download has dropped. You don't need 47 copies of the same quantized Llama build. The second reading is behavioral shift.

00:03:25 Agents and API-based workflows may be consuming model access in ways that no longer register as HuggingFace downloads. If your team runs inference through an API gateway, or if agent tooling pulls models from a different registry entirely, you're still doing the work — just not on HuggingFace's dashboard.

00:03:47 The third reading is platform friction. If Julien and the HuggingFace team did change filtering — perhaps tightening which models appear in default search results, or deprioritizing ones with insufficient metadata — that would show up exactly like this: a broad, sustained drop rather than isolated model-specific declines.

00:04:10 The timing sharpens the contrast. We're seeing massive open-weight releases today — Qwen dropped 2.4 trillion parameters on HuggingFace this morning alone — and yet downloads across the platform are declining. It suggests the growth story for hosting platforms is diverging from capability scaling.

00:04:31 Distribution may not keep pace. Downloads were always a noisy proxy for adoption, not a direct measure. They work fine during growth spurts and break down once growth stalls. We should probably track something else before dashboards convince everyone that use has flatlined.

00:04:50 Qwen3.8 just landed on HuggingFace with 2.4 trillion total parameters and 95 billion activated — the last number being the ones actually used during inference thanks to mixture of experts routing. The architecture details are where this gets interesting. Instead of going purely transformer, Qwen3.8 uses a hybrid: Gated DeltaNet for some layers combined with mixture of experts routing on others.

00:05:19 Gated DeltaNet is a state-space variant that handles sequential computation more efficiently than attention for certain patterns. The combination — linear attention heads paired with expert routing — aims to get you close to transformer quality at lower compute cost during inference.

00:05:40 Running 2.4 trillion parameters sounds enormous, but with only 95 billion active per token, the actual compute load lands closer to a 100-billion-class model than a full-density trillions-parameter one. That shifts what's possible for anyone trying to run frontier-class weights locally without renting a data center.

00:06:03 The benchmarks Qwen published are strong on agent-execution tasks — Terminal Bench hits 86.6 and SWE-bench Pro sits at 67.7. The paper benchmark (PaperBench) comes in at 93.0 against Claude Opus 4's 90.5. These aren't synthetic benchmarks; they're real coding and research evaluation suites, though I'd want independent replication before treating published results as settled.

00:06:31 The hybrid architecture itself — Gated DeltaNet plus mixture of experts — is a direction other major teams haven't committed to yet. The big open models tend to either be pure transformer or pure state-space at this point. Qwen is betting on the middle ground, and if it holds up in independent evaluation, it could influence how the next wave of open-weight models are designed.

00:06:58 The context window is 262K natively with extensibility up to a million tokens. That's already the standard for frontier models. The differentiator here is really the architecture choice and the breadth across which Qwen claims Max-class performance — coding, research, professional work, and long-horizon agentic tasks.

00:07:22 Independent evals will tell if these numbers hold up, and the open community's reaction will determine whether this becomes a viable inference pattern or stays an academic curiosity. The hybrid approach is worth trying; whether it generalizes remains to be seen.

00:07:41 The last item today runs in the opposite direction from Omarchy Quattro's ambition. There's a new coding agent called Hax that uses just a few megabytes of RAM because it's written as a single native C binary. It supports local models through llama.cpp and Ollama, plus OpenAI, Anthropic, OpenRouter, and Codex.

00:08:02 The philosophy is deliberate minimalism. No MCP marketplaces, no plugin runtime, no IDE panels. It streams Markdown output reflowed for terminal display, preserves native scrollback, and lets you inspect the full wire protocol via a built-in transcript view. The setup is straightforward: brew install, run from your project directory, done.

00:08:25 The target audience it names explicitly spans developers who live in the terminal and run local models. It also reaches people who audit their tooling, package software for distros, or run agents where resources are scarce. That's a real community that gets squeezed when every new "AI coding tool" demands 800 megabytes of resident memory and half a dozen background processes.

00:08:51 Hax doesn't solve the fundamental tension between agent complexity and system bloat. But it does make a tight argument that not every AI tool needs to be an ecosystem. If your primary use case is running a local model from the command line while you code, spending megabytes on the agent runtime rather than the model itself is a trade-off worth examining.

00:09:15 There's also something structurally interesting about how the C choice shapes what Hax can and cannot do. A C binary has a small dependency set, starts instantly, and doesn't pull in runtime environments you didn't ask for. But it also limits what kind of tooling or plugin infrastructure you can build on top — which is exactly the constraint the authors are leaning into.

00:09:41 Both Omarchy Quattro and Hax are trying to solve the same underlying problem — how do agents fit into developer workflows without taking over the machine? They just reach for opposite answers. One wants the OS to be intelligent. The other wants the agent to stay out of your way until you call it.

00:10:01 That's the read for today. Seln Oriax.