Most agentic coding today happens inside an IDE. Cursor, VS Code with Copilot — the editor owns the agent, and the terminal is just a panel at the bottom. But the terminal itself is having a moment, and two projects prove it:
cmux is genuinely awesome — vertical tabs, notification rings when agents need attention, split panes, a socket API. It's also macOS-only, native Swift on libghostty, with Windows and Linux on a waitlist.
Intelligent Terminal, Microsoft's experimental fork of Windows Terminal from Build 2026, docks an ACP-compatible agent pane (Copilot, Claude Code, Codex, Gemini) next to your shell. Windows-only, by definition.
Both are great. Both are locked to one platform. That gap is why I built Hyperia: an open source, platform-agnostic, agent-native terminal that runs the same on Windows, macOS, and Linux — no waitlist for your OS. Signed binaries. Waiting on 1.x.x to ship before putting on the Microsoft Store.
The core idea: agents are tenants, not visitors. Hyperia ships a full MCP server, so anything that speaks the Model Context Protocol — Claude Code, Codex, or a small local model on Ollama — can drive the terminal directly: open tabs, split panes, run commands, read screens, right beside you.
One hard rule, enforced in the harness rather than a prompt: an agent can never steal your focus. You keep typing in your pane; agents work in theirs, in your peripheral vision. Review becomes glancing, not switching.
Hyperia doesn't run agents itself — that's a separate concern, handled by nemesis8.
n8 launches coding agents inside containers and wires everything together securely: the agent gets a sealed environment scoped to your workspace, Hyperia gets the panes. Terminal and runtime stay decoupled, so either one can evolve without breaking the other.
Architecture
Hyperia splits its visual interface and execution layers to ensure responsiveness:
- Electron UI (a fork of the open-source Hyper terminal) — handles layout, tabs, and native web panes.
-
Rust sidecar — owns PTYs, the MCP server (HTTP at
localhost:9800/mcp), consent/identity, and telemetry. Decoupling this means heavy agent traffic never janks the UI.
Three core building blocks
1. Doors — progressive tool disclosure
There are 120+ tools across the built-in agent and the external MCP surface. Handing all of them to a model every turn is expensive and, for a small local model on an 8k context window, fatal.
Hyperia exposes a small always-on core plus category "doors" the model opens on demand. This took the per-turn tool payload from a flat ~58 KB to ~6 KB, saving substantial token costs and reducing execution latency.
It also allows you to use a local model for "Token Maximus" filtering. The local model, if enabled, can act as a summarizer for the larger models. Hyperia's built in agent uses credit based tokens, but agent CLIs use your login tokens (raw token usage vs. plan usage). I'm working on getting a Gemma4:e4b model + drafter training pipeline (in a container or hosted) setup to allow others to fine tune their own drafters to run any MCP tool. More on that soon: https://sailfish.nuts.services
2. Consent at the API layer, not the prompt
State-changing actions — opening a window, driving another pane — hit a human-approval gate in the sidecar. Identity is a low-privilege token that names the agent; it grants nothing on its own. Autonomy with a leash beats autonomy with vibes. Toasts pop up for approval.
3. Web panes as native views
Browser panes sit next to terminals (native WebContentsView, not an iframe). An agent can read the rendered, post-JavaScript DOM as clean Markdown — nav and chrome stripped to keep tokens down — so "read the docs you have open" is one call, not a scrape.
Concrete MCP Example
Agents interact with Hyperia using standard MCP JSON schemas. For instance, to read the content of an open Web Pane:
{
"ServerName": "hyperia-mcp",
"ToolName": "web_pane_content",
"Arguments": {
"pane": "DEV Community (65a885bd)"
}
}
The server returns the clean, reader-mode Markdown structure directly back to the agent:
# DEV Community
- Announcing the First DEV Education Track: "Build Apps with Google AI Studio"
- Gemma and sandboxing cause a stir at the World's Fair
...
🧰 Secondary Features
⚡ Click to expand: Stickys™, Memory, & Command History
- Stickys™: Persistent notes that can be written, updated, and queried by both you and the agent.
- BM25 Search over History: Locally indexed terminal history allows agents to search past command logs to debug errors.
- Built-in Agent: Runs directly inside the terminal on your configured model (local or frontier).
What I actually learned building and using it
Frontier models feel great in this shape. Small local models were useless until I stopped blaming them and made the harness hand them unambiguous data: pre-rendered strings instead of raw JSON, hard caps on runaway loops, tool schemas slimmed to fit their window.
🔗 Links & Resources
- 💻 Hyperia GitHub ➔ deepbluedynamics/hyperia*
- 💻 Nemesis8 (n8) GitHub ➔ deepbluedynamics/hyperia*
- 🌐 Documentation ➔ Deep Blue Dynamics Docs (also, a WIP...standby for launch)
Still building in public. How are you giving agents real access to your terminal — and keeping yourself in the loop? Let's discuss in the comments below! 👇
Top comments (0)