Connect Kilo Code to CometAPI with a Custom Provider

Last reviewed: November 8, 2026.

Direct answer

For a Kilo Code CometAPI setup in VS Code, open Kilo’s settings, select Providers, and create a Custom provider. For a model documented to support Chat Completions, choose OpenAI Compatible and enter the CometAPI base URL from the quickstart : scheme https, host api.cometapi.com, and path /v1. Paste your CometAPI key into the API key field and add the exact CometAPI model ID under Models. Submit the provider, then select its model in Kilo’s model picker.

The Kilo provider guide documents both automatic model detection and manual entry. A blank model picker can be a discovery problem: Kilo looks for an OpenAI-compatible /v1/models endpoint, while CometAPI documents a separate public catalog at /api/models. You can consult that catalog and enter an ID manually. This does not establish whether CometAPI’s /v1/models route works in your environment.

Who this is for

This walkthrough is for developers configuring the Kilo Code VS Code extension with their own CometAPI credentials. Have Kilo installed, an active CometAPI key, and a disposable workspace ready before starting.

The procedure covers a Chat Completions custom provider. API-family selection matters: Kilo also offers OpenAI Responses and Anthropic Messages, and its guide recommends those for particular model families. Check the selected model’s endpoint documentation before choosing the provider API. A model’s presence in CometAPI’s catalog alone does not establish compatibility with this recipe.

Key takeaways

• Use a unique provider ID so you can identify this configuration in Kilo.
• Match Provider API to the model’s supported request format.
• Use CometAPI’s documented /v1 base URL and an exact model id.
• Add a model manually if automatic discovery cannot supply it.
• Verify a short response first; check tool use separately before relying on coding actions.

Contract details to verify

These settings come from two contracts: Kilo defines the custom-provider fields, and the CometAPI quickstart supplies the base URL and Chat Completions route.

CometAPI documents direct Chat Completions requests at POST /v1/chat/completions with Bearer authentication. For this setup, enter the base URL shown above and use Kilo’s API key field. Leave the optional custom headers empty for the basic configuration.

Keep the key out of model labels, prompts, shared settings examples, and screenshots. Before sharing a setup record, follow the guide to keeping CometAPI keys out of tutorial repositories . This walkthrough does not require a credential-bearing project file.

Step 1: Choose the model before filling the dialog

The CometAPI models reference documents a public catalog that requires no Authorization header. Following that reference, send an unauthenticated GET /api/models request to the HTTPS API host api.cometapi.com.

In the response’s data array, find a candidate text model and inspect its exact id, model_type, features, endpoints, and upcoming flag. Check the linked api_doc_url when available. For this walkthrough, choose an available model whose documentation supports the Chat Completions route.

Read endpoint metadata carefully. CometAPI’s schema permits endpoints to be a string, array, object, or null; a string may itself contain JSON. A display name or a familiar provider name is insufficient evidence of the correct request format.

Also inspect published context and output limits. A null limit means that the catalog has not exposed a value. It does not mean unlimited capacity. Confirm missing details in the model documentation before adding a large repository context or changing Kilo’s advanced model configuration.

The public catalog describes models and capabilities. Account access and a successful request still need their own check. Record the selected ID exactly, including punctuation and suffixes, so that your first test uses the model you reviewed.

Step 2: Create and select the custom provider

Follow the VS Code flow in Kilo’s current provider documentation:

1. Open Kilo’s Settings using the gear icon and select the Providers tab.
2. Scroll to the bottom and choose Custom provider.
3. Enter the provider ID, display name, Provider API, Base URL, and API key from the table above.
4. Under Models, select the verified model if automatic detection lists it. Otherwise, add its exact ID manually.
5. Click Submit, then select the provider’s model from the model picker.

Kilo documents a Fetch models control for retrying discovery after correcting the base URL or key. You can use it, but a successful catalog lookup is a different check from a successful generation request. Likewise, manual entry supplies an ID; it does not validate that ID or grant access to the model.

For a reproducible setup note, record the Kilo extension version, provider ID, Provider API selection, base URL, exact model ID, and date. Omit the key. Kilo’s guide directs advanced token-limit, tool-calling, and variant configuration to kilo.jsonc and its custom-model documentation. Leave those changes for a separate step after the basic request works.

Step 3: Check a short response, then the intended workflow

Start a fresh Kilo task in the disposable workspace with the selected provider and model visible. Send a small prompt such as:

Reply with the single line KILO_CONNECTION_OK. Do not use tools.

The expected result is that line without a provider error. This is a proposed reader check, not a measured result from this article. A successful reply establishes that this configuration handled the small request. It does not establish context capacity, streaming behavior under load, or tool compatibility.

If you intend to use file tools, verify that the selected model and route support the tool format Kilo needs. The CometAPI Chat Completions reference describes tool calls as structured responses with message.tool_calls and matching tool-result IDs. It also directs some model-specific tool workflows to Responses. Ordinary assistant text cannot prove that this exchange works.

For a narrow follow-up, create kilo-provider-check.md yourself in the disposable workspace:

Integration fixture.
The marker is COMET-KILO-42.

Then ask Kilo to read that file and report the marker, with no edits or terminal commands. Keep action approvals enabled under your local policy, and approve only the fixture read if approval is requested. The prompt describes the task; approval controls and the disposable workspace provide the practical boundary.

Treat the read check as successful only if Kilo shows a file-read action and returns the correct marker. A statement that it read the file is insufficient. Stop if it proposes unrelated access or if the provider rejects the tool request. Resolve that capability mismatch before trying edits or commands in a real project.

Failure modes

Use the smallest failing prompt and change one setting at a time. Save the displayed error category, any exposed HTTP status, model ID, provider API, and time. Redact credentials and repository content from diagnostic notes.

Catalog reachability checks access to a public endpoint. It does not validate the API key or prove that an authenticated generation request can succeed. Similarly, retrying Fetch models cannot repair an unsupported generation parameter.

If you change Provider API or model ID, start another fresh task and repeat the same small prompt. This is a controlled comparison: keep the prompt fixed so that you can relate the outcome to the configuration change.

FAQ

Can I proceed when automatic model detection fails?

Yes. Kilo explicitly supports manual model entry. Obtain the exact ID from CometAPI’s catalog, check its endpoint documentation, add it under Models, and verify it with a small request. Keep the discovery failure separate in your notes.

Should I paste the complete Chat Completions URL into Base URL?

Kilo documents support for full operation URLs, but this walkthrough uses the standard base URL from the CometAPI quickstart : scheme https, host api.cometapi.com, and path /v1. Keep that value consistent while following these steps.

Does OpenAI Compatible cover every CometAPI model?

No. The catalog includes multiple model types and endpoint formats. Kilo distinguishes Chat Completions, Responses, and Anthropic Messages. Use the API family documented for your selected model; a matching brand or display name does not establish protocol compatibility.

Does a successful reply mean coding tools are ready?

It establishes only the small request you ran. Confirm tool support for the model and route, then check an observable, narrowly scoped action before expanding the workflow.

Reader next step

Choose one documented Chat Completions model, create the custom provider, and run the short response check. Keep a sanitized configuration note so you can reproduce the result. If your next task needs file tools, complete the fixture read before moving to project edits.

If you also work in Neovim, the CodeCompanion connection walkthrough covers that editor’s separate adapter setup.

Need an account and API key first? Start with CometAPI , then return to the provider dialog with the model’s request format already checked.

Sources checked

• Kilo: Using OpenAI-Compatible Providers — VS Code custom-provider fields, API-family choices, manual models, automatic detection, and troubleshooting.
• CometAPI: OpenAI-compatible API quickstart — base URL, Bearer authentication, and the Chat Completions request route.
• CometAPI: List available models — unauthenticated public catalog, exact IDs, endpoint hints, capability fields, and null-value meanings.
• CometAPI: Create a chat completion — tool-call structure and model-specific request-format considerations.

These official references were checked live on November 8, 2026. This is a documentation-based setup guide; an authenticated Kilo session and the suggested fixture checks were not executed for this article.