Connect Continue to CometAPI for IDE Chat | CometAPI Integration Notes

Last reviewed: 2026-08-12

Direct answer

A Continue CometAPI integration uses Continue’s openai provider with a custom API base, a current CometAPI text model ID, and the chat role. Set apiBase to the documented CometAPI base URL , supply the credential through your approved local secret process, and select a model ID from the current CometAPI model catalog .

For a predictable first test, configure Continue to use Chat Completions. CometAPI documents an OpenAI-compatible POST /v1/chat/completions route. Continue’s OpenAI-compatible provider guide says apiBase overrides the provider base and useResponsesApi: false forces Chat Completions when Continue would otherwise select the Responses endpoint for certain model families.

Do not copy an old model name from an unrelated example. Model availability and capabilities are catalog data, so choose the ID at setup time and preserve its spelling exactly.

Who this is for

This guide is for developers using Continue in VS Code or a JetBrains IDE who want CometAPI to provide the model behind normal IDE chat. It assumes Continue is already installed and that you can open or create its YAML configuration.

The scope is deliberately narrow: establish one working chat model before enabling Edit, Apply, Agent mode, image input, or tool use. Continue documents those as separate roles or capabilities. Keeping the first request small makes a provider, model, endpoint, or authentication mistake easier to isolate.

Key takeaways

Use provider: openai; Continue documents this provider as supporting an overridden apiBase for OpenAI-compatible services.
Use a current CometAPI model ID that the public catalog identifies as suitable for text or chat routing.
Start with only the chat role. Add other roles after the chat path works.
Set useResponsesApi: false for this Chat Completions procedure, especially when Continue would otherwise choose /responses for the selected model family.
Treat a visible answer as necessary but not sufficient evidence. Confirm the active model and, where diagnostics are available, the destination host and endpoint family.
Keep credentials, request headers, prompts, source code, and full response bodies out of routine troubleshooting logs.

Sources checked

Continue’s OpenAI model provider configuration documents provider, model, apiKey, custom apiBase, legacy completions behavior, and the useResponsesApi switch.
The Continue config.yaml reference defines required configuration and model fields, model roles, capability overrides, completion options, and request options.
Continue’s Chat Role guide explains that the selected chat model powers normal Chat and can also serve Edit and Apply when separate models are not configured.
The CometAPI OpenAI-compatible quickstart documents the base URL, Chat Completions request shape, current authentication requirement, common parameters, and basic troubleshooting.
The CometAPI model catalog guide documents a public catalog containing model IDs, providers, capabilities, routing metadata, and pricing information.

Contract details to verify

Choose a model before editing YAML

Open the live catalog and select a model whose metadata matches a text or chat workflow. Record the exact id, provider, relevant capabilities, and documented endpoint support. Do not infer chat support from a familiar brand name alone: the catalog includes multiple model types, including media models that do not belong on a Chat Completions route.

The catalog guide describes GET /api/models as public and says it does not require an authorization header. That makes it useful as a preflight step even before the private chat request is tested. If your organization snapshots approved model choices, record when the model ID was selected so a later catalog change is distinguishable from a configuration typo.

Build the smallest useful Continue configuration

Use this as a template. Replace CURRENT_TEXT_MODEL_ID with the exact catalog ID, replace COMETAPI_BASE_URL_FROM_DOCS with the value on the CometAPI quickstart, and replace the redacted credential only in your protected local configuration.

name: CometAPI Chat
version: 1.0.0
schema: v1

models:
  - name: CometAPI IDE Chat
    provider: openai
    model: 'CURRENT_TEXT_MODEL_ID'
    apiBase: 'COMETAPI_BASE_URL_FROM_DOCS'
    apiKey: '[REDACTED]'
    roles:
      - chat
    useResponsesApi: false

The root name, version, and schema fields are required by Continue’s YAML reference. Inside models, name, provider, and model are required. The explicit chat role limits the first test to the intended workflow. The API base override directs the OpenAI-compatible provider to CometAPI, while useResponsesApi: false keeps the request on the Chat Completions family documented by the CometAPI quickstart.

Do not add tool_use or image_input merely to make the configuration look complete. Continue says a capabilities array overrides its autodetection. An incorrect override can advertise behavior the selected deployment does not provide. Add a capability only after the current model metadata and an actual test support it.

Keep the local configuration out of version control when it contains a live credential. The [REDACTED] value above is intentionally unusable. For a broader repository boundary, see how to keep CometAPI keys out of repositories .

Run the happy path

Save and activate the YAML configuration in Continue.
Select CometAPI IDE Chat as the active chat model.
Send a small deterministic prompt such as Reply with exactly COMETAPI_CONTINUE_OK. Avoid attaching a repository or large file to this first request.
Confirm that Continue displays a nonempty response and still shows the intended model as selected.
Where Continue or your network tooling exposes diagnostics, confirm the destination host is api.cometapi.com and the endpoint family is chat_completions.
Send a second short coding question to rule out a one-off UI artifact. Do not enable automatic repeated retries.

A successful pair of requests establishes the basic client-to-provider path. It does not prove that Agent tools, images, long contexts, streaming, Edit, or Apply work. Test each added role or capability separately. Continue notes that a selected chat model can be used for Edit and Apply when dedicated models are absent, so expanding scope can change which operations reach this provider.

Failure modes

Use a controlled error path

When the first request fails, stop before changing several fields at once. Capture a sanitized record, classify the failure, make one correction, and retry the same small prompt once. If it still fails, use the CometAPI quickstart’s direct request procedure from a protected environment. A direct request that succeeds while Continue fails points toward YAML, config activation, or Continue’s endpoint selection. The same failure in both paths points more strongly toward the credential, model ID, route compatibility, or provider availability.

Retain only fields needed to compare attempts:

Field	Safe example or rule
`event_time`	ISO timestamp
`client_surface`	`continue_ide`
`operation`	`chat`
`config_name`	`CometAPI Chat`
`model_id`	Exact nonsecret catalog ID
`api_host`	`api.cometapi.com`
`endpoint_family`	`chat_completions` or `responses`
`http_status`	Numeric status when available
`latency_ms`	Elapsed client time
`attempt`	Small integer
`error_class`	`auth`, `model`, `endpoint`, `config`, `network`, or `unknown`
`response_chars`	Length only, not response text

Never log the credential, authorization data, complete headers, prompt text, attached code, or full response body. If a diagnostic export includes those values, redact them before sharing it.

Configuration cannot be parsed

Check YAML indentation and the required root and model fields. Confirm models is a list and roles is a list beneath the intended model. A parser failure happens before the provider contract is tested, so changing the CometAPI model ID will not repair malformed YAML.

Authentication fails or the response status is 401

Confirm the placeholder was replaced only in the protected local configuration and that Continue is using that configuration. The CometAPI quickstart specifically advises checking that the credential is available in the runtime sending the request. Do not paste the live value into an issue, chat message, screenshot, or test repository.

The model is not found

Refresh the public catalog and compare the configured value character for character with a current text-capable model ID. Also verify that the selected catalog record supports the route you are testing. Replacing the ID with another unverified guess obscures whether the original problem was spelling, availability, or modality.

The request goes to the wrong service

Recheck apiBase, verify that the intended Continue config is active, and inspect the destination host if diagnostics expose it. CometAPI’s quickstart identifies an unchanged default provider base as a reason an OpenAI SDK client may still call the wrong service. The same principle applies to Continue’s OpenAI-compatible provider.

Continue selects the Responses endpoint

Continue documents that it may use /responses by default for o-series and GPT-5 model families. If diagnostics or an error message show that endpoint during this Chat Completions procedure, confirm useResponsesApi: false is attached to the active model entry. Do not switch to the legacy completions endpoint; Continue documents that as a separate behavior from Chat Completions.

The request times out or returns a transient server failure

Record the status, latency, model ID, and attempt number, then retry the same minimal request once. A timeout alone does not identify whether the client, network, gateway, or upstream model caused the delay. Repeated automatic retries can increase cost and erase the sequence needed for diagnosis.

FAQ

Why does Continue use the `openai` provider for CometAPI?

Continue’s provider documentation explicitly supports OpenAI-compatible services by allowing apiBase to be changed. CometAPI documents an OpenAI-compatible Chat Completions route, so the provider name selects Continue’s compatible request adapter while the base override selects CometAPI as the destination.

Which CometAPI model should I put in the example?

Use a current catalog ID whose metadata supports text or chat routing. This article does not hard-code a model because a familiar name can refer to a different modality or change availability. The live catalog is the contract for selection.

Is `useResponsesApi: false` always required?

It is required for the deterministic Chat Completions path described here when Continue would otherwise choose Responses. Continue specifically documents the switch for model families that default to /responses. If you later adopt a Responses-based workflow, verify that contract separately instead of silently removing the setting.

Can the same entry power Edit and Apply?

Continue says the selected chat model is used for Edit and Apply when dedicated models are not configured. Start with chat only, then deliberately add or test those workflows so an edit request does not become an unobserved expansion of the integration.

Should I declare tool or image capabilities?

Only after verifying them for the selected model and route. Continue’s reference says explicit capabilities override autodetection. A capability declaration is therefore a contract assertion, not a harmless label.

What proves the setup is working?

Two small successful prompts, the intended model remaining active, and diagnostics showing the expected destination and endpoint family provide useful evidence. A response in the UI without destination confirmation could still come from another active configuration.

Reader next step

First, choose a current text model and complete the one-model YAML configuration. Then run the two-request happy path and save only the sanitized fields above. For a deeper model-selection check, use the CometAPI model catalog validation guide .

When you are ready to create the account and obtain the local credential needed for the test, Start with CometAPI . Keep the first integration limited to IDE chat; promote additional roles only after each one passes its own happy and error paths.