Get the weekly radar
One short email with the freshest products, every week.
A self-hosted Python proxy connecting Atuin's AI endpoint to OpenAI-compatible backends.
Grounded in available product and source data
Atuin AI Proxy is a Python 3 tool that stands in for the Atuin Hub AI endpoint, taking the requests Atuin normally sends to that hub and forwarding them to an OpenAI-compatible Chat Completions or Responses backend instead. It is built for people running Atuin who want control over which AI backend answers their queries — OpenAI's own API, a Codex access token, or a Codex OAuth device login flow, selected via the BACKEND environment variable. In openai mode, an OPENAI_API setting of auto, responses, or chat_completions decides which API shape is used, with auto trying Chat Completions first and falling back to Responses.
The proxy can run under Docker Compose — copy .env.example to .env and run docker compose up --build — or locally, since it depends only on the Python standard library at runtime and starts with python3 -m atuin_ai_proxy serve. Each HTTP response includes a request id, and log verbosity is configurable across INFO, WARNING, DEBUG, and TRACE levels for troubleshooting.
Internally, the proxy accepts POST requests at /api/cli/chat, replies with a text/event-stream, and translates upstream events — response.output_text.delta, Chat Completions' choices[].delta.content, function_call/tool_calls, and response.completed — into the text, tool_call, done, and error events Atuin expects. Documented failure responses include 400 for a missing model, 401 for a token mismatch, 502 for auth or upstream HTTP errors, and 504 for an upstream timeout. Licensing and hosting costs are not documented, since this is a proxy that runs on infrastructure you control rather than a hosted service.
Configure Atuin's [ai] section with an endpoint and an api_token pointing at the running proxy instance.
TRACE logging is sanitized and bounded, but the documentation notes it can still include shell history, prompts, paths, and command output, so it is meant only for active troubleshooting rather than routine use.
codex-token uses a Codex access token supplied directly, while codex-oauth authenticates through a Codex OAuth device login flow and stores the resulting credentials in auth.json.
