AI-Provider Router IDE：本地路由多 AI 提供商的桌面 IDE

AI-Provider Router IDE

A local desktop IDE for routing LLM requests across multiple AI providers. Providers are described by a declarative adapter manifest; an unknown API is figured out by a guided probe → identify → test wizard, or you can add one manually. A local gateway exposes an OpenAI-shaped API on 127.0.0.1 so other tools can talk to every configured provider through one endpoint.

API keys are stored in a local secrets file (mode 600), never in the database. Nothing leaves your machine except the requests you make to the providers you configure.

Status

Developed and tested on macOS (CI runs macos-14). Windows and Linux are untested — the bundler carries Windows/Linux icons, but the file-backed secret store and the gateway have only ever been exercised on macOS.

There is no downloadable release yet. A build another Mac will launch has to be Developer ID signed and notarized by Apple, which needs a paid Apple Developer Program membership; until then the release workflow attaches its artefacts to a draft. The supported path is building from source.

Getting started

Prerequisites

Quickstart

git clone https://github.com/begumporshi-alt/ai-provider-ide.git
cd ai-provider-ide
pnpm install
pnpm --filter ai-provider-router-desktop tauri dev    # full desktop app

pnpm --filter ai-provider-router-desktop dev runs the frontend alone, with no Rust shell — faster to start, but the gateway and the secret store are absent.

First run

Add a provider, add its key, enable it, then switch the gateway on under Control → Local Gateway. It listens on 127.0.0.1:8787 by default and shows the master key to paste into whichever other tool you want to route through it.

The full walkthrough — provider setup, pointing Cursor or a script at the gateway, where your data lives, and every error code — is in USER_GUIDE.md.

Run the router, headless

The desktop app is one of two ways to run the gateway. If you want the routing service without the UI — the thing other coding agents (ZCode, Claude Code, any OpenAI-compatible tool) talk to — run the daemon:

cd apps/desktop/src-tauri
cargo build --release --bin aiproviderd --no-default-features
./target/release/aiproviderd install     # copies itself to the data dir + registers a launchd service
./target/release/aiproviderd status
curl http://127.0.0.1:8800/health        # → {"status":"ok"}

The daemon serves the same routes as the in-app gateway on 127.0.0.1:8800 (or whatever port the store carries) against the same data directory — providers, keys, settings, ledger. It survives reboots and needs no UI; the desktop app, when you do open it, is simply its best-connected client.

Point a tool at it. Any OpenAI-compatible client takes:

base URL:  http://127.0.0.1:8800/v1
API key:   the master key (`aiproviderd mint` prints one), or a per-app key for each tool

curl http://127.0.0.1:8800/v1/chat/completions \
  -H "Authorization: Bearer <key>" -H "Content-Type: application/json" \
  -d '{"model":"<provider>/<model>","messages":[{"role":"user","content":"hello"}]}'

Per-app keys (one per IDE, individually revocable, with monthly spend caps) are minted on the AI Providers screen. Claude Code speaks the Anthropic dialect — the same gateway also serves /v1/messages on the same port. Run the daemon or the app's in-process gateway against a data directory, never both (same port, same SQLite store).

Build, sign and release

To bundle, sign, or cut a release, see CONTRIBUTING.md — "Building a bundle" and "Releasing". In short, ./node_modules/.bin/tauri build --bundles app from apps/desktop.

Test

pnpm typecheck                 # all workspaces
pnpm test                      # unit tests
pnpm ci:local                  # the full gate: leak scan, version sync, build, Rust, browser

pnpm ci:local needs PATH="$HOME/.cargo/bin:$PATH" or it reports a bogus "Rust (cargo missing)" failure. The step-by-step version, and what each step exists to catch, is in CONTRIBUTING.md.

Layout

apps/desktop/            Tauri shell + React UI (screens/, src-tauri/ for Rust)
packages/router-core/    routing, adapter runtime, model catalog, onboarding orchestrator
packages/adapter-spec/   the manifest grammar (zod) — the frozen contract

Inside apps/desktop/src-tauri/, the src/core/ half is deliberately Tauri-free, and a headless binary target (aiproviderd) builds from it — the gateway detached from the UI process, tracked in the dev book's headless chapter. The daemon serves the same routes as the in-app gateway (/v1/chat/completions, /health, the admin API), reads the same data directory (providers, manifests, keys, settings), and on macOS installs as a launchd service (aiproviderd install / status / uninstall; default port 8800 unless the store carries one). The desktop app runs the identical gateway in-process — so run one or the other against a data directory, not both at once (same port, same SQLite store).

The repository root holds only the audience-facing documents — README.md, USER_GUIDE.md, CONTRIBUTING.md, SECURITY.md, CHANGELOG.md and LICENSE. Everything else is in docs/ — design notes, session records, audits — with the visual diagrams in diagrams/.

Developers: start with the developer book. It owns the rules, the interfaces and the conventions, and it tracks every known doc-versus-code disagreement.

Security model

The gateway binds to 127.0.0.1 only — it is not reachable from the network. Every admin route (POST /admin/*, GET /admin/*) requires the master key (or a per-app key) in the Authorization header; the only unauthenticated route is GET /health, by design, so a client that does not yet hold a key can still discover that the service is up.

API keys are stored in the local secrets file (mode 600) and are never put in the database. The egress allowlist derives from the providers the user has configured; a request to a host that is not allowlisted is refused locally and reported as NETWORK, not forwarded.

Notes

• The local SQLite database is gitignored — a fresh clone starts empty. That is correct, not a bug.
• There is no keychain, so replacing the installed binary prompts for nothing: the vault is a file (<data_dir>/.secrets.json, mode 600) owned by your account. A 503 master key unavailable therefore means the secrets file could not be read — a local fault, not a rejected credential.
• This repository is public. Never commit a real key or token; pnpm key-leak-grep runs in CI.

Contributing

See CONTRIBUTING.md for the gate, and for the conventions this codebase follows — each one was paid for by a bug. For a vulnerability, do not open a public issue; see SECURITY.md.

Licence

Apache License 2.0 — see LICENSE.