chatgpt-shell: a multi-LLM comint shell for Emacs, now marked deprecated
A multi-llm Emacs shell (ChatGPT, Claude, DeepSeek, Gemini, Kagi, Ollama, Perplexity) + editing integrations
At a glance
- What is it?
- chatgpt-shell puts ChatGPT, Claude, Gemini, DeepSeek, Kagi, Ollama, OpenRouter and Perplexity behind one Emacs comint buffer with a compose workflow. The README now says the project is largely superseded by agent-shell, so the decision is less about features than about whether you are adopting a maintained tool or inheriting one.
- Who is it for?
- Adopt chatgpt-shell if you already run a comint-based Emacs workflow and want eight providers behind one buffer without leaving the editor. Do not adopt it for new work: the README states the project is largely superseded by agent-shell and that new development happens there, so anything you build on it inherits that trajectory.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 52 days ago.
- What is it written in?
- Mainly Emacs Lisp, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem chatgpt-shell solves for Emacs users
Most people talk to language models in a browser tab or a separate terminal. If your work already lives in Emacs buffers, that means constant context switching: copy a region, paste it into a web UI, copy the answer back. chatgpt-shell removes that round trip by presenting each provider as a comint shell. Comint is the same machinery behind M-x shell and M-x python-shell, so the buffer behaves like a shell you already know: prompts, input history, and the usual shell keybindings. The README describes it as "a multi-llm Emacs comint shell" and lists eight providers in one table. That single table is the pitch. Anthropic Claude, DeepSeek Chat and Reasoner, Google Gemini, Kagi Summarizer, Ollama Llama, OpenAI ChatGPT, OpenRouter, and Perplexity Llama Sonar are all reachable from the same interface. The intended user is someone who edits code or prose in Emacs and wants model access as a buffer, not as a website. It is not aimed at people who want a chat client with a graphical interface, nor at teams that need shared conversation history across machines.
How the shell, compose buffer and source blocks fit together
The architecture is a shell front end over per-provider HTTP calls, with shell-maker as the reusable layer underneath. The README lists shell-maker separately as a package for creating Emacs shells backed by local or cloud services, which tells you chatgpt-shell is one consumer of that abstraction rather than a self-contained client. Model selection is a session property, not a per-message one: M-x chatgpt-shell-swap-model changes the provider and you continue in the same flow. The compose buffer is the part the author calls his favourite and most frequently used mechanism. You select a region, invoke M-x chatgpt-shell-prompt-compose, and an editable buffer opens pre-filled with that region. You refine the prompt, submit with C-c C-c, and the buffer turns read-only and switches to single-character bindings. Those bindings are the real interface: n and p (or TAB and shift-TAB) move between source blocks, r replies, m asks for more of the same list, e requests an entire snippet when the model returned a partial one, and q buries the buffer. A transient menu on C-c C-t groups the same commands by area: shells, compose prompt, inline edit, session, history, navigation, source blocks, transcript. Source blocks being auto-selected on navigation is the detail that makes the read-only buffer usable; you are meant to grab code out of it, not read it like prose.
Getting it running: keys, providers and the Ollama exception
Installation is not spelled out in the README excerpt beyond the MELPA badges for stable.melpa.org and melpa.org, so the package is distributed through MELPA and the usual package-install path applies. Configuration is one variable per provider, and the README's setup column names them exactly: chatgpt-shell-anthropic-key, chatgpt-shell-deepseek-key, chatgpt-shell-google-key, chatgpt-shell-kagi-key, chatgpt-shell-openai-key, chatgpt-shell-openrouter-key, and chatgpt-shell-perplexity-key. Set only the ones you intend to use. Ollama is the exception: its setup column says to install Ollama, with no key variable, because it runs locally. The README also warns that with the exception of Ollama you typically have to pay the cloud services for API access and that you should check with each provider. That is a billing statement, not a technical one, and it matters: a misconfigured or looping shell is metered. Two related packages extend the same buffers into Org: ob-chatgpt-shell evaluates chatgpt-shell blocks as Org babel blocks, and ob-dall-e-shell does the same for DALL-E blocks. A third, dall-e-shell, is a standalone shell for OpenAI's DALL-E. If you want image generation inside Org, those are separate installs, not features of this package.
The deprecation notice is the first thing to read
The README opens with a warning banner, not a feature list. It states the project is now largely superseded by agent-shell, described there as far more capable and actively developed. The wording is careful: chatgpt-shell may continue to work, but new development happens in agent-shell. For a prospective adopter this changes the evaluation entirely. You are not comparing chatgpt-shell against other Emacs LLM clients on features; you are deciding whether to build habits and configuration around a package whose author has redirected effort elsewhere. The README even supplies the migration hint: to create throw-away shells as you did with M-x chatgpt-shell, use M-x agent-shell-new-temp-shell. That is a concrete mapping from the old entry point to the new one. The repository is not archived, and the last push date is recent, so the code is not frozen. But an unarchived repository with an explicit supersession notice is a different proposition from an actively developed one, and the README's own language should be taken at face value.
Where chatgpt-shell is the wrong tool
The multi-provider table is also the main limitation. Because each provider is wired in separately, the feature set is the intersection of what the package implements per provider, not the union of what each service offers. Nothing in the README describes provider-specific capabilities such as tool use, file attachments, or structured output, so you should not assume parity with a provider's own SDK or web interface. The compose buffer's single-character bindings are efficient precisely because they are modal and destructive of normal editing; the buffer becomes read-only after submission, which is the intended design but also means you cannot keep editing your prompt in place. The transient menu depends on the separate transient package, so that dependency has to be present. And if your workflow is not already shell-shaped, the comint foundation buys you nothing. Someone who wants a chat transcript they can scroll, search and share across devices will find a buffer that lives and dies with the Emacs session. The README does not describe any persistence or sync mechanism for conversations.
agent-shell is the alternative the author points to
The obvious alternative is named in the deprecation notice itself: agent-shell, by the same author. The difference in approach is not cosmetic. The README characterises agent-shell as far more capable and actively developed, and routes the throw-away shell use case to M-x agent-shell-new-temp-shell. So the split looks like this: chatgpt-shell is a comint shell you type into, with a compose buffer bolted on for careful prompting; agent-shell is where the author is putting new capability. If you are starting fresh in 2026, the README's own instruction points you at agent-shell first and treats chatgpt-shell as the legacy path. The honest reading is that chatgpt-shell remains useful for people with existing configuration and muscle memory, and that anyone without that baggage should evaluate agent-shell before writing a single chatgpt-shell-*-key variable. If you need Org babel integration specifically, note that ob-chatgpt-shell is a separate package and its relationship to agent-shell is not described in this material.
Licence, maintenance and what an upgrade actually costs
The licence is GPL-3.0, which means if you redistribute a modified version you take on the obligations that licence imposes; that is a general property of the licence and not legal advice, so read the text if you plan to ship changes. The practical maintenance question is different. There are no recent releases listed, the package is on MELPA, and the README's development note directs sponsorship to keep development and support sustainable while new work moves to agent-shell. That combination suggests the upgrade cost is not in dependency churn but in the eventual migration: your provider key variables, your keybindings around chatgpt-shell-prompt-compose, and any Org babel blocks in ob-chatgpt-shell all encode assumptions about this package. The README gives you one migration anchor, M-x agent-shell-new-temp-shell, and nothing else. Before committing, check the agent-shell README for whether the provider key variables carry over, and check the MELPA recipe for chatgpt-shell to confirm it is still being built. Those two checks tell you more about the real cost of adoption than the feature table does.
Editorial conclusion
Adopt chatgpt-shell if you already run a comint-based Emacs workflow and want eight providers behind one buffer without leaving the editor. Do not adopt it for new work: the README states the project is largely superseded by agent-shell and that new development happens there, so anything you build on it inherits that trajectory. Before installing, verify the current MELPA recipe and the agent-shell README, since the deprecation notice points at M-x agent-shell-new-temp-shell as the replacement for throw-away shells.
Community notes