AionRouter Client and Coding Tool Integration Guide
Connecting a client to AionRouter requires a matching API URL, key, model ID and protocol. Success means the intended feature sends a request to the correct model, a matching usage record exists and the client parses the result. Saving settings alone does not establish connectivity.
This guide covers Claude Code, Codex CLI, Cline, OpenClaw and chat tools with custom providers on macOS, Windows or Linux. Updates can change features and configuration scope. Codex guidance follows the OpenAI Docs checked for this revision, with official references also retained for other tools.
Prepare for how your client actually runs
| Usage | Check first | What not to assume |
|---|---|---|
| General chat client | Custom URL, model ID and Chat/Responses protocol | Accepting a key does not imply overriding official endpoints |
| Messages tools such as Claude Code | Messages model, credential source and tool interaction | One chat response does not verify every agent capability |
| Codex CLI | Responses protocol, model identity and local configuration source | A generic model list is not a native Codex catalog |
| Editor extension | Whether it runs locally, in WSL, a container or remotely | Local terminal variables do not configure every remote environment |
| Multiple tools or users | Separate keys and traceable records | A shared key complicates revocation and attribution |
Connect one client to one verified model before adding models or automation. Use exact model IDs, not display names, rankings or a model's self-description to infer routing.
Prepare four connection details
| Item | Where to find it | Notes |
|---|---|---|
| API root URL | Console or model API examples | Examples use https://test.aionrouter.io; use the address actually provided |
| API Key | API key management | A model API key, not website login credentials |
| Model ID | Model Marketplace or /v1/models |
The full ID available to your key |
| Request protocol | Model details and client provider settings | Match Chat, Responses and Messages separately |
Set environment variables first, using the syntax for your shell:
Terminal compatibility
Use the examples for your shell: macOS/Linux use Bash or Zsh; Windows uses PowerShell or CMD. Git Bash/WSL can use the Bash examples, but run all setup and requests in the same environment. The current API root is https://test.aionrouter.io.
Windows examples explicitly use curl.exe to avoid the curl alias in Windows PowerShell 5.1. Check curl --version or curl.exe --version; --fail-with-body requires cURL 7.76.0 or later. Microsoft: curl on Windows · cURL options
Run one shell variant only. Environment variables apply to that terminal and programs started from it. In CMD, run each line separately; at the AIONROUTER_BASE_URL prompt, paste the API root shown above, without a trailing slash. Then enter the actual key, model or voice when prompted. Do not paste Bash export, backslash continuations or heredocs into CMD or PowerShell.
macOS / Linux — Bash / Zsh
export AIONROUTER_BASE_URL='https://test.aionrouter.io'
export AIONROUTER_API_KEY='替换为控制台复制的完整密钥'
Windows — PowerShell
$env:AIONROUTER_BASE_URL = 'https://test.aionrouter.io'
$env:AIONROUTER_API_KEY = Read-Host 'AIONROUTER_API_KEY'
Windows — CMD
set "AIONROUTER_BASE_URL="
set /p "AIONROUTER_BASE_URL=AIONROUTER_BASE_URL: "
set "AIONROUTER_API_KEY="
set /p "AIONROUTER_API_KEY=AIONROUTER_API_KEY: "
Then verify the model list:
macOS / Linux — Bash / Zsh
curl --fail-with-body --silent --show-error \
"$AIONROUTER_BASE_URL/v1/models" \
-H "Authorization: Bearer $AIONROUTER_API_KEY"
Windows — PowerShell
curl.exe --fail-with-body --silent --show-error "${env:AIONROUTER_BASE_URL}/v1/models" -H "Authorization: Bearer ${env:AIONROUTER_API_KEY}"
Windows — CMD
curl.exe --fail-with-body --silent --show-error "%AIONROUTER_BASE_URL%/v1/models" -H "Authorization: Bearer %AIONROUTER_API_KEY%"
If this fails, resolve the address, authentication and access permissions first. A successful model list still requires a small request to the target endpoint to verify model and protocol compatibility.
Match Base URLs, endpoints and protocols
Should the Base URL include /v1?
| Client connection type | Typical value | Final request example |
|---|---|---|
| OpenAI Chat-compatible Base URL | https://test.aionrouter.io/v1 |
/v1/chat/completions |
| OpenAI Responses-compatible Base URL | https://test.aionrouter.io/v1 |
/v1/responses |
| Anthropic Messages root URL | https://test.aionrouter.io |
/v1/messages |
| Tool requiring a full endpoint | Full URL as required by the tool | For example, the complete /v1/chat/completions URL |
These are common URL-building conventions for the corresponding integrations. With a 404, inspect the final path. /v1/v1/messages, duplicated /chat/completions, or a missing /v1 may indicate an incorrect base URL.
Do not add or remove /v1 for every client indiscriminately, or assume every “API URL” field has the same meaning.
Inspect the final request one part at a time. The API root, versioned Base URL and full endpoint are different levels. Check where the client actually sends requests instead of repeatedly adding or removing /v1 everywhere.
Credentials and URLs must belong to the same service. A AionRouter key sent to an unchanged official endpoint goes to the wrong destination. Changing the URL while retaining an old provider's key also does not validate this platform. A small terminal request with the same model helps distinguish gateway problems from client configuration.
Connect Claude Code and check configuration scope
Claude Code: use Anthropic Messages
Point Claude Code at the gateway root and select an available model supporting Messages:
macOS / Linux — Bash / Zsh
export ANTHROPIC_BASE_URL="$AIONROUTER_BASE_URL"
export ANTHROPIC_AUTH_TOKEN="$AIONROUTER_API_KEY"
export ANTHROPIC_MODEL='替换为支持 Messages 的实际模型 ID'
claude
Windows — PowerShell
$env:ANTHROPIC_BASE_URL = $env:AIONROUTER_BASE_URL
$env:ANTHROPIC_AUTH_TOKEN = $env:AIONROUTER_API_KEY
$env:ANTHROPIC_MODEL = Read-Host 'ANTHROPIC_MODEL'
claude
Windows — CMD
set "ANTHROPIC_BASE_URL=%AIONROUTER_BASE_URL%"
set "ANTHROPIC_AUTH_TOKEN=%AIONROUTER_API_KEY%"
set "ANTHROPIC_MODEL="
set /p "ANTHROPIC_MODEL=ANTHROPIC_MODEL: "
claude
ANTHROPIC_AUTH_TOKEN uses Bearer authentication; ANTHROPIC_API_KEY uses x-api-key. Check for conflicting credential settings, then use /status in Claude Code to verify the address and credential source. Official Claude Code gateway configuration
Test in the same terminal before persisting settings. Do not put real keys in project configuration committed to a repository. CLI environment variables do not automatically configure desktop apps, editor extensions or cloud sessions; follow the instructions for each environment. Claude Code configuration scope
AionRouter supports the Messages route and both authentication methods. Full agent functionality still depends on the model, channel and client version. A successful ordinary Messages request does not verify every tool, context-management feature or extension.
Inspect active configuration before changing it. If terminal calls work but Claude Code takes another route, check for settings files, process variables or other credential sources overriding your setup. Confirm in /status as described by the official gateway guide. Do not immediately delete all saved sign-ins for troubleshooting.
CLI, editor extensions, desktop apps and cloud tasks have different configuration entry points. Editors launched from Dock or the Start menu may not inherit terminal variables. Follow the current documentation for that surface and verify requests in platform records instead of editing an unread file. Claude Code: gateway configuration and scope
Connect Codex CLI and check models and user configuration
Codex CLI: use Responses
Merge this into user-level ~/.codex/config.toml, replacing the model ID and address. Preserve existing settings; do not overwrite the entire file with this example. OpenAI Docs: Codex configuration reference
model = "YOUR_RESPONSES_MODEL_ID"
model_provider = "aionrouter"
[model_providers.aionrouter]
name = "AionRouter"
base_url = "https://test.aionrouter.io/v1"
env_key = "AIONROUTER_API_KEY"
wire_api = "responses"
requires_openai_auth = false
Codex configuration paths by environment
| Environment | Default user configuration |
|---|---|
| macOS / Linux / WSL | ~/.codex/config.toml |
| Windows PowerShell | $env:USERPROFILE\.codex\config.toml |
| Windows CMD | %USERPROFILE%\.codex\config.toml |
If CODEX_HOME is set, use config.toml under that directory. WSL uses its own Linux home directory; editing the Windows file does not automatically configure WSL. Merge the existing TOML example into the appropriate file. Install and launch each CLI in the same operating-system environment as its configuration; shell syntax does not guarantee every third-party feature is supported. OpenAI Docs: configuration locations · Claude Code: Windows and WSL
Set AIONROUTER_API_KEY in the terminal before starting, then run:
macOS / Linux / Windows
codex
env_key is the environment variable name, not the key value. The current official configuration defines custom-provider wire_api as responses. Do not follow old advice to switch it to chat on failure. Put provider settings in user-level configuration. OpenAI Docs: provider and protocol fields
The gateway provides /v1/responses, but the model and channel must support the events and tools required by the client. Investigate the selected model and response when incompatibilities occur, rather than using a nonexistent protocol value.
Check TOML hierarchy and duplicate definitions. Put top-level model and model_provider before provider tables. Do not duplicate an existing table or place top-level keys inside it. Back up the original, then merge only required fields. OpenAI Docs: gateways and configuration locations
Appearing in /v1/models does not guarantee integration with the full Codex model picker. The native catalog also needs recognized identifiers and metadata. For custom aliases with catalog, context or capability issues, check your client's catalog requirements. Do not substitute a generic list URL for a dedicated catalog or invent an endpoint the platform does not provide.
Configuration and keys may live in different environments. WSL, containers and remote CLIs use their own user directories and process environments. Inspect what the running process loads before concluding the platform rejected it. Saving Windows configuration does not automatically configure a CLI inside WSL.
Connect Cline, OpenClaw and other tools
Cline: choose OpenAI Compatible
Choose OpenAI Compatible in Cline provider settings and enter:
| Field | Value |
|---|---|
| API Provider | OpenAI Compatible |
| Base URL | https://test.aionrouter.io/v1, or the equivalent address from the console |
| API Key | Your complete AionRouter API Key |
| Model ID | An actual model supporting the corresponding Chat format and tool use |
This integration uses a custom provider URL, key and model ID. Set context size, output limits, image support and tool capabilities according to the actual model. A visible option does not prove support. Official Cline OpenAI Compatible guide
After saving, run a small task and check console request records. Passing a model-list or connection check does not validate the complete tool-use workflow.
OpenClaw: match the custom-provider protocol
OpenClaw custom providers can be configured under models.providers. Common mappings are below; check field names against your version:
| Setting | Chat model | Responses model |
|---|---|---|
baseUrl |
Service URL plus /v1 |
Service URL plus /v1 |
api |
openai-completions |
openai-responses |
apiKey |
Current key; prefer supported secret references | Current key; prefer supported secret references |
| Model catalog | Actual model ID | Actual model ID supporting Responses |
openai-completions is OpenClaw's adapter name for the corresponding Chat-compatible connection. It does not mean requests should use the legacy /v1/completions. Choose openai-responses only when the backend supports Responses. Official OpenClaw custom-provider configuration
Check which agent receives the configuration and whether an existing model catalog or credentials override it. Do not overwrite the current environment with an entire configuration file from another installation.
Cursor and other custom-provider clients
Cursor
Cursor supports bringing API keys for some providers. Connecting it to AionRouter also requires a suitable custom service URL setting in the current version. Pasting a AionRouter key into the official OpenAI key field alone does not route requests to AionRouter.
If your version offers a custom or override URL, enter the root or /v1 base URL according to that field's meaning, then select a compatible model. Without that setting, this tutorial does not constitute a verified integration.
Bring-your-own-key support does not cover all Cursor features. Tab completion, for example, still uses its built-in models. A single completion appearing or not appearing in AionRouter logs cannot validate every client setting. Official Cursor API key documentation
Cherry Studio, LobeChat and similar chat tools
For tools whose current version supports custom OpenAI-compatible providers:
- Create or select a custom provider and confirm whether it uses Chat or Responses.
- Enter the API URL, key and actual model ID as required by the fields.
- If model-list refresh is available, check the service address it reads. Otherwise, add models manually as instructed.
- Save, send a small request and check usage records.
Menu names and model discovery change by version. Clicking a button is not proof of successful integration, and automatic model import is not universal.
AionRouter desktop client entry
You can also visit the site's desktop client page for downloads. Follow the actual version's installation, login and model-configuration workflow. A download page does not prove that every model or protocol is supported by a client's settings.
Match locally entered pricing and context to the real model. Some tools require manual context windows, output limits and prices for estimates. These settings do not change platform capabilities or billing. Do not copy another model's values without evidence; estimates do not replace actual usage records.
A supplied key may not power every feature. A tool can combine custom models, built-in completion, other providers and separately charged features. Determine what actually passes through AionRouter from feature settings and usage records, not a model name shown in the main window.
Verify real requests before moving to daily work
Verify that requests really use AionRouter
Complete these checks in order:
- Make a minimal API request with the same address and key to verify the target model and endpoint.
- Send a small, recognizable request in the client and note its time and model ID.
- Match the call in consumption logs, using the request ID if necessary.
- For agent use, also validate a controlled tool-use task.
A model's answer to “which model are you?” does not independently prove routing. Other logins, fallback providers or built-in models may be active. Check the effective settings and request records together.
Verify these four levels in order:
- Basic connection: complete a minimal request with the same URL, key and model.
- Client conversation: send an identifiable short prompt and check the time, model and usage record.
- Tool loop: run a bounded task with inspectable results in a temporary directory and verify arguments and result submission.
- Real work sample: use an anonymized project excerpt or small task to check context, streaming, recovery and costs before expanding.
Migrate one client or environment at a time and keep a reversible configuration. Avoid changing URLs, credentials, protocols and every model together. Teams can share nonsensitive provider names, URLs and model IDs while assigning keys by user or purpose.
The platform records requests reaching it; a client may also have subscriptions, built-in features or service charges. Reconcile each billing party separately. One successful platform call does not cover every client fee.
Troubleshooting and common questions
Troubleshooting connections
| Symptom | Check first |
|---|---|
401 |
Key status, completeness and the credential source actually used; do not change paths blindly |
403 |
IP allowlist, model restrictions, account, group and enterprise access rules |
404 |
Duplicated URL paths and whether the client protocol matches the endpoint |
| Empty model list | Key-accessible models, group and billing settings, and client list support |
| Chat works but the agent fails | Tool use, streaming, context size and protocol extensions |
| Environment change has no effect | Whether the process inherits that terminal; config files, containers or remote settings may override it |
| No matching request record | Actual destination, network/authentication/routing failures before logging, or a different account |
429 or temporary unavailability |
Reduce concurrency, check limits and available channels; avoid infinite retries |
A 404 does not establish an invalid key. Authentication failure does not automatically require signing out of every client. Check the specific error, final URL and effective settings first.
Frequently asked questions
Can one API Key be used in several tools?
Yes, if its settings allow the models and request origins. Separate keys per tool or user make usage management and revocation easier.
Why does my configuration fail after switching models?
The new model may support different endpoints, tools or parameters. Visibility does not guarantee suitability for the same agent configuration. Recheck the protocol and capabilities.
Will using a AionRouter key also consume the client's included quota?
That depends on the client, feature, plan and routing settings. The platform records only requests actually sent to AionRouter and cannot guarantee that third-party clients incur no other charges.
Can client settings turn a Chat model into a complete Responses or Messages model?
Names and protocol selectors alone cannot guarantee that. The gateway, channel and upstream model must support the actual interactions, especially streaming events and tool calls.
If the terminal works but the editor fails, check where it runs. Record configuration paths and environment sources for local editors, Remote SSH, development containers and WSL separately. Restart the process that actually sends model requests, not an unrelated terminal.
Stop expanding call chains when an agent keeps retrying. Save errors and request details, return to a verified small request, and check protocol, tools and model. More retries, larger context and new tasks do not substitute for diagnosis.