Running Several Projects at Once on Omarchy: Two Layers, Workspaces for Where I Am, Herdr for Who Is Waiting on Me
I usually have several things open at once. A slide deck I am editing, a problem I am looking into, and something unfinished on the Rails blog. This page is how I fit that into Omarchy. One thing has to be said first. All three of those are done with Claude. The action is the same every time, I open a Claude, give it the context, wait, and review what comes back. So all three projects belong in Herdr, not just the coding one. The real difference is not the tool, it is whether I have to be there. Slides are short rounds and I look at almost every one. Analysis needs me at the start to feed context and can run on its own after that. Development I can hand off and walk away. The core split is that Hyprland workspaces answer which project I am in, and Herdr answers who inside that project is running and who is blocked on me. My layout is workspace 1 for interruptions, 2 to 4 one project each with no distinction between slides, analysis, or code, 5 as a shared material desk, 9 for long running jobs, and 6 to 8 deliberately empty. Then six keys that actually save time, and two keys that hurt. The last section is honest about the goal. None of this lets me do more at once. What it does is cut the switching cost and stop me from missing the pane that has been waiting on me.
I rarely do only one thing at a time. A normal day looks like this. A slide deck is being edited, a question is being looked into, and there is still something open on the Rails blog. This page is how I fit that state into Omarchy.
The conclusion first, because the rest of the page is just that sentence expanded. Hyprland workspaces answer which project I am in. Herdr answers who inside that project is running and who is blocked. The two layers should not cover for each other.
Why the two layers need to stay separate
The easiest mistake is using one layer to do the other layer's job.
If you only use Hyprland workspaces, you end up opening every agent as a window and spreading them over ten workspaces. Then you have no idea which one is finished and you have to switch through them one by one.
If you only use Herdr, you end up trying to push slides, a browser, and PDFs into a terminal, and those things were never in a terminal to begin with.
The split is natural. A workspace is space, and one workspace is the whole setting for one project. Herdr is the terminal inside that setting, and it knows whether the agents in there are alive or done. What Herdr is and what it can do is a separate page, Herdr: What Multiple Machines and Multiple Agents Actually Look Like on Screen.
Three things that look different but are the same underneath
Making slides, analysing a problem, and writing the Rails blog sound like three different kinds of work. But what I actually do in all three is the same. I open a Claude, give it the context, wait for it, review what it gives me, and go another round. None of them is me sitting there typing from nothing.
That matters a lot for the layout. It means all three projects are "something is running and I am waiting", so all three belong in Herdr, not just the coding one.
The real difference is not the tool. It is whether I have to be there.
| Work | How long one round takes | Do I need to be there | Where it goes |
|---|---|---|---|
| Slides, editing images | Short, seconds to a minute or two | I look at almost every round | The focused workspace, I stay with it |
| Analysing a problem | Medium | I feed context at the start, then it can run on its own | Focused at first, then handed to Herdr to mark state |
| Rails blog, the LINE bot, a Spectra apply | Long, minutes to tens of minutes | I can send it off and leave | Fully on Herdr, it calls me back |
This line is far more useful than "which tool for which job", because it decides one thing directly. Which panes do I go and check, and which panes can just notify me.
It also means DHH's setup, four or five machines with three agents each, is not completely unrelated to mine. The only difference left is scale. He does this full time. I have a hospital job during the day, so I usually have two or three going.
How I lay out the workspaces
Omarchy gives you ten workspaces on SUPER + 1 through SUPER + 0. My rule is one workspace per project, not one workspace per application.
| Workspace | What is in it | Note |
|---|---|---|
| 1 | Interruptions | Discord, messages, mail. All of it in this one workspace so the others stay clean |
| 2 | Main project | Whatever matters most right now, usually the one with a deadline |
| 3 | Second project | The second one |
| 4 | Third project | Usually the blog or the wiki, where nobody is waiting on me |
| 5 | Source material and reference | PDFs, policy documents, screenshots people send me. Feeding context and reviewing output both happen here |
| 9 | Long running jobs | Kamal deploys, tests, NanoClaw logs |
| 10 | Odds and ends | Quick lookups, cleared when done |
6, 7, and 8 are empty on purpose. Three free workspaces are there for whatever comes in, so I never have to break an existing setup to make room for something urgent.
Workspaces 2 to 4 are one project each, regardless of whether it is slides, analysis, or code, because the same thing drives all of them. Each one is built the same way, a Herdr running that project's Claude plus one window for looking at the output. Only that second window changes.
| Project type | What runs in Herdr | What the window next to it shows |
|---|---|---|
| Slides | Claude generating images or reworking layout | An image viewer, one version at a time |
| Analysing a problem | Claude reading material and organising it | The original documents, PDFs, official letters, screenshots |
| Rails development | Claude Code plus Codex reviewing | A browser on the local page |
The Herdr in each workspace is pinned to that project's directory. Slides and analysis need their own directories too. Do not leave everything in the home directory.
Workspace 5 is the only exception. It is not a project, it is the shared material desk. All three projects come here to pull things out, so it gets its own space, and it is where SUPER + CTRL + PRINT for OCR and SUPER + CTRL + V for clipboard history get used.
One naming rule
Name the Herdr session after what the workspace is for. Do not invent a second naming scheme. If workspace 2 is the LINE bot, the Herdr session in it is called fireline. Later, when you SSH in from another machine and reattach, you will be glad you did this.
The six keys that actually save time
I covered all 227 bindings in Omarchy 4 in Practice. For running several projects, these six are the ones I use over and over.
SUPER + CTRL + TAB goes back to the previous workspace. This is the one I feel the most. When you are doing two things at once you are not jumping around ten workspaces, you are going back and forth between two. This key is faster than pressing a number and you do not have to think.
SUPER + S is the scratchpad. Throw a window in and it disappears from the screen while the program keeps running. It is for the thing you have to deal with later but do not want to look at now, like an email you have not worked out how to answer.
SUPER + G turns windows into a tab group. When one project has four or five windows open, group them into tabs so the workspace does not get chopped into small boxes.
SUPER + CTRL + PRINT is screen OCR. I use this most when analysing something. A screenshot somebody sent, a scanned letter, a table inside a remote desktop. Select it and it becomes text you can paste.
SUPER + CTRL + V is clipboard history. Essential for moving things between projects. You copy a paragraph in workspace 5, switch to workspace 6, and find the clipboard has already been overwritten. This key gets it back.
SUPER + BACKSPACE makes a window transparent. For comparing two documents.
There is also a safety net. If you forget a key, press SUPER + K and search.
Two keys that hurt
When several projects are running, these two cost much more than usual.
CTRL + ALT + DELETE closes every window, and it does not ask whether you want to save. Normally you lose one setting. With four projects open you lose four at once.
SUPER + SHIFT + ALT + a number moves a window silently. The window vanishes to another workspace while you stay where you are. The first time it happens you will think the program crashed. With several projects open, you will not be able to find where it went.
One thing I have not tested yet
Hyprland can have rules that pin a given program to a given workspace at start, so the whole setting comes back after a reboot. But Omarchy 4 moved the Hyprland config to Lua and the syntax is not the same as the old .conf, and I have not tried it on my machine yet.
It is worth doing, because it would turn the table above from "I remember to arrange it this way" into "it is like that when it boots". I will add it here once I have tested it.
The point is not to do more
The last part has to be honest, otherwise this page turns into a tool advertisement.
None of the above lets me handle more things at once. I can only review one thing at a time, and that is a hard limit that has nothing to do with tools. What this layout actually solves is two other problems.
One is the switching cost. Going from slides to the blog used to mean finding the windows again and remembering where I had got to. Now I switch over and the setting is already there.
Two is missing the pane that is waiting on me. That is the real failure mode of running several things at once. It is not that the work is slow, it is that something has been blocked waiting for an answer and you find out thirty minutes later. Hyprland notifications plus the blocked state in Herdr are what fill that gap.
So the test for whether this is working is simple. If I get to the end of a day without discovering that something had been sitting there waiting on me, it worked.