Claude Code & Codex

Coding agents are the workload Aile is shaped around: long sessions, big contexts, and models that are expensive to hold a seat for. Anything that accepts a custom base URL works.

Claude Code

Claude Code speaks the Anthropic format, so it takes the bare origin:

1export ANTHROPIC_BASE_URL="https://api.aile.sh"
2export ANTHROPIC_AUTH_TOKEN="sk-aile-..."
3
4claude

https://api.aile.sh/v1 works too: Aile serves the doubled /v1/v1/… paths as /v1/….

Every Aile model id names its provider, with one exception made for this client: a bare id from Claude Code (claude-sonnet-5) goes to the claude provider. So its /model picker and background calls work with the two variables above.

To list every Claude model Aile can serve in /model, add the line below. Each row names its provider, as in claude-sonnet-5 (Claude Code):

1export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1

To use a different provider's Claude, name it: anthropic/claude-sonnet-5, or x-aile-provider in ANTHROPIC_CUSTOM_HEADERS.

Claude Code's own default model, Claude Sonnet 5.5 (claude-sonnet-5-5), is served like the rest. It, Opus 5.5 and Fable 5.1 always think: turning thinking off, or forcing a tool choice, is rewritten to the nearest setting the model accepts rather than forwarded into a 400. See Anthropic SDK.

1x-aile-session: <your-session-id>

Codex CLI

Codex speaks the OpenAI Responses API, which Aile serves at /v1/responses. Add a provider to ~/.codex/config.toml:

1model_provider = "aile"
2
3[model_providers.aile]
4name = "aile"
5base_url = "https://api.aile.sh/v1"
6wire_api = "responses"
7experimental_bearer_token = "sk-aile-..."

Codex's own model names (gpt-6.1-sol, its current default, or gpt-5.5) work as they are: a bare id from the Codex CLI (its originator header, such as codex_cli_rs or codex_exec) goes to the codex provider, so its model picker and background calls work with the config above. A model a sharer's ChatGPT plan does not carry fails that sharer's test and is not listed for that account. Any other provider is named in the id (cc/claude-sonnet-5). Tool-heavy sessions work best on codex/ models, which Aile passes through natively.

GET /v1/models detects the Codex CLI and includes the extra field it expects, so its model picker populates without special configuration on your side. Each row also carries the window a Codex account actually gets (context_length, 872K on the GPT-6 family rather than the API's figure) and the effort levels in Codex's own labels (reasoning_efforts, Light to Ultra).

Prompt caching works across turns from any endpoint. Through /v1/chat/completions or /v1/messages, a codex/ model is sent a prompt_cache_key per conversation, as the Codex CLI sends one; your own prompt_cache_key is honoured, hashed with the serving account so it never reaches the sharer as written. /v1/responses passes yours through unchanged.

Each Codex conversation stays on the account that served it, keyed on the session-id header the Codex CLI sends with every turn, and each of its subagents on its own (by thread-id). That keeps the account's prompt cache warm, and the reasoning Codex replays from earlier turns readable: ChatGPT seals it to the account that produced it, so a turn that lands on another account (a failover, a cooldown) is refused. Aile then sends that turn once more to the same account without the reasoning it cannot read, keeping each step's readable summary, so you get an answer rather than an error. The same applies to any client replaying encrypted reasoning through /v1/responses or /v1/chat/completions. Only if that second try is refused too does the turn end with invalid_encrypted_content, the code Codex recovers on.

The codex provider sends no output cap upstream, whatever the request says. On a key's balance the usage it reports is billed, past the quote if need be, up to the model's context window; an x402 payment cannot bound that, so a codex/ request paid by x402 is a 400.

Cline, Continue, Roo and friends

All of these take an OpenAI-compatible endpoint:

If the client has no field for custom headers (many do not), pin your routing filters to the key instead: API keys → Routing on the dashboard. Provider, sharer, node and a price ceiling (a discount off list) can all live on the key. See API keys.

Choosing a model for agent work

1aile sharers --model claude-sonnet-5
2aile price claude-sonnet-5 --max-tokens 8192

Agent sessions authorise large output ceilings, and the reservation is taken against the ceiling rather than the reply. That makes max_tokens the number worth tuning; tools and thinking can raise the cap sent upstream, a route that sends no cap (codex) ignores it, and a key's balance is billed up to what went upstream. See Spend & limits.

Keeping a session on one sharer

Two levels:

1x-aile-sharer: <sharer handle>   # this seller, any of their machines; L + 16 hex, from the marketplace
2x-aile-node: <node id>       # one specific machine

Pinning a node means one machine's price and one machine's availability: if it goes offline mid-session, the request fails rather than moving. Pinning the seller is usually the better tradeoff.

Things worth knowing for long sessions

Failover happens before the first token. Once a stream commits, you are with that sharer for the rest of the response. A rearming idle timeout (10 minutes of silence) governs from there, so a long answer is never cut off for being long.

A slow first token does not drop the connection. A streaming request with no response inside 25 seconds is committed to 200 and kept alive with keepalive frames until the model starts. A failure after that arrives as the SDK's stream error event, not a status code, and the response carries x-aile-edge-hold and only the x-aile-* headers that could no longer change (not the sharer or price, except on self-hosted capacity — see Headers). An x402-paid request is never held.

context_overflow will not fail over. It comes back as x-aile-error: context_overflow with the OpenAI code context_length_exceeded, because no other sharer would fit it either. Trim the context instead of retrying.

The catalogue is live. A model that disappears between sessions means no sharer is serving it at that moment. That is not an outage.