Arcana's proxy API sits between your agent and model providers. It routes requests, manages keys, and gives you a single endpoint regardless of which providers you use.
The proxy is the reason Arcana can offer a genuine free tier. Without it, every request would need direct provider authentication. With it, Arcana manages a pool of proxy keys that distribute load across providers, track quotas per user, and handle failover when a provider is unavailable.
Why a Proxy?
Without a proxy, every tool and integration in your workflow would need its own API key configuration. The proxy consolidates this: one endpoint, one authentication method, all providers.
Consider the alternative. You want to use OpenAI for code generation, Anthropic for long-context analysis, and Google for multimodal tasks. Without a proxy, you configure three separate API keys, three separate endpoints, and three separate error handling paths. With the proxy, you configure one endpoint and Arcana handles the routing.
This is especially valuable for the free tier. Free-tier users get proxy access with quotas. The proxy handles rate limiting, quota tracking, and provider fallback transparently. When one provider is rate-limited, the proxy can route to an alternative provider without you noticing.
BYOK (Bring Your Own Key)
If you have your own provider keys, you can use them through the proxy. The proxy does not store your keys on its servers. Keys are held in memory during the request lifecycle and discarded afterward.
# Configure BYOK (works on all platforms)
arcana config set providers.openai.apiKey "sk-..."
arcana config set providers.anthropic.apiKey "sk-ant-..."
These commands modify your config file at:
- Linux / macOS:
~/.arcana/config.json - Windows:
%USERPROFILE%\.arcana\config.json
Request Flow
- Your agent sends a request to the proxy endpoint
- The proxy resolves which provider handles the model
- Authentication is applied (proxy key or BYOK)
- The request is forwarded to the provider
- The response flows back through the proxy
The proxy adds minimal latency. On the primary domain, round-trip overhead is typically under 20ms.
Fallback Domains
The proxy operates on a primary domain with a fallback. If the primary is unreachable, requests automatically route through the fallback. This is configured at the infrastructure level and requires no action from you.
Security
The proxy uses TLS for all connections. API keys are never logged. Request bodies are not persisted. The proxy is a relay, not a storage layer.
This design has important implications:
- No key storage. BYOK keys are held in memory for the duration of a request and then discarded. They are never written to disk, never logged, and never transmitted to any service other than the target provider.
- No request logging. The proxy does not log request bodies. Your code, your prompts, and your data pass through without being recorded.
- TLS everywhere. All connections use TLS 1.3. No plaintext traffic between your agent and the proxy, or between the proxy and providers.
- Rate limiting. The proxy enforces rate limits per user, preventing runaway costs from accidental loops or misconfigured scripts.
The proxy is a convenience layer, not a security boundary. Your keys are already trusted by the providers. The proxy just routes them efficiently.