← All docs

Choosing an AI provider

Bring your own key — or your own infrastructure entirely.

Five options, one active at a time

Claude, GPT, Gemini, Grok, or a private-hosted OpenAI-compatible endpoint you run yourself. You can store credentials for more than one and switch which is active whenever you like — the one marked In use is the one every subsequent ticket fix is sent to.

What it receives

The ticket's summary and description, the source files gathered for it, related tickets, and runbook pages if a Confluence connector is configured. It is asked to return the complete new content of every file it touches — not a diff description — plus a plain-language explanation and an honest can_fix: false when it doesn't have enough to work with.

A private-hosted endpoint keeps it off any third party

Point the private-hosted option at vLLM, Ollama, TGI, or any OpenAI-compatible server you run — inside a VPC, with no auth at all if that's how it's set up. In that mode there is no AI-vendor sub-processor for the reasoning step: ticket context and source code never leave infrastructure you control.

Model names aren't defaulted for you

Vendors rename and retire model ids on their own schedule, so — except for Claude, which is pinned to a current model as the platform-wide fallback — there's no baked-in default that could 404 mid-run. Paste the exact model id from the provider's own current model list, then use Test connection, which confirms it exists without generating any tokens.