AIO Coding Hub puts one local gateway in front of Claude Code, Codex and Gemini CLI

A local gateway, deliberately not a service

The positioning is stated early and it is the constraint that shapes everything else. The project is a single machine desktop tool plus a local gateway. The gateway only listens on 127.0.0.1, all data is kept on the machine, and there is no public deployment, no remote access and no multi tenancy. The point of the tool is to give Claude Code, Codex and Gemini CLI one entry point, so each of those clients points at the local gateway instead of at its own provider configuration, and the gateway decides which upstream actually answers. The FAQ is direct about the data question too. When asked whether API keys and request data are uploaded, the answer is that they are not, because the gateway only listens on the loopback address. The implementation is a Tauri 2 application, with the Rust side in src-tauri and the interface in src/ built by Vite with Tailwind, and the homepage for the product is helpaio.com.

Routing, failover and the circuit breaker are the core

The first problem the tool lists is that every command line tool needs its own API configuration, and the second is that requests fail when an upstream is unstable. The gateway answers both with a single entry point and automatic failover. Providers are ordered by priority, and when one fails the gateway trips a circuit breaker with a configurable threshold and recovery time before moving to the next provider, with sticky session keeping a conversation attached to the provider that started it. On top of that sits the ordered template idea, which lets you define several provider combinations and activate one per CLI, with drag and drop ordering inside a template, an independent enabled switch per provider, and the change taking effect immediately. The home page exposes a proxy switch per CLI, so you can start and stop the interception for one tool without touching the others, and there is a custom model name mapping plus automatic repair of SSE and JSON responses. For anyone running the same tool against two different providers, the per CLI switch and the templates are the parts that remove the manual editing.

Usage accounting, model validation and shared session history

The third problem the README lists is not knowing how many tokens were used and what they cost, and the observability section answers it in detail. Token usage is counted along three dimensions, by CLI, by provider and by model, with cost estimation and automatic sync of model prices. Requests are traced, with a real time console log, and the home page shows a heatmap of requests by time of day, a cache hit rate chart drawn per provider with a warning line at 60 percent, and an availability view drawn as a provider timeline dot matrix that refreshes every 15 seconds. None of that is exotic, and all of it is the kind of thing that otherwise requires a proxy service and a bill. Model validation is the other half of the observability story. It provides multi dimension validation templates, the examples given being token truncation and extended thinking, together with cross provider signature validation, and it supports batch validation with a history, so you can check that a provider really is the model it claims to be.

Workspaces isolate prompts, MCP servers and skills per project

The fourth problem listed is that different projects need different prompts and MCP configuration, and the answer is workspace isolation. Prompts, MCP and Skill configuration are kept per project, and the README lists workspace comparison, cloning, switching and rollback, with configuration synchronised automatically to each command line tool. Cloning and rollback are the two capabilities worth pausing on, because they are what make a workspace system usable in practice. A clone lets you take a working configuration and adjust it without disturbing the original, and a rollback means a change that broke your setup can be undone rather than reconstructed from memory. The Skill market builds on the same structure, since it discovers and installs Skills from Git repositories, and skills can be managed, filtered, sorted and then associated with workspaces in bulk. The CLI management section covers the practical side of running three tools at once: Claude Code settings can be edited directly, the Codex config.toml is opened in a code editor, environment variable conflicts are detected, and local session history can be browsed by project, then session, then message.

A plugin host, a bundled privacy filter, and a documented migration path

The plugin system is where the project has made a clear architectural choice. There is one official built-in plugin, the Privacy Filter, and community plugins run on an Extension Host, which can provide commands, provider extension values, gateway hooks, a protocol bridge skeleton and a user interface rendered by the host. Plugins have permissions, a configuration schema and an audit log, and can be enabled, disabled and uninstalled. There is an SDK and scaffolding tool, the @aio-coding-hub/plugin-sdk package and create-aio-plugin. The README also says something worth heeding for anyone arriving from an earlier version. Community plugins are to use the Extension Host, and the old prerelease rules, WASM and process runtime are treated only as unsupported migration history. That is a project telling you the old extension model is gone, which is why the plugin development manual at docs/plugins/README.md is the place plugin authors should start.

Installing the packages and confirming the gateway is up

The release matrix is small and explicit. Windows x64 ships as an .msi or a portable zip, macOS Intel and Apple Silicon ship as a zip for each chip, and Linux x64 ships as a .deb, an .AppImage or a wayland flavour of it. The matrix covers only those four targets, and the mac:universal and win:arm64 builds are kept as local build commands that do not enter the release artifacts or the update manifest. On macOS the recommended route is Homebrew:

brew tap dyndynjyxa/aio-coding-hub
brew install --cask aio-coding-hub

and later upgrades are a brew update followed by a brew upgrade of the cask. The macOS package is not signed with an Apple developer certificate and is not notarised, so Gatekeeper blocks the first launch. The README gives three ways through it. The recommended one is a single command that removes the quarantine attribute from the app bundle, sudo xattr -cr applied to the AIO Coding Hub.app path, and the alternative is an ad hoc signature with sudo codesign, which replaces the invalid signature and survives system upgrades. On Linux, Arch users install the binary package from the AUR with paru or yay, and there is a documented Wayland failure mode, a white screen or a crash on startup caused by an EGL conflict, which the application works around by injecting an environment variable to disable compositing mode. If that is not enough, the release includes a wayland AppImage built against the system libraries, and a script in the repository can repack an existing AppImage the same way. Building from source needs Node.js 18 or newer, pnpm, and Rust 1.90 or newer, plus platform toolchains, and on Debian or Ubuntu the webkit and indicator development packages:

sudo apt-get update
sudo apt-get install -y libasound2-dev libwebkit2gtk-4.1-dev libappindicator3-dev librsvg2-dev patchelf

The quick start after that is four steps. Add a provider, which can be an official API, a self hosted proxy or a company gateway, from the providers page. Turn on the proxy switch for the target CLI on the home page, so requests are forwarded through the local gateway. Then use the command line tool as usual in your terminal. Finally, look at the console or the usage page for traces, token counts and cost. The gateway listens on 127.0.0.1 on port 37123 by default, and the health endpoint is the quickest confirmation that it is running:

curl http://127.0.0.1:37123/health

A status of ok means the gateway is up.

A 0.60 release line that moves every few days

The release history says the project ships often. Version 0.60.21 was published on 2026-10-10, 0.60.22 on 2026-10-12 and 0.60.23 on 2026-10-17, and the last push was on 2026-10-17, with the package manifest at the same 0.60.23 and pnpm pinned at 12.9.1. The repository carries a release-please configuration and manifest, so the version bumps and the changelog are generated rather than typed, and the scripts directory is full of project specific checks that run in the package scripts: support matrix checks, a homebrew cask check, gateway error code checks, generated binding checks, plugin API contract checks, plugin system documentation checks, a check that forbids an instant now substitution, and a check for release pull request changelog entries. The licence is MIT. The practical consequence of that cadence is that you should pin a version rather than track the branch, and read the changelog between two versions, because a feature and a breaking change can both arrive inside a week.

The alternative is three separate configurations and no shared accounting

The alternative to this tool is the setup it replaces. Point each command line client at its own provider, keep the API keys in each tool's own settings, and change provider by editing three files. The difference in approach is where the state lives. With separate configurations there is no single place that knows which provider answered which request, so failover is something you handle by hand, token counts have to be collected per tool and per provider, and the notion of a workspace does not exist because each tool has its own prompt and MCP files. A single local gateway inverts that, at the cost of a hop in the request path and a new failure surface, since if the gateway is not running none of the three tools can reach a provider at all. For one tool and one provider, the manual arrangement is simpler and has fewer moving parts, and the gateway earns its place only when the number of tools, providers or projects grows.

Editorial conclusion

Adopt AIO Coding Hub if you run more than one of the supported AI command line tools on one workstation and want a single place to switch providers, watch token spend and keep per project configuration, since that is exactly what the local gateway is for. Do not adopt it for a shared or remote setup, because the gateway only listens on the loopback address and the project rules out public deployment, remote access and multi tenancy. Before you install, confirm the platform is in the supported release matrix, and on macOS expect to have to clear the quarantine attribute yourself because the package is not signed and not notarised.

Frequently asked questions

Official sources

1. dyndynjyxa/aio-coding-hub on GitHub
2. License: MIT
3. Project website
4. README
5. Releases