Providers
Set up a custom provider
Connect an endpoint that implements OpenAI Responses or Anthropic Messages with one of Kition 0.1.41’s supported authentication schemes.
Updated
By Kition Docs
Verified against Kition 0.1.41 (d3e1b931) on 2026-08-29
Compatibility boundary
A custom provider must implement one of the two Agent wire APIs exposed by Kition 0.1.41: responses or anthropic_messages. A service that exposes only legacy /chat/completions is not compatible unless a gateway also provides one of these supported wires.
Model discovery is separate from generation. A successful /models request proves that Kition can read a catalog; it does not prove that streaming, tool calls, or Agent generation work on the selected wire.
Heads up
Do not assume that every service advertised as OpenAI-compatible implements the Responses API. Verify the exact wire before entering a production credential.
Fields available in Settings
- Base URL — the root used for the provider API
- API key — the token Kition sends with provider requests
- Models endpoint —
/modelsby default - Auth scheme — Bearer, Raw, or X-API-Key
- Wire API — OpenAI Responses or Anthropic Messages
- Reasoning effort — Minimal, Low, Medium, or High for endpoints that support it
Configure the endpoint
For Responses-style providers, a bare host is normalized with /v1; an explicit path is preserved. Enter the complete documented Base URL instead of relying on this convenience when a gateway uses a nonstandard prefix.
- Open Settings → AI Providers and select Custom
- Enter the exact Base URL supplied by the endpoint operator
- Enter a limited API key or token
- Open Advanced and set the models path, authentication scheme, and wire
- Choose Sync now, then select a returned text model in the Agent model picker
- Send one small, non-sensitive prompt before trusting the endpoint with workspace context
Headers and authentication limits
The 0.1.41 Settings UI lets you choose the authentication scheme, but it does not expose an editor for arbitrary extra headers or a custom header name. Endpoints that require tenant headers, beta headers, signed requests, or several independent credentials may need a gateway that presents a supported interface.
Do not place additional secrets in the Base URL, model name, or workspace files as a workaround.
Local and private endpoints
Kition accepts the Base URL you enter, including a local HTTP service. Use plain HTTP only on a trusted local connection; use TLS for traffic that leaves the device or crosses a network.
A self-hosted endpoint can receive prompts, selected workspace context, tool schemas, and generated outputs. Review its logs, retention, access control, and operator trust before connecting sensitive workspaces.
Diagnose in layers
- Model sync fails — check Base URL, models path, authentication scheme, DNS, proxy, TLS, and service availability
- Models sync but Agent fails — verify the configured wire, streaming format, selected model, and tool-call support
401or403— verify token format and permissions; do not repeatedly paste a real key into shell history404— confirm both the catalog path and generation wire endpoints- Connection works locally but not remotely — check firewall, certificate chain, reverse-proxy buffering, and access policy
Credential storage
Custom-provider credentials use the same local plaintext secret-file storage as built-in providers in Kition 0.1.41. Disconnect disables the provider but does not reliably delete that persisted secret, so revoke the remote credential and use verified application-data removal guidance when local erasure is required.
Implementation sources
Related pages
Configure an AI provider
Use Kition Cloud or connect OpenAI, Anthropic, DeepSeek, Kimi, or a supported custom endpoint.
Set up common models
Use the DeepSeek and Kimi presets or connect another service through the verified custom-provider compatibility boundary.
Protect provider credentials
Understand how Kition 0.1.41 stores provider secrets and reduce the impact of device or key compromise.
