One window: Unity modes, extra clones, agent terminals, alerts, the editor, search, logs and resource stats. What makes them worth having together is the game running beside them.
A normal Unity-with-agents setup is an editor, a terminal, an IDE, a browser and the Unity console, and the work is mostly moving between them. Every switch is a small tax, and the taxes are why "just check whether it worked" so often turns into ten minutes.
Satura Space puts the pieces in one place, arranged around the game itself, running, streamed into the same window.
.gitignore-aware file tree, so Library/ and friends stay out of your way.The engine package also registers Satura Space as Unity's External Script Editor, so double-clicking a script in the Unity editor opens it here rather than launching a separate IDE.
Unity's console streams in with error and warning counts, per-player filtering and every Debug.Log line searchable. With multiplayer clones running, each client's output is filtered separately, so you read one client at a time instead of four interleaved logs.
Several Unity instances plus several agents is a lot of process. The app reports live CPU and memory for every terminal, every Unity instance and every internal process, so you can see a runaway agent or a wedged editor instead of deducing it from the fans.
Alongside it, the status bar reads out Claude and Codex session and weekly limits with reset times, so a spent plan is visible before it interrupts a run.
Running agents in parallel only pays off if you are not babysitting them. A finished turn flashes the tab green and plays a sound; a stop waiting for permission flashes amber. Both work from tabs you are not looking at. Nine sounds ship with the app, including the Half-Life HEV beeps.
Terminals run in a detached daemon that owns the pty out of process. Quitting or updating Satura Space does not kill an agent mid-thought, and reattaching replays the scrollback from a ring buffer. See coding agents for how that plays out over a long run.
Launch is a single screen: pick a folder, choose your terminals and agents (down to model and reasoning effort for Claude Code), pick the Unity mode, and optionally create a fresh git worktree so the session is isolated from your main checkout. On macOS the Library clones instantly with no extra disk. Then press Launch. An agent can branch itself a worktree later too, through unity_worktree_create.
Panes + git blameAlso Unity's External Script Editor, so .cs opens here.
ripgrep-backedStreaming full-text search with replace, plus fuzzy quick-open.
Per-playerThe Unity console with counts, filtering and search.
Live CPU + memoryPer terminal, per Unity instance, per internal process.
Yes: syntax highlighting, a git blame gutter, multiple panes, full-text search with replace and fuzzy quick-open, over a .gitignore-aware file tree.
Yes. It streams into the app with counts, per-player filtering and every Debug.Log line searchable.
For reading, searching and fixing code beside a running game, it's usually enough. For heavy refactoring in a large solution, keep your IDE; the project on disk is an ordinary Unity project.
Claude and Codex session and weekly limits, with reset times, straight from the status bar.
They survive. The pty is owned by a detached daemon, and reattaching replays the scrollback.
Yes. Launch each in its own git worktree, or let an agent create one for itself with unity_worktree_create. On macOS the Library clones instantly, so a second session costs almost no disk.
Editor, terminals, search, Unity logs and stats, all around a game that is already running.