HacxGPT-CLI: a small Python wrapper whose real product is the provider account

A wrapper, stated plainly by its own documentation

The most useful sentence in this repository is the one where the documentation stops describing what the tool is and starts describing what it is not. The project is billed as an open source command line interface for unrestricted AI, and then immediately lists what that does not mean: the code is not a custom model, it is not a paid service, and it does not collect your data. That framing is unusually candid for a project in this category, and it sets up everything else.

What the package actually does is sit between a terminal and someone else's API. Requests go directly from your machine to OpenRouter, Groq, or the HacxGPT API. There is no intermediary server in the path. The three headline features in the feature list are all variations on the same idea: multi provider support, an unrestricted framework built from system prompts, and cross platform behaviour that the docs claim is tested on Kali Linux, Ubuntu, Windows, macOS, and Termux.

The language is Python, the licence field resolves to NOASSERTION rather than a recognised licence identifier, and the last commit recorded in the project metadata is 2026-06-16. The repository has 1109 stars and 242 forks, which puts it in the range where the code is small enough to read in a sitting. That is the main argument for caring about it.

Eight dependencies, and one that the packaging forgot

The dependency surface is small enough to read in one screen, and it is worth reading because the whole point of the rewrite was to shrink it. Version 2.1.1 dropped the `openai` and `litellm` packages in favour of a standalone engine called `api.py`, described in the changelog as a high performance local engine with zero external API SDK dependencies.

Those two removals are the substantive engineering claim. Both of those packages are convenient and both abstract away the HTTP details of a chat completion request, and replacing them with hand written code is the kind of decision that pays off when you want request shaping that an SDK makes awkward. It also means every provider quirk is now this project's problem.

The requirements file lists the runtime surface directly:

rich>=14.3.0
python-dotenv>=1.2.0
pwinput>=1.0.0
pyperclip>=1.8.0
colorama>=0.4.6
prompt_toolkit>=3.0.0
requests>=2.31.0
cryptography>=42.0.0

The stack splits cleanly. `rich` and `prompt_toolkit` are the interface layer, which is what gives the tool its panel based rendering and the dedicated reasoning view for `<think>` blocks. `requests` is the only network dependency, which is consistent with the hand rolled engine story. `pwinput` handles hidden password entry, and `cryptography` is there for the machine bound key encryption the 2.1.1 notes describe.

One detail worth flagging: `cryptography` appears in `requirements.txt` but not in the `install_requires` list inside `setup.py`. The packaging metadata and the requirements file disagree about what a clean install pulls in, which means a `pip install` of the published package may not behave the same as a development install from a clone.

Configuration moved to the home directory in 2.1.1

The 2.1.1 notes are the most useful part of the documentation because they describe changes rather than aspirations. Three of them concern state management.

Configuration now lives in `~/.hacx` rather than inside the project directory. The stated reason is persistence across updates, and that is a real problem this solves: a package that writes state next to its own source loses it on every upgrade from a fresh clone, and putting the directory in the home folder is the conventional fix.

API keys are encrypted against a machine specific hardware identifier, and the notes describe this as locking keys to your device. Whether that stops an attacker who already has code execution on your machine is debatable, since a hardware bound key table sitting in the home directory can be read and replayed on that same machine. What it does reliably stop is copying the config directory to a second machine and reusing it there.

Session persistence arrived alongside it, through slash commands: `/save`, `/load`, and `/sessions`. There is also an `/update` command and a set of update scripts, so the tool can replace itself from inside a chat session. Combined with a self contained `version.json` at the repository root and an automated release pipeline that watches it, this is a project that treats its own version number as a control surface.

The comparison table that explains the business

The documentation includes a table contrasting the free CLI with the HacxGPT production API, and reading it tells you more about the project than the feature list does.

The technology row says the free tool is an interface to public APIs with jailbreak prompts, while the production offering is custom trained models optimized for coding. The approach row is blunter: prompts applied to existing models versus models built without the need for prompts. The infrastructure row moves from you connecting to public APIs to dedicated GPU infrastructure, and the cost row moves from free with your own keys to a paid subscription.

So the free client is a funnel. That is not an accusation, it is just what the table describes, and the open sourcing is genuine in the sense that the code is there to read. But a reader should be clear about what they are getting: the free path is a prompt strategy plus a transport layer, and the paid path is a different product with different training.

The project is direct about the free side being adequate for experimentation, learning, and general use, and about the production side being aimed at large codebases and production coding workflows. Context window on the free path is listed as varying by provider between 4k and 128k, which is a fair description of what happens when you route to OpenRouter.

Releases that say almost nothing

Three releases appear in the project metadata. v2.1.3 was published 2026-06-12, v2.1.2 on 2026-02-28, and v2.1.1 also on 2026-02-28, minutes apart.

The 2.1.1 notes are the only ones with content worth quoting, covering session persistence, machine bound key encryption, and repository migration. The 2.1.2 notes say internal bug fixes and an improved automated release system. The 2.1.3 notes say internal bug fixes. All three carry the same automated release footer, triggered by a `version.json` update, which explains the burst of two releases on the same afternoon.

There is a version inconsistency worth noting. The `setup.py` file declares `version="2.1.0"` while the badge in the documentation reads 2.1.0 and the changelog section is headed NEW IN V2.1.1, yet the release tags have moved to 2.1.3. If the packaging metadata is what pip sees, then a fresh install from the package index may not match the newest tag. Anyone tracking this project should read `version.json` rather than trusting the badge.

The repository layout itself is compact: `hacxgpt/` for the package, `scripts/` for the update tooling, `img/` for assets, plus `MANIFEST.in`, `SECURITY.md`, `CONTRIBUTING.md`, and `requirements.txt`. The package data declaration names `providers.json` and a `prompts/` directory of markdown files, which tells you where the provider catalogue and the prompt library actually live on disk.

Who should install this

This tool makes sense in two situations, and they are quite different.

The first is learning. If you want to see how a terminal chat client handles provider routing, hardware bound credential storage, session files, and a prompt library loaded from markdown, this is a compact and readable example. Eight dependencies and a self contained package directory make it a realistic size of project to actually finish reading. The `/save`, `/load`, `/sessions`, and `/update` commands are implemented in a way you can trace.

The second is having a provider key and preferring a terminal to a web interface, particularly on Termux where a browser tab is awkward. The prompt layer is the differentiator, and if you disagree with it you can edit the markdown files rather than fighting a GUI.

Where it is the wrong choice is anywhere the promise of unrestricted output is doing real work in your decision. Removing or reducing refusal behaviour in a system prompt is not the same as a model that will answer a particular question, and no amount of prompt engineering makes a hosted model reliably produce output its provider has trained it to decline. If your work depends on a specific capability being available every time, that belongs in a self hosted model you control, not a provider account plus a wrapper.

The honest summary is that this is a thin, readable transport layer with a commercial agenda attached, and both of those things are fine. Just do not mistake the wrapper for the model.

Editorial conclusion

HacxGPT-CLI is a reasonable thing to read if you want to see how a multi provider terminal client is put together without an SDK in the middle, since `api.py` replacing `litellm` is the genuinely instructive decision in version 2.1.1. It is not a substitute for a model. Once the key is entered, the interesting behaviour lives in the prompts under `hacxgpt/prompts/` and the upstream provider does the rest, which means output quality tracks your OpenRouter or Groq account rather than this code. Start at `requirements.txt` to see the actual surface, then read `providers.json` to know which backends the release expects, and treat every capability claim in the feature list as a prompt strategy rather than a guarantee.

Frequently asked questions

Official sources

1. HacxGPT-Official/HacxGPT-CLI on GitHub
2. Issues
3. Project website
4. README
5. Releases