tgpt: a terminal AI chatbot with no API key required

What tgpt replaces, and who it is aimed at

The pitch in the README is short: a cross-platform command-line interface that lets you use AI in your terminal. That framing matters, because it tells you what tgpt is not. It is not a local inference runtime and it is not a library you embed in your own code. It is a client. You type a prompt, tgpt talks to a hosted provider, and the answer comes back as text in your shell.

The audience follows from that. People who already live in a terminal and want a quick model query without opening a browser tab are the obvious fit. The README's install matrix is telling: an install script for GNU/Linux and macOS, pacman for Arch, Homebrew, FreeBSD ports and packages, a PowerShell script for Windows, Scoop, Chocolatey, and go install. That is a distribution surface aimed at individual developers, not at platform teams rolling out an internal service. There is no server component, no config schema for a fleet, and no mention of a hosted control plane.

The name is also worth clearing up, since search traffic around it is confused. tgpt is the name of this CLI project by aandrew-me. It is not a model, a vendor, or a standard.

How tgpt talks to providers without your API key

The mechanism visible from the repository is a Go client that speaks to multiple hosted providers, with the provider layer abstracted behind the CLI. The README links to a separate providers document rather than listing them inline, which is the right call for a project whose provider set changes, but it also means the README alone cannot tell you which providers exist today.

What the dependency list does tell you is how the transport is built. The module requires github.com/bogdanfinn/tls-client and github.com/bogdanfinn/fhttp rather than net/http alone. That is a client that presents a browser-like TLS fingerprint, which is a common technique for talking to endpoints that are not published as stable public APIs. It is also the clearest signal of the project's central trade-off: tgpt works without an API key because it is talking to providers in a way those providers did not necessarily design for. That is the reason the tool exists, and it is also the reason it can break without a version bump.

The rest of the dependency set is ordinary for a modern Go TUI. charm.land/bubbletea/v2 and charm.land/bubbles/v2 handle the interactive mode, github.com/JohannesKaufmann/html-to-markdown/v2 converts HTML responses into terminal-friendly Markdown, and github.com/mark3labs/mcp-go indicates Model Context Protocol support. github.com/atotto/clipboard is there for copying output. Nothing here is exotic, and the go.mod declares go 1.25.5, so building from source needs a recent toolchain.

Installing tgpt and sending a first prompt

The README's primary path for GNU/Linux and macOS is a shell script that downloads a binary. The default location is /usr/local/bin, and the README notes you can change it, provided the location is on your PATH.

curl -sSL https://raw.githubusercontent.com/aandrew-me/tgpt/main/install | bash -s /usr/local/bin

If you are on Arch Linux, the README gives pacman instead, and Homebrew covers macOS and Linuxbrew users.

pacman -S tgpt

brew install tgpt

On Windows, the README offers a PowerShell installer, plus Scoop and Chocolatey. The PowerShell form is a remote script piped into iex, which is the same trust decision as the curl pipe above.

irm https://raw.githubusercontent.com/aandrew-me/tgpt/refs/heads/main/install-win.ps1 | iex

If you prefer to build from source, go install works and the README points you at the Go documentation for adding the install directory to your shell path.

go install github.com/aandrew-me/tgpt/v2@latest

Once the binary is on your PATH, running tgpt with a prompt is the first real use. The README does not print a canonical example prompt in the excerpt available, so the honest statement is that usage details live in md/usage.md rather than in the README itself. Read that file before you assume a flag exists. If you are behind a proxy, the README documents two mechanisms: an http_proxy or HTTP_PROXY environment variable accepting http://ip:port, http://user:pass@ip:port, socks5://ip:port or socks5://user:pass@ip:port, or a proxy.txt file read from the current directory or from ~/.config/tgpt/proxy.txt.

http://127.0.0.1:8080

Updating tgpt, and the rollback the README never describes

Self-update is a single flag for script installs.

tgpt -u

The README warns that on GNU/Linux and macOS this may require admin privileges depending on where the binary lives. If you installed through a package manager, the README is explicit that you should use that manager instead: brew upgrade tgpt, pacman -Syu tgpt, scoop update tgpt, choco upgrade tgpt, or go install github.com/aandrew-me/tgpt/v2@latest. Mixing the two paths is how you end up with two binaries and a confusing PATH.

Here is the gap. The README documents updating and uninstalling, but it does not document rollback. There is no pinned-version install command, no documented way to fetch v2.13.0 after v2.14.0 lands, and no release-channel concept. The install script takes a destination directory, not a version. For a tool whose provider integrations can break between releases, that is a real operational weakness, and it is the kind of thing a team adopting tgpt at scale would need to solve itself by vendoring a specific release binary from the releases page.

Uninstalling is documented, and it is blunt: sudo rm $(which tgpt). The README notes the config directory is usually ~/.config/tgpt on GNU/Linux and Library/Application Support/tgpt on macOS, so removing the binary does not remove your proxy configuration.

Where tgpt is the wrong tool

The clearest failure mode is the one the architecture implies. Because tgpt reaches hosted providers without your own credentials, it is dependent on those providers continuing to answer requests from a client that presents a browser-like TLS fingerprint. When a provider changes its endpoint, its headers, or its rate limiting, tgpt can stop working for that provider until a new release ships. You cannot fix that with configuration, because there is nothing in the README describing a provider endpoint you can point elsewhere.

That also rules out the offline case. The related searches around this project include offline AI models, and the repository gives no indication that tgpt runs one. The providers document is about hosted services. If your requirement is that prompts never leave the machine, tgpt is the wrong layer entirely, and no flag changes that.

The third case is anything with a compliance boundary. There is no documented data-retention story, no way to select a specific provider for a specific request that the README describes, and no audit log. For a personal terminal assistant that is fine. For regulated data it is disqualifying.

tgpt against a local llama.cpp setup

The natural alternative for the same terminal workflow is a local runtime such as llama.cpp, or a wrapper around a locally served model. The difference in approach is not cosmetic. llama.cpp loads a model file from your disk and runs inference on your own CPU or GPU. Nothing leaves the machine, and there is no third-party endpoint that can change under you.

The cost is the mirror image. You need a model file, enough RAM or VRAM for it, and a machine that can produce tokens at a usable rate. You also own the model choice and the quantization trade-off. tgpt asks for none of that: the install script is a few seconds and the first prompt works on a laptop with no GPU. What you give up is control over which model answers, where your prompt goes, and whether the service is up tomorrow.

A second alternative is simply calling a provider's own API from a shell script with an API key. That gives you a documented interface, a stable contract, and per-request provider selection. It also means managing a key, which is precisely the friction tgpt removes. The choice is between a stable contract you administer and a zero-setup client you do not.

Licence, maintenance and what a fork would cost you

tgpt is GPL-3.0. For individual use that changes nothing. For anyone embedding tgpt in a distributed product, the copyleft terms apply to the combined work, and that is a decision for your own legal review rather than something this article can settle. Note also that the licence covers the tgpt code, not the upstream AI services it calls, which have their own terms you are accepting by using them.

The repository is not archived, and the last push was on 2026-09-14. Releases have been frequent: v2.12.0 on 2026-07-26, v2.13.0 on 2026-08-09, and v2.14.0 on 2026-08-30. That cadence is consistent with a project that has to keep up with provider changes, which is exactly the maintenance burden a fork inherits. If you fork tgpt to pin a provider behaviour, you are signing up to track those changes yourself.

Upgrade cost for a normal user is low, because the update path is one command or your package manager. The cost that is not low is the surprise factor: a release can change which providers work, and the README does not describe a rollback. Budget for keeping the previous binary around.

Editorial conclusion

Adopt tgpt if you want a terminal chatbot that installs from a single script or package manager and does not ask for your own API key, and if you are comfortable depending on third-party hosted providers. Skip it if you need a documented rollback path, an offline model, or a project whose provider list you can pin yourself. Before adopting, read md/providers.md and confirm which providers are currently reachable from your network, then run tgpt -u after installation to see what the self-update path does in your environment.

Frequently asked questions

Official sources

1. aandrew-me/tgpt on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases