Omarchy 4 in Practice: What Is Good, What Is Not, and a Keyboard Shortcut Cheat Sheet

I installed Omarchy 4.0.1 on an old machine from 2018. This page has two halves. The first is what it is like to use, good and bad. The second is how to remember the shortcuts, with tables taken from the settings on that machine.

Let me state the premise first, because it changes how you should read every sentence below. I did not wipe my main machine. I found a spare machine that was sitting around. So everything I say about it being smooth or fast comes from eight year old hardware, not from a new machine.

This thing is good, but what it saves is not what most people think it saves, and its problems are not the old cliche about Arch being hard to install.

What Omarchy is

Omarchy is a desktop made by DHH, the author of Ruby on Rails and the person at 37signals. The base is Arch Linux and the window manager is Hyprland. The project used to sit under Basecamp. Now github.com/basecamp/omarchy redirects with a 302 to omacom/omarchy, and the site still says "Incubated at 37signals". The official manual calls it an omakase Linux distribution built on Arch and the Hyprland tiling window manager.

Omakase means you do not order. The chef decides for you. The word fits, because the whole design starts from that idea. Terminal, editor, browser, launcher, notifications, theme, fonts, key bindings, all chosen and wired up for you in advance.

Whether it counts as a "distribution" was argued about for a long time, because early on it was a bundle of dotfiles and an install script that you laid on top of your own Arch install. 4.0 mostly ended that argument, because 4.0 moved the internals from git into pacman packages, with its own repository and its own full ISO. So the accurate way to put it now is that it started as a configuration layer and is turning into a real distribution, and 4.0 is the turning point.

What changed in 4.0 (Quattro)

4.0.0 shipped on 2026-08-14 and DHH called it the biggest release since the project started. 4.0.1 followed on 8/25 as a fix release reviewed by a newly formed security team.

The parts you notice:

The whole desktop shell was rewritten in Quickshell. A pile of separate components (Waybar, Walker, Mako, SwayOSD, hyprlock, hypridle, swaybg, polkit-gnome) were removed and replaced by one long running process with a plugin architecture. That means the status bar, the lock screen, notifications, and the launcher are now different faces of the same thing, which is what makes theming and scaling actually consistent.

The Hyprland config moved to Lua. To work with Hyprland 0.56, the old .conf became Lua. So changing a key binding is now writing code, not filling in a config file.

The launcher merged into the main menu. One entry point on SUPER + SPACE, with nested search underneath, instead of a separate launcher and menu.

The theme palette went from 8 colours to 24.

The install got faster and smaller. The ISO shrank by more than 1 GB, to under 6 GB, and the install is about 30 percent faster. The official claim is that it can now finish in under a minute. It also finally supports dual boot when there is free space, so you no longer have to wipe the whole disk.

AI agents are first class. 4.x wires several coding agents into the system layer (Claude Code, Codex, that group) and the status bar shows usage. What is interesting is that one of the 4.0.1 release notes says agents now launch with auto-review instead of full bypass, which is the project admitting that the default permissions in 4.0 were too loose. I come back to this in the bad section.

The good

1. What it saves is not install time, it is a few hundred decisions

I think this is the part most people get wrong. Everyone talks about the one minute install, but installing was never where the cost was.

The real cost is this. Which terminal. Which font gives you ligatures and full Chinese coverage. Which notification daemon. How screen lock and idle connect to each other. How multi monitor scaling is set. What you plug in for clipboard history. Which tools you use for screenshots and screen recording. And how all of their shortcuts avoid colliding. Every one of those takes you between half an hour and two hours to work out, and if you get it wrong you start again.

The value of Omarchy is that it makes those few hundred decisions once, with taste, and in a way where the pieces agree with each other. The few you disagree with, you change. Changing one is much cheaper than choosing one from nothing.

2. The shortcuts are designed, not assembled

There is a whole section on this below. The point is that the modifier key itself carries meaning, so you are not memorising 227 bindings, you are remembering four rules. You almost never see this in a hand built tiling WM setup.

3. Moving the internals into packages is what makes long term maintenance possible

Going from git dotfiles to pacman packages sounds boring, but it is the most important thing in 4.0. The problem with the dotfiles model is that upgrades happen by merge, so your changes and upstream's changes fight each other inside your home directory. With packages, system files are system files and your overrides are your overrides, and upgrades have a chance of being predictable.

This is also how I judge whether a project is worth using long term. Is it working on the second year problem, or only on the first day problem.

4. Somebody is maintaining the hardware details

Fingerprint readers, suspend, power profiles, the odd quirks of specific laptops. The release notes are full of these small fixes. This is the part of building your own desktop that you least want to do and that bothers you every day if you skip it.

5. An eight year old machine runs it

This is the one I was least sure about before installing and most convinced by afterwards.

A tiling window manager has no pile of compositing effects to run, and the resident overhead of Hyprland plus Quickshell is low, so almost all of the machine's resources stay with the programs you are actually using. Put a full desktop environment on the same machine and a chunk is gone before you do anything.

The point is not saving electricity. The point is that you have a machine that is close to being retired and it can probably run for a few more years. What was on it before was just too heavy.

To be clear, this only covers CPU and memory. The screen, the battery, and the wireless card on an old machine are still old, and Omarchy cannot help with those.

6. There is a full ISO, so you do not have to know how to install Arch

4.0 has its own ISO. You boot it and install. You no longer need to install Arch first and lay a configuration on top. It also supports dual boot when there is free space, so you do not have to wipe the disk. For the case of "let me try this on an old machine", that matters more than it looks.

The bad

I am not going to be polite in this section, because anyone who would install something like this needs to know what they will hit.

1. The rolling update risk is real, and it is on you

There is no version freeze and no testing channel. Whatever upstream pushes today, you get tomorrow. This is not Omarchy's fault, it is Arch's design, but choosing Omarchy means choosing that.

There is only one piece of advice that goes with it. Keep the system and your data completely separate, and have a backup you can restore from. Do not treat "I will not break it" as a plan.

2. A rewrite of this size brought a batch of new regressions

When you rewrite an entire desktop shell, the price is that problems you had already solved become problems again. This is not a guess. These are open on the issue tracker right now:

• Frequent kernel panics after upgrading to 4.0
• The upgrade leaves behind config pointing at old paths, which if mishandled breaks every compose key combination
• The new lock screen and permission dialogs do not accept the numeric keypad
• D-Bus idle inhibit was lost during the rewrite, so in some cases the machine sleeps when it should not
• The night light background process is not supervised, so if it dies nobody tells you
• On Hyprland 0.56.2, closing the lid with an external monitor attached kills every GUI program
• After waking from suspend the keyboard layout resets to English

These will get fixed. But if you earn your living on that machine, "it will get fixed" and "I cannot take my meeting today" are two different things.

My advice is not to chase new releases. Wait one or two point releases and let other people go first.

3. The default agent permissions were too loose once

I mentioned that 4.0.1 changed agent launching from full bypass to auto-review. That change is good and it means somebody is watching. But it also tells you something. When this project wired agents into the system layer, the first version leaned towards convenience.

If there is anything on your machine an agent should not touch, go through that part yourself. Do not assume it is safe because it is the default.

4. NVIDIA is community supported

The official hardware work is overwhelmingly on Intel platforms and a few mainstream laptop lines. NVIDIA is not unusable, but for black screens at boot, power management on hybrid graphics, and cursor lag on high refresh multi monitor setups, you will find the threads are users helping each other.

In one sentence, if you have a desktop with a discrete NVIDIA card, be ready to spend your own time.

5. It assumes you have a good screen

The defaults in the official manual are tuned for 2x displays, 218 dots per inch and above. If you have an ordinary 4K or 1080p screen, the out of the box scaling will not be right and you have to go in and adjust it.

6. It is one person's taste, and one person's project

This is the other side of omakase. You are buying the chef's taste, so you have to accept the chef's palate. The more you want to change, the less it saves you, and past a certain point you are fighting it, at which point you may as well build up from Arch yourself.

On governance it is genuinely moving outward, with a team that has roles, including a security team, and a foundation. But some of DHH's public statements over the past year have caused a lot of controversy, and some people have said plainly that they will not use the project because of it. I am not going to comment on those statements here. But if you plan to bring this into a team or an organisation, you will be asked about it, so you should think about your answer first.

Chinese input, as its own section

Omarchy already ships fcitx5, which a lot of people do not know. It uses fcitx5 for the CapsLock compose key, so there is an fcitx5 process running in every session and a matching system service.

But you have to install the engine yourself. For Chinese that means adding a Chinese engine. I use Chewing.

Then the most important thing in this section. One of Omarchy's default keyboard options remaps the Shift release event to Caps_Lock, so that the CapsLock compose setup works. The side effect is that fcitx5's "press Shift once to switch between Chinese and English" stops working, because the modifier event fcitx5 is waiting for never arrives.

That is why my cheat sheet lists CTRL + SPACE for switching, not Shift. That is not a personal preference, that is what the default forced.

If you insist on Shift, the fix is to override that keyboard option in your own input config. The trade off is that you lose the CapsLock compose setup.

Two more known situations, so you do not doubt yourself when you hit them:

• In native Wayland Chromium and Electron apps, the candidate window appears in the wrong place and does not follow the cursor. Running them under XWayland is normal.
• If you start a second fcitx5 yourself at login, it fights the system one and the service restarts forever.

One more thing that is not Omarchy's fault but is worth writing down. The default keyboard layout in Chewing may not be the one you want. My machine uses the Eten layout and the positions of the phonetic symbols are different from the default Dachen. To change it, edit Layout in ~/.config/fcitx5/conf/chewing.conf.

Shortcuts: learn four rules, do not memorise 227 bindings

My machine has 227 bindings in total. Memorising all of them is impossible and pointless.

What you actually need to remember is what the modifier keys mean. Omarchy's bindings follow a pattern, and the modifier tells you which kind of operation this is:

Remember that table and you can guess about eighty percent of the shortcuts.

Start with these six

The first one matters most. You do not have to remember anything, you only have to remember that if you forget, you press SUPER + K.

Focus and movement

Workspaces

Window state

Window groups and resizing

Add CTRL for large steps and ALT for fine steps on the resize keys.

Launching applications

All of these are SUPER + SHIFT plus a letter. Several of them open a different variant if you also hold ALT.

System menus

All of these are SUPER + CTRL plus a key.

Clipboard and capture

Notifications, volume, brightness

Chinese input

A few worth learning on purpose

SUPER + CTRL + PRINT pulls text off the screen. This is OCR. Any region of the screen becomes text you can paste. Scans, remote desktops, tables somebody screenshotted at you, all recoverable. I use this far more than I expected.

SUPER + CTRL + V is clipboard history. It is there after install, nothing to wire up.

SUPER + BACKSPACE toggles window transparency. Useful when comparing two documents.

SUPER + S is the scratchpad. Throw a window in and it disappears from the screen but stays alive. Good for the window you have to deal with later but do not want to see now.

SUPER + CTRL + TAB goes back to the workspace you were on last. For bouncing between two workspaces it is faster than pressing numbers.

Two that are easy to press by mistake

CTRL + ALT + DELETE here closes every window, and it does not ask whether you want to save. People coming from Windows are especially likely to hit this in the first few days.

SUPER + SHIFT + ALT + a number is a silent move. The window just disappears to another workspace while you stay where you are. The first time it happens you will think the program crashed.

Changing key bindings

You edit bindings.lua under the Hyprland config directory. Because it is Lua since 4.0, overriding an existing binding means unbinding it first and then binding it again. You cannot just write the same key again and expect it to win.

To see all 227, press SUPER + K, or run omarchy menu keybindings --print in a terminal.

There is a Chinese cheat sheet made directly from my machine's settings, four pages covering 87 of the 227 bindings, on the Chinese version of this page.

What is it trying to become: comparing it with OpenClaw

My own instinct was that Omarchy wants to become something like OpenClaw. After looking into it, the direction holds and the category does not, and the two are approaching the same spot from opposite sides.

What supports the instinct

The tagline says so. The one line on omarchy.org right now is "The malleable computer for the age of agents." The project has already defined itself in terms of agents. This is not us reading it in.

It ships a manual that teaches an agent how to change the system. Under default/agents/skills/omarchy/ there are seven files (SKILL.md plus hyprland, plugins, theming, hooks, capture, contributing), and the declared scope is editing ~/.config/hypr/, key bindings, and display settings. Then bin/omarchy-provision-user symlinks it unconditionally into ~/.claude/skills, ~/.codex/skills, ~/.pi/agent/skills, ~/.gemini/config/skills, and ~/.agents/skills.

That is a much bigger deal than "AI tools are built in". It is not shipping you an agent to use. It is the operating system handing its own manual to any agent runtime, without picking a vendor.

This also explains the trackpad story on my MacBook Air page. config/hypr/input.lua already had commented out hl.gesture({fingers = 3, ...}) examples sitting there waiting for an agent to uncomment them. I thought I was asking Claude to improvise. In fact Omarchy had paved the road in advance and had not told me.

The scale of the investment only jumped at 4.0. Counting AI related files, v3.0.0 has 0, v3.8.4 has 2, and v4.0.0 has 49. The Omarchy skill itself existed as early as v3.3.0 (2026-01-07), but the whole group of omarchy-agent, omarchy-agent-prompt, omarchy-agent-crash, and omarchy-agent-usage-* commands only appeared in August 2026.

There are resident pieces already. omarchy agent usage-update runs every 15 minutes. When a program crashes and triggers systemd-coredump, the system raises a notification and hands the core dump to your default agent with a diagnose-crash skill. That is the closest thing to an agent daemon today.

DHH wrote about this himself. In his 2026-04-15 piece "The malleable computer" he says AI is compressing complexity at a violent pace and making it malleable, and that once this force acts on the operating system, it acts on the whole computer. That sentence is almost a product description for what Omarchy is now.

Governance is expanding. Omacom was formed in July 2025, and the site banner says the foundation started with ten million dollars.

What does not hold

There is no agent inside Omarchy. It bundles no model and has no resident agent runtime. All install/user/mise.sh does is set up lazy stubs for the claude, codex, opencode, copilot, pi, and grok commands, and nothing downloads until the first run. None of the 147 base packages is an LLM.

The core of OpenClaw is exactly the layer Omarchy does not have. OpenClaw is a resident Gateway daemon bound to 127.0.0.1:18789 that manages sessions, tools, events, and channel connections. The README says it is "an AI assistant that runs on your devices and meets you in the channels you already use." The second half is the point, connecting an agent to the WhatsApp, Telegram, Slack, Discord, iMessage, and LINE you already use.

Omarchy has no concept of a channel at all. That is not doing less, that is not being in that business.

4.0.1 pulled back rather than pushed forward. The new security team changed agent launching from full bypass to auto-review. A project that really intended to become an agent host would not be tightening autonomy at this point.

DHH is openly negative on local models. In November 2025 he wrote that honestly they are all far behind the frontier models because they are simply bad. So Omarchy is not going to grow towards being a local inference box. On the OpenClaw side, llama.cpp, LM Studio, Ollama, vLLM, and SGLang are all first class. That is a real difference in values, not a difference in progress.

One exception so I am not overstating it. Omarchy does carry one local model, voxtype for voice dictation, about 150 MB, using the Vulkan GPU, and it asks whether to install it the first time you use it. But that is a small single purpose model, which is a different thing from moving inference back onto your own machine.

The proportions are not there either. The v4.0.0 release highlights run to about 24 items and only 1 of them is about agents. The shell rewrite, the Lua config, and the smaller ISO are the main show.

A more accurate way to put it

Rather than saying Omarchy wants to become OpenClaw, it is better to say both are competing for the same position from different layers. Who gets to host the agent.

What is interesting is that OpenClaw's own docs quote, approvingly, the line that the only security boundary that can hold back a hostile LLM is the operating system. That is OpenClaw admitting the OS is underneath it. NanoClaw's argument is exactly that too. It says OpenClaw's security is at the application layer and not real OS level isolation, so it gives each agent its own container.

Three answers to the same question. OpenClaw grows down from the agent and wants to reach the OS. Omarchy grows up from the OS and wants to reach the agent. NanoClaw takes the isolation the OS already has and puts agents in it. They have not met yet.

What you can take from this

What you can copy is the pattern, not the software. What Omarchy does is write the system's own operating rules into files an agent can read, put them in a fixed location, and let any agent follow them, without tying it to a vendor.

In a hospital context, that means writing a system's configuration rules, handover documents, and common procedures into a form an agent can read, instead of only giving staff a chat window. This is the same thing I keep saying about building in blocks that can be handed over and reused elsewhere, just taken one layer further down.

The lesson to remember is the 4.0.1 one. The first version of the defaults leaned towards convenience and was tightened later. If you do this inside a hospital, work out the permissions cell yourself first. Do not wait for someone else to find it for you.

So who is this for

Good fit: people whose main work is development or writing, who work from the keyboard, who can accept rolling updates, and who are not bothered by someone else making decisions for them. Especially people who have already built a tiling WM setup once and know how much time that takes. You will feel it the most.

Bad fit: people whose machine cannot go down. Production lines, clinical work, anything where downtime has a cost, do not use a rolling release system as that workstation. Also desktops with discrete NVIDIA cards, and people who already have a setup they have used for years and are happy with, because Omarchy will save you less than you will have to change.

The middle path: install it on an old machine and leave your main machine alone. Run it for a month or two and see whether you can go back. That is what I did. I found an old machine from 2018 where I would not mind if it broke, and what I actually found was that the machine was not as useless as I thought.

There is another benefit to doing it this way. The rolling update risk and the big rewrite regressions above are only an annoyance on a machine that is not carrying your work, not a disaster. To really know whether you can live with this thing, you have to let it break in front of you first.

In one line

Omarchy is not selling Linux. It is selling not having to decide. That is worth a great deal when you are starting out and worth less once you have your own opinions. So the question is not whether it is good, it is which stage you are at.

Related pages

• Omarchy on a 2012 MacBook Air: Installed in 6 Minutes
• Running Several Projects at Once on Omarchy: Two Layers
• My Full Agentic Workflow: NanoClaw + Claude + Spectra + Rails
• Chinese version of this page