Omarchy 4.0's AI-Native Desktop, Tested on a $130 Dell OptiPlex

We put DHH’s claim that AI agents are now “part of the desktop” through a real test — on a fan-cooled office micro with integrated graphics, no cloud subscriptions, and a homelab inference server.

DHH and Basecamp make a bold promise with Omarchy 4.0 (“Quattro”): AI agents aren’t something you bolt onto this Linux desktop — they’re shipped as part of it. OpenCode and Claude Code come preinstalled, every other major agent CLI is a lazy-loaded command away, Ollama and LM Studio install from a menu, and a bundled “Omarchy skill” lets an agent reconfigure the desktop itself.

That’s a testable claim. So we tested it — not on a workstation with a $2,000 GPU, but on the kind of machine most people actually have sitting in a closet: a Dell OptiPlex 3070 Micro (~$130 used), i5-9500, 16GB RAM, 256GB NVMe, integrated Intel graphics only. No discrete GPU. No paid AI subscriptions. And because we’re a homelab shop, we also pointed the whole stack at our own self-hosted inference server to see whether Omarchy’s “AI-native” story works when you own the model.

Short version: the install story is genuinely excellent. Everything after it is where the marketing outruns reality.

The install: faster than your coffee order

Omarchy’s installer is a short guided set of minimal options, and then it gets out of the way. On the 3070 Micro, from selection to finished system: 1 minute 34 seconds. That is not a typo, and for anyone who has sat through an Ubuntu Desktop install, it’s a revelation.

First boot lands you in Hyprland (Wayland) with Ghostty as the terminal (Super+Return). The AI tooling is already half-there:

• opencode and claude launchers in ~/.local/bin
• Stub launchers for codex, gemini, copilot — plus undocumented extras: crush, grok, hunk, omp
• The bundled agent skills (omarchy, diagnose-crash) already in ~/.claude/skills/

The stubs are tiny bash scripts that call mise to fetch the real binary on first run. It’s a clever design: nothing bloats the image, but every harness is one command away. And it works:

All five came up with zero manual intervention beyond authentication. One nitpick: Gemini’s first run compiles a native module via node-gyp, which means it silently depends on build tools being present — fine on Arch’s default base, but a landmine on stripped-down systems.

Early gotchas: the documented c/cx aliases are bash-only definitions buried in /usr/share/omarchy/default/bash/aliases — invisible if you land in zsh or any non-interactive shell. And SSH setup forces key-based auth out of the box (good security, mild friction). More on cx later — its default is worth a raised eyebrow.

Auth: where “native citizen” starts paying dues

This is where our no-subscriptions constraint became the experiment. We don’t pay for Anthropic, OpenAI, Google, or GitHub Copilot tiers — like most readers, we wanted free-tier or self-hosted paths. Results varied wildly.

Copilot CLI was the pleasant surprise. Its device-code flow (copilot login --device-code) works perfectly over SSH: it prints a short code, you authorize at github.com/login/device from any browser, done. Two gotchas worth knowing: your account needs Copilot enabled (the free tier counts) before you authorize — otherwise it fails silently — and if the waiting login process dies before you finish authorizing, GitHub shows success but the token never gets stored.

Gemini CLI was the disaster. It refuses non-interactive sessions outright, has no device-code flow, and instead demands a browser OAuth dance that ends in a paste-back authorization code that expires in five minutes. Worse, when the code prompt times out, the CLI auto-retries with a fresh cryptographic challenge while displaying what looks like the same URL — so codes go stale invisibly. We tried three times across two auth methods. Then we tried the escape hatch, a free API key from Google AI Studio — which demanded age verification via selfie, credit card, or government ID. We declined. A final direct attempt at the OAuth URL returned “Access blocked: Authorization Error” with no VPN involved.

Four distinct failure modes. Gemini CLI was the only harness of five we could not get working at all, and every failure was on Google’s side of the fence.

The pattern is hard to miss: the smoother the auth, the more the vendor wants you in their ecosystem. GitHub built a flow that works headlessly; Google built one that assumes you’re at a desktop, using Chrome, with a fully-verified account.

Local AI: the homelab test nobody else runs

Here’s the part most Omarchy coverage skips: what if you don’t want your desktop agent talking to Anthropic’s servers at all? We run a llama.cpp server on our LAN (Qwen3.8-27B, Q8, on a GPU box across the house) speaking both OpenAI-style and Anthropic-style APIs. Perfect test bed.

OpenCode: flawless. One config file edit pointing it at our server’s /v1 endpoint, and the full agent — tools, file editing, everything — ran against our own model over the LAN. First try, zero errors.

Claude Code: blocked. It happily accepts ANTHROPIC_BASE_URL, and curl to our server works fine in both wire formats — but Claude Code’s actual requests trigger a fatal error from the model’s chat template (“System message must be at the beginning”). This is Claude Code’s request shape failing against a local model, not a config problem on our end. Add the “unrecognized model” nag and a required escape-hatch env var, and local-model support is clearly not a priority.

Codex: actively hostile. OpenAI removed the standard chat wire format entirely (wire_api = "chat" is rejected now — their discussion #7782), forcing their newer Responses API. Our server happens to speak it, but Codex 0.149.1 still routed requests to api.openai.com despite config files and command-line overrides — and along the way it wiped our config file. We got closest here and still didn’t get a clean run.

Copilot and Gemini: cloud-only by design.

So the honest scorecard looks like this:

For a homelab user, the conclusion is blunt: harness choice matters more than distro choice, and the only harness that respects your own infrastructure is the open one.

Can an agent safely modify your desktop?

The marquee feature deserves its own test. Omarchy ships a skill that teaches agents how to customize Hyprland, themes, terminals, and more — DHH himself calls it experimental and points to a full-config-reset command as the rollback plan.

We asked OpenCode (running on our LAN model — no cloud involved) to change window gaps to 12px. What happened next was genuinely impressive:

1. The agent found and read the omarchy skill unprompted
2. It made exactly the requested edit — activated one config block, set two values, touched nothing else
3. When it couldn’t verify the result live (no Hyprland session available to it), it said so instead of claiming success

Equally important: the sandbox held. Our first attempt ran non-interactively, and OpenCode refused access to ~/.config/hypr/ until explicitly permitted. Fail-closed by default is exactly right.

Rollback is the weak link. omarchy reinstall configs exists, but it’s an interactive, all-or-nothing reset of every user config — a sledgehammer for a thumb-tack job, and unusable over SSH. Practical safety comes from your own backups: we restored the edited file byte-identical from a snapshot taken before the test. If agents are going to be “part of the desktop,” per-file versioning of configs should be too.

One more thing worth a raised eyebrow: Omarchy’s default alias for Claude Code is cx — which launches it with --permission-mode bypassPermissions. Danger mode isn’t hidden behind a flag you’d have to find; it’s the front door. For a distribution whose pitch is “agents live here,” shipping the least restrictive permission mode as the default launcher deserves scrutiny.

Verdict

What Omarchy gets right: the fastest Linux installer we’ve used; genuinely thoughtful lazy-loading of the entire agent ecosystem; skills that work as advertised; a sandbox that fails closed; and an install experience that makes Ubuntu feel sluggish by comparison.

Where the “AI-native” story bends: native citizenship apparently means cloud citizenship. Four of five harnesses either require paid subscriptions or fight you on self-hosted backends. Auth flows range from good (GitHub) to unusable (Google) — and none of that friction is Omarchy’s fault, which is precisely the point: the distro can ship the tools, but it can’t fix an ecosystem built to route you through someone’s API billing.

Our advice so far: if you want Omarchy’s AI desktop without subscriptions, run OpenCode against your own inference server — it’s the one combination that worked flawlessly end-to-end, and honestly, it’s a better architecture anyway. Your agent lives on your desk; your model lives in your basement.

To be clear about scope: this was a few hours of testing, not a long-term verdict — and we came away genuinely optimistic about Omarchy. The bones are excellent: an installer that respects your time, a clean separation between distro and user config, and a team shipping fast. Most of our friction points weren’t Omarchy’s failures at all but ecosystem realities it inherited. We’ll be keeping this box running and revisiting as the project matures.

The “AI-native desktop” is real. It just arrived wearing someone else’s logo — unless you bring your own.

Benchmarks run on Dell OptiPlex 3070 Micro (i5-9500, 16GB RAM, 256GB NVMe, Intel UHD 630), Omarchy 4.0.0, August 2026. Full methodology and raw results available.