A terminal is where work happens — but a surprising amount of work around the terminal happens elsewhere: in a browser tab, a notes app, a system monitor, or a calendar. Every one of those is a context switch, and context switches are where focus goes to die.
Sidebar widgets are our answer to a specific complaint: “I love the terminal, I just keep leaving it.” This post covers why that happens, what each widget is for, and the design rules we used to decide what earns a permanent slot in your window.
The Real Cost of Context Switching
You glance at a memory graph in Activity Monitor, switch back, and have to rebuild your mental model of what the command on screen was doing. You open a notes app to jot down a connection string, then scroll past yesterday’s grocery list to find it. You check a browser tab for the time of your next meeting and lose the thread of the error you were reading.
None of these detours are big on their own. Together they fragment an afternoon. The research on this is consistent: the cost is not the seconds spent switching, it is the minutes spent reloading the context you were holding. That reload is the tax.
So the design constraint for widgets is narrow and unforgiving: keep supporting context next to the output, not one app-switch away. A widget that requires its own window has already failed the test.
System Stats Without the Extra Command
The CPU and RAM widget monitors your machine in real time, so you can see the spike the
moment a build or test suite starts — no top in another pane, no reaching
for Activity Monitor, no second terminal you opened just to run a monitor.
The interesting engineering is underneath. Stats polling is centralized across the app, so multiple widgets share a single sampler instead of each running its own timer. That keeps idle energy use down and means adding a second view of the same data is effectively free. The widget reads from one publisher; it does not own a clock.
A small but important detail: the widget updates on a human cadence, not a per-frame one. Watching a number tick sixty times a second is noise, not information — and it costs battery for nothing.
Markdown Notes That Live Next to Your Logs
The Notes widget is a persistent, auto-saving markdown notepad docked beside your panes. Keep connection strings, runbooks, or that regex you always have to look up right where the work is:
- Auto-saving — never hit
cmd-sagain. Close the app and the note is exactly where you left it. - Markdown rendering for checklists, tables, and inline code, so a runbook reads like a document rather than a scratchpad.
- Persists per workspace, so each project keeps its own notes instead of mixing staging credentials with the notes for your side project.
The per-workspace part matters more than it sounds. A single global notepad becomes a junk drawer within a week. Scoping notes to the project keeps the signal-to-noise ratio high enough that you actually trust what you read.
Calendar Without Leaving the Prompt
The Calendar widget keeps the time and your schedule in view. That is genuinely useful when a deploy is running and you have a meeting in ten minutes, or when you are deciding whether there is room to start one more task before lunch.
It is also a good example of our restraint rule: it shows what you need — the current time and the next events — and nothing else. There is no month grid to click through, because if you need to manage your calendar in depth, a full calendar app is the right tool. The widget exists to answer “what time is it and what is next?” in a glance.
Keyboard-First, Always
Widgets are useless if reaching them costs a click. Everything in the app is reachable from the keyboard, so the mouse stays optional throughout:
⌘⇧D— split the focused pane⌘⇧L— cycle layout presets⌘⇧[/⌘⇧]— move focus between panes⌘K— open the command palette⌘⇧T— toggle the widget sidebar
It is a small list of shortcuts that compounds into hours of saved attention. The rule we hold ourselves to: if a feature needs the mouse, it is not finished.
How We Decide What Earns a Widget
Adding a widget is easy. Adding a widget that does not become clutter is hard. Every candidate has to clear the same bar:
- It answers a question you ask at least daily. Occasional tools belong in a separate app.
- It is glanceable. If it needs to be read carefully, it is a pane, not a widget.
- It stays quiet. No notifications, no badges, no animation when nothing has changed.
- It is scoped to the workspace. Context should follow the project, not the app.
Features that fail these tests stay out — even when they are popular requests. Every widget we add takes a slice of a finite window and a slice of your attention, and both are expensive.
The best sidebar is the one you forget is there until the exact moment you need it.
Stay in Flow
Widgets, layouts, and shortcuts all serve one goal: fewer interruptions between you and the command you are about to run. Try it for a week and notice how many times you used to leave the window — that number is the whole pitch. Download LayoutCLI and keep your entire workflow in one window.