Problem
Kilo has no first-class way to get started with aimlapi.com, an OpenAI-compatible aggregating gateway that fronts 1000+ models. A new user has to leave the CLI, create an account on the website, top up a balance, copy an API key, and paste it back into a provider profile by hand.
Requested behavior
Add aimlapi.com as a built-in provider with a guided TUI onboarding sub-flow that:
- takes an existing API key, or
- signs the user in by email (passwordless 6-digit code) and tops up the balance via the hosted partner-checkout page, then writes the issued key straight into the provider profile.
The provider is registered in the picker (shown in the Popular group) with a dynamic model catalog fetched from GET /v1/models — the same per-provider fetcher pattern Kilo already uses for kilo/apertis — and sends the partner attribution headers on every request. Default endpoints point at production and each is overridable via AIMLAPI_*_URL env vars for local/staging testing.
Why it belongs in Kilo
It removes the biggest onboarding friction for a large multi-model gateway: users go from "no provider" to a working, funded key without leaving the TUI. It follows Kilo's existing dynamic model-catalog fetch and provider-picker patterns, so it is additive and consistent with how other providers (kilo/apertis) are surfaced.
Alternatives or workarounds considered
- Manual setup: add a custom OpenAI-compatible endpoint and paste a key obtained from the website. Works, but loses the guided top-up and partner attribution.
- Documentation only (a how-to in the docs) — does not solve the in-CLI top-up / key-issuance step.
Examples, screenshots, or prior discussion
Based on the working AIMLAPI integrations in Zero and OpenClaude, adapted for Kilo (dynamic catalog fetch + TUI onboarding). Screenshots of the onboarding screens to be attached.
Problem
Kilo has no first-class way to get started with aimlapi.com, an OpenAI-compatible aggregating gateway that fronts 1000+ models. A new user has to leave the CLI, create an account on the website, top up a balance, copy an API key, and paste it back into a provider profile by hand.
Requested behavior
Add aimlapi.com as a built-in provider with a guided TUI onboarding sub-flow that:
The provider is registered in the picker (shown in the Popular group) with a dynamic model catalog fetched from
GET /v1/models— the same per-provider fetcher pattern Kilo already uses forkilo/apertis— and sends the partner attribution headers on every request. Default endpoints point at production and each is overridable viaAIMLAPI_*_URLenv vars for local/staging testing.Why it belongs in Kilo
It removes the biggest onboarding friction for a large multi-model gateway: users go from "no provider" to a working, funded key without leaving the TUI. It follows Kilo's existing dynamic model-catalog fetch and provider-picker patterns, so it is additive and consistent with how other providers (
kilo/apertis) are surfaced.Alternatives or workarounds considered
Examples, screenshots, or prior discussion
Based on the working AIMLAPI integrations in Zero and OpenClaude, adapted for Kilo (dynamic catalog fetch + TUI onboarding). Screenshots of the onboarding screens to be attached.