Positioning · October 2026
What an AI shell is, and what it is not
A shell used to be the one place your work happened. You opened it, and everything you were doing was reachable from there. That stopped being true, and no amount of models bolted onto a chat window brings it back.
«AI shell» gets used for three different things right now: a terminal that can autocomplete a command, a chat client with a code editor next to it, and an agent runner. None of those is a shell. A shell is defined by what it holds, not by what it can call.
A terminal runs commands and forgets you
The terminal is still the most honest tool on your machine: it does exactly what you typed, on your files, with your permissions. That is why it survived fifty years.
What it has never had is memory of your work. Close the tab and the session is gone. The reason you ran that command, the three attempts before it worked, the decision you made at the end: none of it is anywhere. Add a model that suggests commands, and you have a faster terminal with the same hole. The model also forgets, and now it forgets on your behalf.
A chat window has the model but not your machine
A chat client gives you the model and a transcript. What it does not have is your machine: your repository as it is right now, your running processes, your keys, the folder you are actually in. Everything has to be pasted in, and everything useful that comes out has to be pasted back.
So the work ends up in pieces. Some of it in a chat history on someone's server, some in your notes, some in a terminal scrollback that no longer exists, some in a task tracker, some only in your head. Each piece is fine. The scatter is the problem, and it is the expensive one: every time you come back, you pay to reassemble the context before you can do anything.
So what has to be true for it to be a shell
-
It runs where your work is
On your machine, with your files and your permissions, not on a copy of them uploaded somewhere. A remote perimeter for heavy work is useful; it has to be a choice you make, not the only option.
-
It keeps the work, not just the output
Sessions, decisions, notes, tasks and terminals live in one system and stay addressable afterwards. The test for any feature: does it reduce the number of places your work lives?
-
The model is a rail, not the product
Your keys, your subscription, or a local model as the fallback. A shell you cannot run without one vendor's API is that vendor's client with your name on it.
That last one is the part people skip. If the shell is wired to one provider, every limit of that provider becomes a limit of your work: its pricing, its rate limits, its outage, its decision to deprecate a model you depend on. A shell that is worth the name treats the model the way a terminal treats a program: something you point it at.
Where this is today
Working now: the desktop app on macOS, Linux and Windows, and the same IDE in a browser. Real terminals with real PTYs, kept alive across restarts. Agent sessions you can watch and take over. Your own keys, a subscription, or a local model behind one facade. A canvas, boards, notes, and a journal of decisions that explains why the code is the way it is.
Not done yet: plenty. The mobile app is a companion rather than a full surface. Some integrations are first-cut. The product is used daily by the people building it, which is the only reason any of the above is specific rather than aspirational, and it is also why the rough edges are known by name.
Product sources are private; the public repository holds the CLI, the examples and the issue tracker. If something here does not match what you find, say so in the forum: that is where the rough edges get named.
Try it instead of reading about it
The fastest honest test: open it in a browser, point it at one real thing you are working on, and see whether you had to leave. That takes about ten minutes and needs nothing installed.
More of the same thinking, written down: the blog for how this gets built, integrations for what it connects to, the store for what people publish on top of it, and the forum for where things break.