Using a chatbot on the command line (the terminal) sounds to many like unnecessary complexity. 90–95 % of AI users use the browser version. Almost everyone I talk to has no idea what the command line is, or how to open it. A browser tab is open in a moment, ChatGPT or Claude.ai load in seconds, and the input field is clear enough. Why make it complicated?
I thought that way at first too. By now I work almost exclusively through the terminal. The reasons grew out of daily work. Over the past years my work with AI became ever more extensive – structures built up that could no longer be kept track of in the browser. Not even with „projects“ or „GPTs“. I am convinced that everyone gets an unimaginable productivity boost when AI use is shifted to the command line.
Never actively worked with a command line before?
Then read the setup article first: Setting up a CLI chatbot: three paths for technical writing. There I explain the terms (command line, CLI, terminal, PowerShell, command prompt), show step by step how to open a PowerShell or the Windows Terminal under Windows, and name the prerequisites for the three most important CLI chatbot variants. This article here assumes you know how to start a command line. If not, start there.
What the browser chatbot structurally cannot do
The browser is good at answering individual requests. You type, you get an answer, you copy it out, you paste it somewhere. As long as you handle one task at a time, that works.
As soon as you want to work on several documents, the browser becomes the bottleneck. Say you have 80 XML files and want to check whether a technical term is used consistently. 80 files do not fit into one chat window. Results cannot be written automatically into an output file. The result of one analysis cannot serve directly as the input for the next.
The browser forces you into copy-paste mode. Every step is manual. Anyone who works in this mode leaves 98 % of all possibilities on the table (a felt figure). A chatbot on the command line works differently: it has direct access to your file system, can read and write files, and works in a context that extends beyond a single conversation. That knowledge can then be saved, and when you start a new „session“ the next day, your chatbot remembers where you left off – at least if you do it right.
The most important differences in practice
The first concerns file access. A chatbot on the command line can access directories, read files, and save results without you having to copy anything. Sounds like a small thing. In practice, on a terminology consistency check across 200 documents, it saves several hours of manual work.
The second is reproducibility. An analysis I once ran in the terminal I can save as a script and run again on updated data in three weeks. In the browser that is not possible. What you do there is one-off and undocumented.
The third is automation. The chatbot on the command line can be embedded into existing processes. If your documentation process already contains scripts for builds, exports, or quality checks, AI steps can be integrated into this chain. You do not have to build a new platform, you add to what is already there.
Data sovereignty: it is not the CLI that decides, but the model
Anyone in technical writing who works with sensitive product data — design parameters, not-yet-published product generations, safety-relevant information — cannot avoid the question of what happens to this data when it is transferred to a cloud service.
The clean distinction runs along two dimensions that are often mixed up in practice:
- Frontend (browser or command line): the workflow question — how you work with the model, whether scripts handle the call, whether integration into an IDE or CCMS is possible.
- Backend (cloud model or local model): the data-sovereignty question — where your inputs are processed and who sees them.
The two axes are independent of one another. ChatGPT in the browser runs in the cloud. Claude Code on the command line also runs in the cloud — via the Anthropic API. Ollama and LM Studio run entirely on your own machine — regardless of whether you address them from the command line or from a browser interface such as Open WebUI or AnythingLLM.
When data sovereignty counts, the relevant decision is therefore: cloud model or local model. Cloud providers transfer your inputs to external servers. Some offer enterprise options without training use — that is a contractual question, not a technical guarantee. Local models (Ollama, LM Studio, vLLM) process everything on your own machine. No data transfer, no external servers, no contractual fine print.
That comes at a price: local models are currently less capable than the leading cloud models. For terminology comparisons, structure checks, and simple phrasing suggestions, the quality is usually sufficient. For more complex tasks, a stronger model is needed — and then the cloud option is back on the table. Anyone who knows both decides per task instead of once and for all.
What you need to get started
Note: I work with a Windows system.
You don’t need technical prior knowledge at a developer level. Most CLI tools for chatbots are designed so that installation and first use are possible without programming skills. With Claude Code from Anthropic, the installation takes a few minutes, and the first sensible applications are within reach without ever writing a line of code.
What you really need: the willingness to accept the terminal as a working environment. For many, that is the real hurdle. Not the technology, the habit.
The entry point is worthwhile with a concrete task that you do manually and repeatedly in the browser chatbot today. Consider whether this task would use direct file access. If yes, read the companion article Setting up a CLI chatbot — three paths, which describes three concrete ways to get started.
What the switch does not solve
One expectation I want to dampen straight away. A chatbot on the command line is no universal solution. It does not replace a structured documentation base. It produces no usable output when the input data is poor. Garbage in, garbage out applies here just as it does to every other form of automation.
The quality of your documentation processes decides what AI tools can make of them. Anyone who invests today in terminology work, modularisation, and quality assurance has a better starting base tomorrow for deploying any AI tool, whether in the browser or in the terminal. What that looks like concretely in the writing department I describe in Introducing AI in technical writing.
Does the browser stay?
The chatbot on the command line does not replace the browser entirely. For a quick thought, a single question, a spontaneous phrasing idea, the browser is faster and more convenient. Here you have to bear in mind that the systems are not connected – which means: the browser knows nothing of the content in the terminal and vice versa. So you create two isolated worlds, and for that reason I strongly advise against it. If you have questions that have nothing to do with your actual work, then you can use the browser. For everything that needs repeatability, file access, or automation, the command line is, going forward, your only tool. Try it with a concrete, small task. That is enough to get a feel for where the difference lies.
Setting up a CLI workflow in the writing department together
When switching from the browser chat to the command line, there are two typical traps: first, the choice of tool, which has to fit your data situation (cloud CLI, local model, or hybrid); second, the order of the first scripts — best, three recurring tasks from everyday editorial work before the whole team is switched over. Schübeler Consulting accompanies tech-doc teams through CLI onboarding: a joint tool selection, the first scripts for your recurring tasks, a clear data-protection line for documents that leave the building.
Book your initial consultation online →
Prefer to write? info@schuebeler-consulting.de
— Johann Jörgen Schübeler, Schübeler Consulting