BlueBerry2001

I don’t think people suddenly started doing other jobs. Marketing writing a short script or engineers building a presentation probably describes it better.

That stood out to me too. Right now it looks more like an infrastructure and security coalition than an industry-wide AI safety alliance.

Pretty cool, tried something like this as well. But had a lot more than 150 loc.

So true

GOATed plane, love the engine power.

Actually very useful. Thanks

fair point

Fair point. I probably should have submitted it as Show HN.

I posted it more as a progress/update thread because I was mainly looking for feedback from people with heavy terminal or multi-window workflows, but I agree that the format fits Show HN better.

Fair point. The wording was a bit clickbaity, I get that.

It’s definitely not dead though. Quite the opposite: the project is actively growing and improving. The first post didn’t get much traction, but we kept working on it, fixed a lot of rough edges, and v1 is in a much better state now.

I should have phrased that more clearly.

Do you mean the demo on website?

Yeah, that’s pretty much how I see it too.

Cate is not trying to compete with tiling/scolling WMs. Those are better if the main problem is arranging normal OS windows.

The goal here is more project-scoped: one spatial canvas where terminals, browser previews, editors, docs, notes, agents, git/worktrees, and saved layouts live together. More like a persistent workspace for a single project than a global desktop environment.

Thanks for the pointer, I actually didn’t know Haystack before. Looks like it belongs in the prior-art / inspiration section, so I’ll add it to the README.

From a quick look, I agree there is overlap around the canvas editor idea. Cate is aiming a bit more at the broader project workspace layer: terminals, browser previews, editors, notes, agents, git/worktrees, docking/tabs/splits, and persistent layouts around a project.

But yes, fair callout. Appreciate the input.

That would be a really interesting direction, and I agree it fits the idea well.

Right now Cate is a local desktop app because we wanted the first version to work closely with local projects, shells, files, node-pty/xterm, browser panels, Monaco, git worktrees, etc.

A self-hosted web version would need a different architecture: a backend that owns the PTY sessions, keeps them alive when the browser disconnects, handles auth/security, and syncs the canvas state to the client. Definitely possible, but a bigger shift than just “put the current app in the browser”.

Long term I think remote/headless workspaces and reconnectable sessions would make a lot of sense.

Nice, I just checked terminaldraw. Very similar core idea, but interesting that you used tldraw more directly as the canvas engine.

Cate is a bit broader in scope: Electron desktop app, persistent project workspaces, node-pty/xterm terminals, browser panels, Monaco editors, docs, git/worktrees, docked tabs/splits, and now agent panels as well.

PTYs were a fun rabbit hole. The basic idea is simple, but making terminals feel native inside a canvas is where it gets tricky: lifecycle, resize behavior, restoring sessions, shell fallback, scrollback, performance, and not breaking when panels are moved/docked/detached.

Cool to see someone else exploring the terminal + canvas direction too. I’ll take a closer look at your repo.

Yeah, that was one of the main challenges and still is.

We chose Electron because the goal for v1 was to make Cate easy to try across macOS, Windows, and Linux without asking people to change their OS setup or use a specific window manager. A native implementation would probably give us more control and better performance in some areas, but it would also make iteration and cross-platform support much harder at this stage.

The HTML/canvas approach definitely has tradeoffs. Large canvases, XY transforms, terminals, browser previews, editors, and agents all in one workspace can get expensive if handled naively. We’ve been working on viewport-based rendering, transform handling, and avoiding unnecessary re-renders, but it is still an ongoing performance challenge.

So yes, we accounted for it, but I would not claim it is “solved”. v1 is much better than the early builds, and we’re continuing to improve it.

That’s fair. Infinite canvas is not for everyone. I think the important part is that it does not have to mean “everything everywhere forever”. Cate also has docking, tabs, splits, project-based layouts, and search, so you can use it more structured if you want. But yes, for some people a finite or stricter workspace model will feel better.

Yeah, I understand that direction. A more native/headless or Rust-based version could be interesting long term, especially for performance and battery life. For v1 I kept it as a cross-platform desktop app so people can try the workflow without changing their OS setup. But collaborative sessions, remote/headless workspaces, and AI-assisted sessions are definitely in the same general direction as what Cate is trying to explore.

I get that. A native WM version would be interesting, especially for performance and deeper OS integration. For now Cate is intentionally an app because it is easier to try, cross-platform, and focused on project-level workflow rather than managing the entire desktop. But I agree the boundary between spatial workspace and window manager is a real discussion.

Yeah, that’s basically the mental model I’m aiming for. Not “replace the desktop”, but one pane of glass for a specific project/workflow. Some people prefer strict OS-level windows, others seem to think better when the project is laid out spatially and persists between sessions.

Exactly. I agree that the OS/window manager is the “proper” layer in theory. In practice, building it as an app makes experimentation much easier: cross-platform, lower friction to try, no need to replace your current WM, and we can iterate on workspace-specific features like terminals, browser panels, agents, Cmd+K search, worktrees, docking/tabs/splits, etc.

Because native virtual desktops still mostly preserve app windows, not project context. Cate is more scoped: one workspace per project/folder with terminals, browser previews, editors, notes, agents, worktrees, docked tabs/splits, and restored panel positions. It’s not meant to replace GNOME/KDE/macOS/i3 globally, more to keep the messy project-specific layer in one persistent place.

That’s a valid concern and probably one of the biggest risks with an infinite canvas. The goal is not “infinite mess”, but persistent context with enough structure: docking, tabs, splits, search via Cmd+K, detachable panels, project-based canvases, and restored layouts. I also think things like expiry/cleanup, saved views, folders or semantic grouping would make sense over time. Retention of context is basically the whole product question here.

Yeah, I agree. I think we are in an interesting phase where people are rethinking the “IDE as one fixed rectangle” model. Cate is one attempt at that from the spatial side: persistent canvases, terminals, browsers, notes, agents, docks, tabs, splits, worktrees etc. It may not be the final shape, but I think there is room for more experimentation around how long-running AI/dev workflows are organized.

That’s fair. I probably need to explain that distinction better. Cate is not trying to replace the OS window manager globally. It’s more a project workspace where terminals, browser previews, notes, agents, editors, and docs can stay arranged together and be restored per project. A native WM version would be interesting, but the app approach makes it easier to test the workflow across macOS, Windows, and Linux without asking people to replace their desktop setup.

Been sharing progress on Cate here for a while. v1 is finally in a pretty solid state now: https://github.com/0-AI-UG/cate, https://cate.cero-ai.com

Cate is an open source desktop workspace built around an infinite canvas. Instead of constantly switching between terminals, editors, browser previews, docs, and AI tools, you arrange everything spatially in one place.

Big improvements since the earlier posts:

docking, tabs, and splits detachable native OS windows git worktree support unified Cmd+K search much smoother rendering/performance on larger canvases AI provider + MCP integration Stack: Electron, React, Monaco, xterm.js/node-pty, Zustand.

Runs on macOS, Windows, and Linux. MIT licensed.

Would love feedback from people with heavy multi-window or terminal-based workflows.