Horizon: an infinite-canvas terminal board for people running several coding agents at once
GPU-accelerated terminal board that puts all your sessions on an infinite canvas
At a glance
- What is it?
- Horizon is a Rust desktop application that replaces the tab strip with a pannable 2D canvas of live terminal, browser, and editor panels. It is aimed at developers who keep multiple agent sessions open and want them spatially arranged rather than stacked, and its main cost is that it is a young project whose documentation stops at the README.
- Who is it for?
- Horizon fits developers who already run several agent CLIs in parallel and lose track of which terminal holds which session. It does not fit anyone who wants a stable, widely documented multiplexer with a plugin ecosystem, or who works mostly over SSH on machines where a GPU-accelerated desktop app is not an option.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Horizon is aimed at
A tabbed terminal gives you one visible session and a row of labels. Once you are running a shell, a Claude Code session, a Codex session, and a browser pointed at localhost, the tab strip stops telling you anything useful. You switch to a tab, read the scrollback, and switch back. Tiled layouts fix the visibility problem but impose a fixed grid, so a wide diff and a narrow log viewer get the same cell.
Horizon takes a third position. The README describes it as a canvas, an infinite 2D surface where every terminal, agent, browser, and editor lives as a panel you can place, resize, and group. The intended user is someone who keeps several long-running agent sessions alive and wants to see them simultaneously without committing to a grid. The README's own framing is a whiteboard for live sessions, with color-coded workspaces, presets, and a command palette layered on top.
That is a narrow audience. If you run one terminal and one editor, the canvas adds navigation cost with no payoff, because panning and zooming are work you do not currently have to do.
Five nouns, and why the vocabulary matters
The README defines a small object model: Canvas, Workspace, Panel, Preset, Session. A canvas holds workspaces, a workspace is a color-coded cluster with a shared working directory, a panel is one live surface inside a workspace, a preset is a named template for creating a panel, and a session is a saved board.
The shared working directory on a workspace is the detail worth noticing. It means a shell panel, a git_changes panel, and an agent panel created inside the same workspace all start from the same directory, so the git panel is showing diffs for the repository the shell is sitting in. That is a design decision, not a neutral container: if you want two unrelated repositories visible at once, you need two workspaces, and the README's example board shows exactly that pattern with a Backend workspace at ~/projects/api and a Frontend workspace at ~/projects/web.
Panel kinds listed in the README are shell, ssh, browser, editor, git_changes, usage, and command, plus first-class entries for grok, claude, codex, open_code, gemini, kilo_code, and pi. The agent panels are not generic terminals with a command typed into them. The README states that title bars show a working indicator and, when a session is bound, its session id, and that a usage panel tracks token spend across agent panels. Session persistence and resume are described as working where the CLI supports it, which is an explicit hedge rather than a blanket promise.
What the rendering stack implies
Horizon is written in Rust and the repository topics name egui and wgpu, so the canvas is drawn on the GPU rather than composited from native widgets. The README also states that terminal emulation is powered by the Alacritty terminal engine, and lists 24-bit color, mouse reporting, scrollback, alt-screen, and Kitty keyboard protocol as supported.
Borrowing Alacritty's engine is the pragmatic choice here. Terminal emulation is a long tail of escape sequences, and a canvas application is not the place to reimplement it. The consequence is that Horizon inherits the behavior of that engine rather than defining its own, including the click-through rule the README calls out: clicking a TUI sends the click to the application, and Shift+click still selects text. If you are used to a different multiplexer's selection defaults, that is the line to test first.
The GPU dependency is also a constraint in disguise. A canvas that repaints through wgpu assumes a working desktop graphics stack. The README lists Linux, macOS, and Windows as platforms, but it says nothing about remote or headless use, and there is no indication in the supplied material that Horizon can attach to a session over SSH the way a terminal multiplexer running on the remote host can. The ssh panel kind covers connecting out to remote hosts, not running the board itself remotely.
Getting a board running
The README states that you do not need a config file to start. Launch Horizon, then Ctrl+double-click empty canvas to get a preset list. Picking Shell, Grok, Claude, or another agent preset prompts for a working directory, which becomes the workspace cwd and the location of the first panel.
From there the shortcuts in the README are the whole workflow. Ctrl+Shift+N creates another panel of the first preset, Shell by default. Ctrl+Shift+K opens the command palette, where a bare string searches workspace names and panel titles, @ restricts to panels, and > restricts to presets and actions. Ctrl+Shift+9 fits the workspace into view and Ctrl+Shift+W jumps to it without changing zoom. Ctrl+Shift+J switches between saved boards. Ctrl+Shift+H opens the SSH and Tailscale host overlay. Ctrl+Shift+, opens Settings, which the README says edits ~/.horizon/config.yaml while the canvas stays visible behind it.
Arrangement is per workspace: Default leaves panels free-dragging, while Rows, Cols, and Grid impose structure. The README also mentions a Detach control on the workspace header that moves a workspace into its own OS window. Panning is middle-mouse or Space+drag, zoom is Ctrl+scroll, and a minimap in the corner can be clicked or dragged to jump.
The persistence claim is the one that decides whether this is usable day to day: the README states that after closing and reopening, the session, layout, canvas pan and zoom, and terminal history are still there. That is a specific and checkable claim, and it is worth verifying on your own machine before you build a workflow around it, because terminal history restoration is the part most likely to behave differently across shells.
The browser panel is the unusual part
Most of Horizon's feature list has an equivalent somewhere: infinite canvases exist, saved layouts exist, command palettes exist. The browser panel is the piece with fewer obvious counterparts. The README describes running Chromium, Firefox, or Safari automation on the canvas, with the human and the agent sharing the same live page: navigate, inspect, click, fill, capture network traffic, then hand control back and forth.
Sharing one page rather than giving the agent its own headless instance changes the debugging loop. When an agent's click fails, you are looking at the same DOM state it acted on, not a screenshot it captured. The README does not describe the control protocol, so it is not possible to say from the supplied material how handoff is arbitrated, whether the agent drives the browser through a local automation port, or what happens if both sides act at once. That is a gap, and it is the first thing I would look for in the source tree.
The same caution applies to the usage panel. The README says it tracks token spend across agent panels, but it does not say where those numbers come from. If they are parsed from each CLI's own output, coverage will vary by agent and version. Treat the dashboard as a convenience until you confirm the source of its figures.
Where Horizon is the wrong tool
The clearest failure mode is remote work. A terminal multiplexer runs on the machine where the sessions live, so you can detach, disconnect, and reattach from anywhere. Horizon is a desktop application that draws on a local GPU. Its ssh panel kind connects out to remote hosts as panels, but nothing in the supplied material suggests the board itself survives losing your connection, and the saved session lives on the machine running the app. If your sessions live on a build server and you reach them from a laptop, Horizon is not replacing tmux for you.
A second limit is the agent matrix. Seven agent CLIs are listed as first-class panel kinds, and the README qualifies session resume with where the CLI supports it. That phrasing means the integration depth is not uniform. If you depend on resuming a specific agent's session after a restart, confirm that the CLI you use exposes a resume mechanism the panel can drive.
A third is documentation surface. The supplied README is long on shortcuts and short on internals. There is no architecture section, no description of how the browser panel is controlled, and no statement about what the config.yaml schema accepts beyond the fact that Settings edits it. For a project at v0.2.7, that is normal, but it means reading the source is part of the evaluation rather than an optional step.
How it differs from a terminal multiplexer
The honest comparison is tmux, and the difference is not cosmetic. tmux is a server and a client: the server owns the sessions, the client is a thin view, and detaching is a first-class operation. Panes are constrained to a window grid, and the layout is a tree of splits. Horizon inverts both. The application owns the sessions, the canvas is unbounded, and panels are placed at coordinates rather than derived from splits. There is no detach in the tmux sense, only Detach of a workspace into a separate OS window.
The other difference is what a panel can be. A tmux pane runs a program. A Horizon panel can be a program, a browser page, a markdown editor with split preview, a git changes view, or a usage dashboard. That is a different product category: an integrated workspace rather than a multiplexer. The cost is that each of those panel kinds is code Horizon has to maintain, and each one is a place where the project can fall behind the tool it wraps.
If you want sessions that outlive your client and a layout expressed as splits, tmux is the better fit and always will be. Horizon is for the case where the sessions are on the machine you are sitting at and the problem is visual organization, not connection resilience.
Licence, releases, and what to check before adopting
Horizon is MIT licensed, which is permissive and imposes no copyleft obligation on your own code. It does not address the licences of the coding-agent CLIs the panels launch, and it does not tell you whether the browser automation path depends on components with different terms. Those are separate questions you have to answer for each integration you enable, and nothing here is legal advice.
The release cadence visible in the supplied data is three releases between April and August 2026, with the most recent push in September 2026. That is an active but not rapid pace, and the version number, v0.2.7, indicates the project has not declared a stable interface. Configuration keys in ~/.horizon/config.yaml and preset aliases are the kind of thing that can shift between minor versions at this stage, so keep a copy of your config outside the default path before upgrading.
What to verify first, concretely: that a build exists for your platform and runs against your graphics stack; that Ctrl+Shift+J actually restores a board with terminal history intact after a full application restart, since that is the claim the whole workflow rests on; and that the specific agent CLI you use reports session ids the panel can bind to. Everything else in the README is a shortcut you can learn in an afternoon.
Editorial conclusion
Horizon fits developers who already run several agent CLIs in parallel and lose track of which terminal holds which session. It does not fit anyone who wants a stable, widely documented multiplexer with a plugin ecosystem, or who works mostly over SSH on machines where a GPU-accelerated desktop app is not an option. Before adopting it, verify three things yourself: that your platform has a working build for the current release, that the coding-agent CLIs you depend on actually support session resume in the version you have installed, and that the MIT licence terms match how you intend to ship or redistribute it.
Community notes