AIProxy

AIProxy is a Windows-first Rust workspace for connecting coding CLIs to multiple LLM providers through shared local adapters, proxy layers, and launch flows.

The project is under heavy development. The long-term goal is broader than any single provider or client: AIProxy is intended to bridge multiple model providers, using API keys or other authentication methods, to multiple coding-focused CLIs. The first implementation milestone is intentionally narrower and currently focuses on Claude Code launched through a local Anthropic-compatible proxy backed by OpenAI credentials and the experimental Codex auth path.

Why this project exists

Coding CLIs tend to be tightly coupled to one provider, one auth model, or one launch flow. AIProxy exists to create a reusable local bridge that can:

• connect multiple coding CLIs to multiple LLM providers
• support different authentication strategies behind a shared local interface
• centralize profile, model, and launch configuration
• reduce manual per-project setup where a CLI already supports proxy or settings-based integration
• keep experimental provider or auth work isolated from supported paths

Current status

• Development stage: pre-release, actively changing, open to contributions
• Product direction: multi-provider and multi-coding-CLI
• Primary implementation today: Claude Code plus OpenAI-backed models
• Experimental implementation today: Codex or ChatGPT auth cache parsing from disk
• Primary platform: Windows-first
• Main interfaces: CLI and Tauri desktop app
• Stability: architecture is intentional, public interfaces are not yet stable

Maintainer's Note: Current Priorities

The project is completely open for contributions! As the core maintainer, my current immediate focus areas (from most to least urgent) are:

1. Proxy & Launcher Stability: Hardening the Anthropic-compatible proxy translation layer and the Claude Code launch flow so connections are rock-solid and don't drop during generation.
2. Credential & Config Safety: Ensuring API keys and experimental auth caches (Codex/ChatGPT) are resolved cleanly and stored securely via the keyring.
3. Cross-Platform Foundation: Easing the 'Windows-first' limitation to ensure seamless setups on macOS and Linux.
4. Desktop UX Polish: Refining the Tauri dashboard interfaces without violating the thin-UI boundary (keeping heavy logic in Rust).
5. Extension Groundwork: Laying the architecture for multiple LLM providers and coding CLIs.

If you are looking to contribute, feel free to tackle any of these areas, or pick up something from our Roadmap!

What is implemented today

• Create and manage AIProxy profiles
• Store and resolve OpenAI API keys
• Inspect experimental Codex auth.json cache state
• Run environment and profile diagnostics with doctor
• Start a local Anthropic-compatible proxy for Claude Code
• Launch Claude Code against that local proxy
• Install optional local Claude settings into .claude/settings.local.json
• Edit profiles and launch/session settings from the desktop app

What this repository is aiming toward

• support more than one LLM provider
• support more than one coding CLI
• keep provider-specific and client-specific integrations behind explicit boundaries
• allow API-based and non-API-based auth flows where technically and legally appropriate

That broader direction should not be read as meaning those integrations are already implemented.

Workspace layout

• apps/cli: aiproxy CLI entrypoint
• apps/desktop: React frontend for the desktop app
• apps/desktop/src-tauri: Tauri host and desktop command layer
• crates/core: shared domain models, validation, doctor types, runtime paths, helper tokens
• crates/config: config loading and persistence
• crates/credentials: keyring-backed secrets and experimental Codex auth cache parsing
• crates/backend-openai: OpenAI-backed adapter
• crates/backend-codex-experimental: isolated experimental backend boundary
• crates/proxy-anthropic: Anthropic-compatible proxy and Claude launcher
• docs/adr: architecture decision records

How the current milestone works

1. AIProxy loads a profile from config.toml.
2. The selected credential source is resolved.
3. AIProxy starts a local proxy on the profile port.
4. Claude Code is launched with temporary settings and environment variables pointing to that proxy.
5. Claude requests are translated through the local bridge to the selected backend adapter.

More detail lives in ARCHITECTURE.md.

Requirements

• Windows with Rust toolchain installed
• claude available on PATH for the current launcher-driven Claude flow
• Node.js and npm for the desktop frontend
• An OpenAI API key for the supported auth path in the current milestone

Quick start

Initialize the default config:

cargo run -p aicliproxy-cli -- init

Store an API key for the default profile:

cargo run -p aicliproxy-cli -- auth set-api-key --profile default --value <OPENAI_API_KEY>

Check the environment and profile setup:

cargo run -p aicliproxy-cli -- doctor --all-profiles

Launch Claude Code through AIProxy:

cargo run -p aicliproxy-cli -- claude launch --profile default

CLI surface today

• aiproxy init
• aiproxy doctor
• aiproxy profile add
• aiproxy profile set-models
• aiproxy profile set-alias
• aiproxy profile list
• aiproxy settings show
• aiproxy settings set-launch
• aiproxy auth set-api-key
• aiproxy auth clear-api-key
• aiproxy auth use-codex-experimental
• aiproxy auth helper-token
• aiproxy proxy start
• aiproxy claude launch
• aiproxy claude install-local
• aiproxy logs

Desktop app

The desktop app is not just a placeholder shell. It already includes panels for:

• profile editing
• doctor diagnostics
• Claude launch flow
• runtime inspection
• session settings

The desktop frontend lives in apps/desktop, and the Tauri host lives in apps/desktop/src-tauri.

Development

Rust workspace checks:

cargo fmt --all
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features

Desktop frontend:

cd apps/desktop
npm install
npm run tauri:dev

Documentation

• ARCHITECTURE.md: system shape, current milestone, and extension boundaries
• docs/adr/0001-auth-and-launcher-boundaries.md: current auth and launcher decisions
• CONTRIBUTING.md: contribution workflow and expectations
• CODE_OF_CONDUCT.md: community standards
• SECURITY.md: security reporting guidance
• SUPPORT.md: how to ask for help
• ROADMAP.md: near-term direction and milestone framing

Contributing

Contributions are welcome. The most useful contributions right now are:

• bug fixes and diagnostics improvements
• launcher and proxy hardening
• tests around config, credentials, and wire compatibility
• desktop UX improvements that do not break backend boundaries
• documentation corrections when behavior changes
• groundwork that helps future provider or coding-CLI integrations without overgeneralizing too early

Start with CONTRIBUTING.md.

Open-source expectations

• The repository is open to external contributions while still changing quickly.
• Maintainers may prefer small, reviewable pull requests over broad refactors.
• Experimental auth work must remain isolated and documented.
• Documentation updates are expected when auth, launcher behavior, shared config, or proxy wire contracts change.
• Broader multi-provider and multi-client goals should be described clearly, but documentation must still distinguish future direction from implemented behavior.

License

This repository is licensed under GPL-3.0-only. See LICENSE.