AQBot: A Local-First Tauri Desktop Client That Bundles Chat, ACP Agents, MCP Tools and an OpenAI-Compatible Gateway

What AQBot Replaces, and for Whom

AQBot is aimed at people who already juggle several AI surfaces at once: a chat app for general conversation, a terminal for a coding agent, a separate tool for prompt libraries, and a proxy such as LiteLLM or one-api to expose models to CLI clients. The README describes the project as a local-first desktop AI workbench that unifies multi-provider chat, ACP Agent, knowledge base, MCP tools and an API gateway, while keeping application data and user files on the local machine. That last clause is the actual pitch. Application state lives in ~/.aqbot/ and user files in ~/Documents/aqbot/, and the README states that API keys are protected with AES-256 under a local master key. For an engineer who is uncomfortable pasting provider keys into a hosted web UI, that placement is the reason to care. The target user is not a team deploying a shared inference platform. It is an individual developer or a small group running a desktop client on macOS, Windows or Linux, who wants the gateway and the agent in the same window as the chat.

Two Agent Paths, and Why the Distinction Matters

The most consequential design decision in AQBot is that it ships two separate agent mechanisms rather than one. The first is a chat-embedded Agent mode. You switch an ordinary conversation into Agent mode, and the model uses the provider API you already configured to read and edit files, execute commands and analyze code inside a working directory. The README is explicit about the boundary here: the directory is only the starting CWD of the process, not a filesystem sandbox. That sentence should govern how you deploy it. The second path is the ACP Agent workbench, which speaks the Agent Client Protocol and connects to external agent processes such as Codex, Claude Agent, Gemini CLI, Cline, OpenCode or Grok Build, pulled from an ACP Registry or configured manually with a custom command, arguments, environment variables and icon. Threads are organized per project, the last session state is restored automatically, and you can also start a conversation without selecting a project, in which case AQBot uses an isolated working directory. The practical difference: the chat Agent inherits your provider keys and whatever permissions the host process has, while the ACP workbench delegates execution to a separate program you chose and can stop, reorder and disable independently.

The Gateway Is the Part Most Desktop Clients Skip

AQBot exposes a local gateway from the desktop application, serving OpenAI Chat Completions, OpenAI Responses, Claude native and Gemini native interfaces. Access and observation are handled locally: gateway keys, SSL/TLS certificates, request logs and usage statistics are all managed inside the app. Client templates are provided for Claude Code, Codex CLI, OpenCode, Gemini CLI and custom clients. This is the feature that changes what the tool is. A desktop chat client normally terminates at the UI. AQBot instead turns the configured providers into a locally reachable endpoint, so a CLI coding tool can point at AQBot rather than holding its own credentials. The README does not specify the default listening port, the bind address, or whether the gateway binds to loopback only by default, so treat that as something to confirm in the running application rather than something documented here. If you are evaluating AQBot purely as a chat UI, you are evaluating the smaller half of it.

Getting It Running: Download, Permissions, and the macOS Gate

Installation is a release download. The README's Quick Start says to go to the Releases page and download the package for your platform. Platform coverage is stated as macOS on Apple Silicon arm64 and Intel x86_64, Windows 10/11 on x86_64 and arm64, and Linux on x86_64 and arm64 with AppImage, deb and rpm packages. There is no package manager command, no Homebrew formula, no npm install and no build-from-source instruction in the supplied material. The one installation step that is documented in detail is the macOS Gatekeeper path, and it is worth reading before you assume the download is broken. AQBot uses a self-signed code signing certificate rather than an Apple Developer ID certificate, so macOS may report that AQBot is damaged or that the developer cannot be verified. The README's fix is narrow: Control-click AQBot.app in Finder, choose Open, then Open again. If that fails, go to System Settings, Privacy and Security, find AQBot in the security section and click Open Anyway, then launch it again. The README also notes that Gatekeeper approval and accessibility permission are two separate settings, and that the selection toolbar requires enabling AQBot under Privacy and Security, Accessibility.

Configuration Surfaces: Providers, Skills Directories and Storage Paths

Provider setup supports custom Base URL, API Path, request headers and proxy rules, which means any OpenAI-compatible endpoint can be added rather than only the named ones. The README also describes a provider quick-import flow using aqbot:// provider links and CC Switch configuration import, with the user confirming before provider data is brought in. Model management covers syncing a remote model list, grouping, latency testing, capability tags, context length, sampling defaults, reasoning levels and per-model extra_body. Skills are file-system based and multi-source: AQBot manages skill directories for itself and for other tools, listing ~/.aqbot/skills, ~/.codex/skills, ~/.claude/skills and ~/.agents/skills, with enable/disable, group collapse, batch toggling and installation from an owner/repo string or a GitHub URL into a chosen target. Tools run over MCP with stdio, SSE or StreamableHTTP transports, and built-in MCP tools such as @aqbot/fetch and file search are available without installing a separate server. There is a configurable maximum loop count for MCP tool calls. Backups go to a local directory, WebDAV, or S3-compatible storage. Third-party import covers ChatGPT official exports, Cherry Studio backups and Kelivo backups, with preview statistics, warnings and duplicate handling, and the Cherry Studio and Kelivo paths can optionally migrate associated providers, API keys and file attachments.

Where AQBot Is the Wrong Tool

The clearest limitation is stated by the project itself. In chat Agent mode, the working directory is the process's starting CWD and not a filesystem sandbox. A permission model with per-request asking, auto-accept-edits and full-access modes gives you a confirmation layer, and the app shows tool calls and approval prompts live and records token and cost per task, but those are approval gates rather than containment. If your requirement is that an agent cannot touch anything outside a designated tree even when it tries, this mode does not provide that, and the README does not claim it does. The ACP workbench shifts the question rather than answering it, because containment then depends on the external agent process you configured. A second limitation is release cadence. The supplied release list shows v0.0.158, v0.0.157 and v0.0.156 published on 2026-09-08, 2026-09-06 and 2026-09-05. A version number still at 0.0.x with builds landing every one to three days means interfaces and stored data can move quickly, and the README does mention streaming render stability fixes arriving in recent versions. Budget for that. A third: the README does not document a CLI, a headless mode, or a way to run the gateway without the desktop application, so server-side or CI use is outside what the material describes.

How It Differs From Cherry Studio

Cherry Studio is the most direct comparison because AQBot imports its backups, and because both are desktop multi-provider chat clients. The difference in approach is what each does with the provider connections after you configure them. Cherry Studio's backup format is treated by AQBot as an import source, with optional migration of providers, API keys and file attachments, which suggests the two overlap heavily on the chat side. AQBot adds two things on top of that overlap. First, the local gateway that re-exposes OpenAI Chat Completions, OpenAI Responses, Claude native and Gemini native endpoints with its own keys, certificates, request logs and usage statistics, plus configuration templates for Claude Code, Codex CLI, OpenCode and Gemini CLI. Second, the ACP workbench with a registry and custom agent commands, which is a different model from a built-in agent loop because execution happens in a separate process you select. If you only need chat, roles and a prompt library, the import path means the migration cost between them is low, and the choice comes down to whether you want the gateway and ACP layer at all. If you do want them, that is the reason to pick AQBot.

Licence, Maintenance and What to Check First

AQBot is licensed AGPL-3.0. That is a network copyleft licence, and it is worth understanding before you build anything around the gateway. If you modify AQBot and let users interact with it over a network, the licence's source-availability condition is generally understood to apply to your modified version. This is not legal advice; if you plan to redistribute a modified build or expose it as a service, get your own reading of the licence text in the repository's LICENSE file. On maintenance, the material shows a project that is actively shipping, with three releases in four days in early September 2026 and a last push timestamp matching the most recent release. What it does not show is a stable interface commitment, a long-term support branch, or a documented migration path for the ~/.aqbot/ state directory across versions. The backup feature covering local directories, WebDAV and S3-compatible storage is the mitigation available to you today, and it is worth configuring before you accumulate conversations, knowledge base embeddings and gateway keys you would rather not rebuild. The first thing to verify after install is that the gateway's interface list and client templates match the CLI tools you actually run, since that is the feature that justifies AQBot over a plain chat client.

Editorial conclusion

Adopt AQBot if you want a single desktop process that talks to OpenAI, Claude, Gemini, DeepSeek and Qwen endpoints, runs ACP coding agents in a separate workbench, and re-exposes everything as a local OpenAI, Claude or Gemini compatible endpoint for CLI clients. Do not adopt it if you need a hard filesystem sandbox around agent file edits, or if AGPL-3.0 obligations conflict with how you plan to distribute the software. Before installing, verify three things: which release asset matches your platform and architecture in the Releases page, whether your macOS build triggers the self-signed certificate warning described in the FAQ, and whether your ACP agent of choice appears in the ACP Registry or must be added as a custom command with its own arguments and environment variables.

Official sources

1. AQBot-Desktop/AQBot on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases