con-terminal: a Rust terminal emulator that ships an AI harness in the same window

Who con-terminal is aimed at, and what it refuses to be

The README states the target audience in one line: people who want a serious terminal first and AI help only when it earns its place. The framing is deliberately narrow. con is not a chat application that happens to render a shell; it is a terminal emulator with an agent attached, and the marketing copy says so with the phrase "nothing more". The stated users are old-school terminal people who want an AI harness only when needed, plus anyone running CLI work over ssh and tmux.

That positioning matters because it sets an expectation the rest of the project has to meet. If the terminal itself is slow or the keybindings fight the shell, no amount of agent integration saves it. The repository topics list libghostty alongside rust, agent and skills, which suggests the rendering layer is not written from scratch. The README does not spell out what libghostty contributes here, so treat the rendering internals as unverified. What is verifiable is the language (Rust), the licence (MIT) and the claim of GPU acceleration.

Two input surfaces and a mode switch that decides who acts

con's mechanism is easier to understand as two text entry points feeding one decision. There is a bottom input bar, toggled with Control-backtick on every platform, and there is an agent panel, toggled with Command-L on macOS or Control-Shift-L on Windows and Linux. Focus moves between the terminal and the input with Command-I on macOS, or Control-Shift-I elsewhere.

The interesting part is Smart mode, cycled with Command-semicolon on macOS or Control-semicolon on Windows and Linux. According to the README, Smart mode decides whether your text is a shell command or an agent request. That is the core routing logic: the same input line can become either a command or a prompt, and the mode determines which. Command mode runs shell commands, and when multiple panes are open, a pane mini map lets you target the focused pane, all panes, or a selected set. Agent mode sends text directly to the built-in agent.

The README also says the harness can read context, ask before acting, and work directly in the terminal you can already see. The confirmation step is the design choice worth noting. An agent that asks before acting is slower than one that does not, and this is a deliberate trade in favour of observability over throughput. Nothing in the supplied material describes how context is gathered, how large the context window is, or which model provider sits behind the agent. Those are open questions.

Installing con and getting con-cli onto your PATH

macOS has two documented paths. The Homebrew route is a single command:

brew install --cask nowledge-co/tap/con-beta

The README states this installs the app and exposes con-cli on your PATH for automation. The script route is:

curl -fsSL https://con-releases.nowledge.co/install.sh | sh

On macOS this installs the app into /Applications and links con-cli into ~/.local/bin. On Linux, described as preview with an official installer, the same script installs both con and con-cli into ~/.local/bin. A DMG is also offered directly from Releases, and the Linux section mentions a con-<version>-linux-x86 artifact, though the README text is truncated at that point.

The con-cli binary is the piece that matters for anyone automating this. It is the only documented programmatic surface; the README does not describe its flags or subcommands. Quick Terminal, a separate feature, is off by default. On macOS it has to be enabled in Settings -> Keys before the global shortcut (Command-Backslash) does anything, or it can be opened from the command palette or the View menu while Con is frontmost. That is a real setup step, not a footnote.

Platform status is the first thing to check before you commit

The README is unusually direct about this. con is in active beta development. macOS is fully supported, beta. Windows is early beta with a tracker issue. Linux is preview with its own tracker issue. The Windows and Linux badges link to issues 34 and 18 respectively, and the Quick Terminal row in the controls table reads "Not available" for Windows and Linux.

So the honest summary is that this is a macOS product with two ports in progress. If your daily driver is Linux, you are being asked to run a preview build of a terminal emulator, which is the one piece of software where a crash costs you every other session you had open. The release cadence reinforces the beta reading: v0.1.0-beta.95, .96 and .97 landed on 2026-09-05, 2026-09-07 and 2026-09-09. Three releases in four days is a project still finding its footing, not one that has settled. Frequent releases are not inherently bad, but they do mean the surface you install today is not the surface you will have next week, and the version string has not yet reached 0.1.0.

The cost of putting an agent inside the terminal

The main limitation is structural rather than a bug. An agent that lives in the terminal shares a namespace with the shell. The README describes a Smart mode that guesses whether your text is a command or a request, and guessing is the weak point. A line that looks like prose to you may look like a command to the router, and the reverse. The README does not describe an override beyond cycling the bottom-bar mode manually, which means the fallback is a keystroke you have to remember.

The second limitation is the ask-before-acting model. It is the right default for a tool that can run arbitrary shell commands, but it means the agent is not useful for unattended work. If your use case is a background agent that fixes a failing build while you are away from the keyboard, this harness is explicitly not that, at least not as documented.

The third is that the AI layer is undocumented in the material available. There is no statement about model choice, local versus remote inference, data retention, or whether prompts leave your machine. For a tool whose selling point is reading terminal context, that gap is the thing a security reviewer will ask about first, and the README does not answer it. There is an llms.txt file published for agents, which suggests the project expects machine readers, but it is not a substitute for a privacy statement.

How this differs from running an agent next to a normal terminal

The obvious alternative is the arrangement most people already have: a conventional terminal emulator plus a separate CLI agent, or an editor with an integrated terminal and a chat pane. The difference is where the boundary sits. In the split arrangement, the agent is a process inside the shell. It sees what you pipe to it and what it can read from disk. It does not share the emulator's view of the screen buffer, and it cannot address panes, because the emulator has no idea an agent exists.

con moves the agent up a layer. Because the harness is part of the emulator, the README can claim it works directly in the terminal you can already see, and the pane mini map can route a command to the focused pane, all panes, or a selected set. That pane-level targeting is the concrete capability a shell-side agent cannot replicate without the emulator's cooperation. The trade is that you give up composability. A separate agent is a process you can script, wrap, version-pin and swap. con's harness is bound to the application, and the only escape hatch documented is con-cli, whose interface is not described. If you already have a working agent pipeline, con asks you to move it inside a beta GUI.

Maintenance, licensing and what the beta cadence implies

The licence is MIT, stated in the README badge and the repository metadata. MIT is permissive: it allows commercial use, modification and redistribution, with the requirement that the copyright notice and permission notice travel with copies. It does not include a patent grant, and it gives no warranty. That is a general property of the licence text, not legal advice for your situation; if con ends up inside a product you ship, have counsel read it.

The maintenance picture is the harder question. The project is at v0.1.0-beta.97 with a last push of 2026-09-10, one day after the most recent release. That is an active repository. What the material does not show is who maintains it, how many people are behind it, or whether the Windows and Linux trackers have momentum. The topics list includes skills and workflow, which hints at a roadmap beyond the emulator core, but no roadmap is included in the README.

The practical upgrade cost is tied to the delivery channel. Homebrew cask installs and the curl installer both pull from con-releases.nowledge.co, so upgrades are whatever those channels serve. Because the version is still beta.N, expect the configuration surface to move. The Settings -> Keys step for Quick Terminal is the kind of thing that tends to change between betas, and there is no documented config file format in the supplied material, which means your settings likely live in application state rather than a version-controllable file. If reproducible machine setup matters to you, that is a gap worth confirming before you standardise on con.

Editorial conclusion

Adopt con if you live in ssh and tmux on macOS, want an agent that shares the visible buffer, and can tolerate a beta that is still shipping releases every couple of days. Do not adopt it if you need a stable Linux or Windows daily driver, or if you want an agent that can act without asking, since the README describes an ask-before-acting harness. Verify three things first: that the Homebrew cask nowledge-co/tap/con-beta resolves on your machine, that con-cli lands on your PATH after the install script, and that the agent panel shortcut (Command-L on macOS) does not collide with your window manager or tmux prefix.

Official sources

1. License: MIT
2. nowledge-co/con-terminal on GitHub
3. Project website
4. README
5. Releases