Architecture
Providers & routing
codel00p-providers gives the harness one consistent way to call models, without tying project memory to any single vendor.
Profiles and transports
Provider support is two layers. A profiledescribes a provider's identity, aliases, API mode, credentials, and model catalog. A transport is the wire adapter for one API mode: it converts messages and tools, builds the request, and normalizes the response and usage. Sending JSON to a URL is not enough, since provider quirks are real, so each mode has its own transport.
| Provider | API mode | Credential |
|---|---|---|
| Anthropic | anthropic_messages | API key |
| OpenAI | responses, chat_completions | API key |
| Azure AI Foundry | azure_chat_completions | Key + endpoint |
| AWS Bedrock | bedrock_converse | AWS credential chain |
| Google Gemini | gemini | API key |
| OpenRouter / custom | chat_completions | Key + base URL |
Credentials
Credentials are resolved from the environment and never stored in memory. Each provider reads a standard variable, for example ANTHROPIC_API_KEY or OPENAI_API_KEY, and also accepts a namespaced form like CODEL00P_PROVIDER_OPENAI_API_KEY when you want keys scoped to codel00p alone. Explicitly injected credentials take precedence over environment ones.
Routing, policy, and cost
A resolved route carries more than a URL. It records safe audit metadata, and the layer adds policy and accounting on top:
- Fallback routing retries retryable failures across an ordered list of routes;
- Policy filters providers and models by allowlist and required capabilities, with built-in presets selectable through
--provider-policy-preset; - Cost normalizes usage and produces request-priced cost estimates with explicit pricing sources;
- Gateways are reached by overriding the endpoint with
--base-urlfor any OpenAI-compatible service.
This keeps inference configurable per project, organization, or gateway while audit and policy semantics stay consistent across every surface.