Connect Roo Code to CometAPI and verify native tool calling.

Last reviewed: 2026-08-27

Direct answer

A Roo Code CometAPI integration uses Roo Code’s OpenAI Compatible provider profile. In Roo Code, create a provider profile, select OpenAI Compatible, set Base URL to https://api.cometapi.com/v1 , enter your CometAPI key in Roo Code’s protected settings field, and select an exact current model ID.

The model choice is the critical part. Roo Code’s OpenAI Compatible provider guide says Roo Code uses native tool calling exclusively and has no XML fallback. A model must therefore support OpenAI-compatible tool calls, not merely return text. Use the public CometAPI model catalog documentation to check the current model ID, provider, capabilities, and endpoint hints, then confirm that the chosen model supports the tool schema required by Roo Code.

A normal assistant reply proves only that authentication, routing, and basic generation worked. To verify native tool calling, give Roo Code a read-only task that requires a file tool. The task timeline should show a native tool-call event followed by the matching tool result. Confirm that the answer reflects the file and that the workspace remains unchanged.

Who this is for

This guide is for developers who already use Roo Code in VS Code and want to route a coding task through CometAPI’s OpenAI-compatible interface. It is also useful for maintainers diagnosing a setup that can generate text but cannot read files, call functions, or complete other tool-driven steps.

You need Roo Code, a CometAPI account and key, an expendable test workspace, and a model currently documented as compatible with the required tool behavior. Keep the first test read-only and use a repository with no sensitive files. For a stronger local secret boundary, review how to keep CometAPI keys out of repositories .

Key takeaways

Select OpenAI Compatible in Roo Code rather than the official OpenAI provider when using the CometAPI base URL.
Resolve the model ID from the current catalog instead of copying a stale model name from an old screenshot or tutorial.
Treat a text response and a native tool call as two separate acceptance checks.
Start a fresh Roo Code task after changing profiles because Roo Code documents per-task profile persistence.
Record diagnostic metadata, but never record the key, complete prompts, sensitive file contents, or unredacted tool results.

A practical happy-path workflow is:

Open the CometAPI model catalog guide . Record the exact model ID, provider, model type, capability metadata, and endpoint hints. The catalog endpoint is public, so catalog discovery does not require a credential. Select a text-capable model whose documentation confirms OpenAI-compatible tool calling.
In Roo Code, open Settings, choose Providers, and create a new profile with the plus button. The Roo Code profile documentation says a profile can hold its own provider, authentication details, model selection, rate limit, and model settings. Give the profile an obvious name such as cometapi-tool-test.
Select OpenAI Compatible, enter the documented CometAPI base URL, paste the key into Roo Code’s key field, and enter the exact model ID. Do not copy the key into a workspace file, terminal history, issue, or screenshot. Roo Code documents that keys entered through its profile UI are stored in VS Code Secret Storage.
Select the new profile before opening a fresh task. This avoids confusing a new global selection with an existing task that retained its original profile.
Run a minimal connectivity check:

Reply with CONNECTED and one short sentence. Do not use a tool.

A successful reply establishes basic connectivity. It does not establish tool support.

In a throwaway repository containing a harmless README.md, run a tool-specific test:

Use the file-reading tool to read README.md. Do not edit files or run commands. Return only the first Markdown heading and the file name.

The happy path has four observable results: Roo Code shows a native file-read tool event, it shows the corresponding tool result, the response matches the known heading, and no file changes appear. Check the repository afterward:

git status --short

No output means the tracked workspace is clean. If the repository already had changes, compare the before and after states instead of assuming every listed file came from the test.

Keep a sanitized diagnostic record for both successful and failed checks. Useful fields include the time, profile name, provider type, base URL host and path, model ID, test stage, outcome, status code when visible, tool name, tool-result state, latency, and request ID when available. A safe example is:

{
  "observed_at": "2026-08-27T00:00:00Z",
  "profile": "cometapi-tool-test",
  "provider_type": "openai-compatible",
  "base_url_host": "api.cometapi.com",
  "base_url_path": "/v1",
  "model_id": "selected-current-model",
  "test_stage": "native-tool-read",
  "outcome": "success",
  "http_status": 200,
  "tool_name": "read_file",
  "tool_result": "completed",
  "latency_ms": 842,
  "request_id": "req-redacted",
  "credentials": "[REDACTED]"
}

Do not place request bodies, response bodies, source-file contents, environment dumps, or credentials in routine logs. If a support case needs more detail, add the smallest sanitized fragment that demonstrates the failure.

Sources checked

Using OpenAI Compatible Providers With Roo Code documents the provider fields, native tool events, tool-capability requirement, and common connection failures.
API Configuration Profiles documents profile creation, profile switching, per-profile rate limits, per-task persistence, and VS Code Secret Storage.
Change the base URL to CometAPI establishes the OpenAI-compatible base URL and explains common 401, 404, and HTML-response symptoms.
List available CometAPI models documents the public model catalog and the model metadata available for current selection.
Create a chat completion documents Chat Completions, native tools, tool-result correlation, streaming behavior, and cross-provider differences.

Contract details to verify

Provider fields: Roo Code expects the provider type, base URL, key, and model ID. A missing /v1 path can route the request incorrectly, while an official OpenAI URL would bypass the intended CometAPI route. Copy the base URL from the current CometAPI guide rather than reconstructing it from memory.

Exact model ID: Model names are routing identifiers, not informal display names. Use the exact current ID shown by the catalog. Check that its model type and endpoint hints fit a text-based coding task. Do not infer tool support from a well-known model family name alone.

Native tool behavior: Roo Code sends tool definitions through the OpenAI-native tools schema and expects dedicated tool events. The CometAPI Chat Completions reference describes function definitions, a tool_calls finish state, returned tool-call arguments, and the matching tool result. Roo Code handles that loop, but the operator should still verify the event and result in the timeline. For a deeper payload review, see Review tool-call payloads in CometAPI examples .

Endpoint family: CometAPI notes that some OpenAI Pro, o-series, and Codex model families have more complete support on the Responses endpoint. Do not assume that a model recommended for Responses will satisfy a Roo Code profile expecting OpenAI-compatible tool behavior through another route. Confirm the route used by the selected model before treating a failure as an authentication problem.

Provider-specific parameters: CometAPI warns that parameter ranges and supported fields vary across model providers. Roo Code also exposes advanced settings such as context window, output limits, pricing, image support, and native tool calling. Configure only values supported by the chosen model; invented limits can create failures that look like gateway problems.

Profile identity: Roo Code documents that a task retains the profile it started with. After changing the model or provider, open a new task and confirm the selected profile name before testing again. This is especially important when two profiles use similar display names.

Failure modes

Invalid key or 401 response: Re-enter the key in the Roo Code profile and confirm that the intended profile is active. Do not expose the value in a screenshot or log. A failed key check does not say anything about native tool support because the request did not reach that stage.

404 response or HTML instead of JSON: Check the base URL against the CometAPI guide, including the /v1 path. CometAPI identifies a missing path and redirects from an incorrect route as common causes. Do not keep changing the model while the route itself is wrong.

Model Not Found: Refresh the public catalog, copy the exact model ID, and confirm that it is available rather than upcoming. A display name, provider nickname, or retired alias may not be a valid request identifier.

Text works, but no tool event appears: First make the prompt explicitly require a harmless file read. If Roo Code still responds without a native tool event, verify that the model supports OpenAI-compatible tool calling. Roo Code has no XML fallback, so a text-only model cannot complete the required contract.

Tool call appears, but arguments or results fail: The provider may implement only part of the native tools interface, the model may emit malformed arguments, or the requested tool may be unavailable in the active Roo mode. Record the tool name and sanitized error category, then confirm model capability and Roo permissions. Do not broaden permissions merely to make the test pass.

The wrong model keeps answering: Check the profile shown in the task. Existing tasks retain their starting profile even when another profile becomes the global selection. Start a new task after the change and rerun the same two-stage test.

Rate limiting: A 429 response is a capacity or pacing signal, not proof that the base URL or model ID is invalid. Wait before retrying. If repeated calls trigger limits, Roo Code profiles can add a minimum interval between requests. Change pacing separately from model selection so the diagnostic result remains clear.

Route mismatch: If the selected model is documented for Responses rather than the Chat Completions tool flow being tested, choose a model and endpoint combination supported by the client workflow. Repeatedly retrying an incompatible route will not repair the contract.

Use this error-path workflow to keep diagnosis controlled:

Stop the task and save only sanitized fields from the failed attempt.
Open a fresh task with the intended profile and run the non-tool connectivity prompt.
If connectivity fails, classify the result as route, authentication, model ID, or rate-limit failure before changing anything.
If connectivity succeeds, run the explicit read-only tool prompt. A failure at this stage narrows the problem to model tool support, partial provider compatibility, Roo mode permissions, or tool-result handling.
Change one variable at a time, start another fresh task, and repeat both checks. Do not rotate a working key to troubleshoot a model-capability failure.
After success, confirm the repository state and retain the sanitized log as the baseline.

FAQ

Can I select Roo Code’s official OpenAI provider instead?

Not for this setup. Roo Code’s provider guide distinguishes the official OpenAI configuration from other OpenAI-compatible endpoints. Select OpenAI Compatible so the profile exposes the custom base URL needed for CometAPI.

Does a successful chat response prove native tool calling works?

No. It proves the request reached a model and returned text. Native tool verification requires a task that cannot be completed honestly without a tool, plus a visible tool-call event and its corresponding result.

Will every CometAPI text model work with Roo Code?

No. Roo Code requires OpenAI-compatible native tool calling. Use the current catalog to find the exact model and route, then verify tool support rather than relying only on the model’s text capability.

Why avoid hard-coding one model in this tutorial?

The catalog is the current source for availability, IDs, providers, capabilities, and endpoint hints. A fixed recommendation can become stale even when the Roo Code configuration process remains valid.

Should I enable automatic approval for the first test?

It is unnecessary for this verification. Keep approvals visible, request a read-only operation, and confirm each tool event. Consider broader automation only after the model, route, permissions, and rollback process are understood.

Why did changing profiles not affect my existing task?

Roo Code documents profile persistence per task. Create a new task after switching the profile or model, then verify the profile name before sending the prompt.

Reader next step

Open the current model catalog, choose a text model with confirmed native tool support, create a dedicated Roo Code profile, and run the connectivity and read-only tool checks in a disposable repository. Save the sanitized result as your known-good baseline. If basic routing needs separate verification, smoke-test the CometAPI chat completion contract before returning to Roo Code.

When you are ready to create the provider account and configuration used in this workflow, Start with CometAPI .