Connect goose to CometAPI with a Custom Provider

Last reviewed: 2026-08-31

Direct answer

To connect goose to CometAPI, create an OpenAI-compatible custom provider in goose, configure the CometAPI chat-completions route, enter the real credential only through the goose credential prompt, and register an exact model ID that is currently available to your CometAPI account. Start with streaming disabled, prove that an ordinary prompt succeeds, and then run a disposable file-operation test to confirm tool calling.

The CometAPI Quickstart documents its OpenAI-compatible API root and model-catalog workflow. The goose provider guide explains provider and model configuration and, importantly, says goose relies heavily on tool-calling capabilities. A model returning text is therefore necessary but not sufficient: the useful acceptance test is whether goose can invoke a local tool and produce the expected artifact.

Who this is for

This guide is for developers who already have access to CometAPI and want to use goose as a local coding agent. It covers the goose CLI because its commands and results are easy to reproduce, but the same contract checks apply when using goose Desktop.

You should be comfortable creating a disposable directory and reading terminal output. You do not need to write an SDK client. You do need permission to use a model that supports text chat and OpenAI-style tool calls. Run the first test outside a real repository so an incorrect model or over-broad instruction cannot modify valuable files.

Key takeaways

• Configure CometAPI as a distinct custom provider instead of overwriting an unrelated provider record.
• Distinguish CometAPI’s API root from the complete chat-completions request route expected by the custom-provider field.
• Copy a current model ID exactly; do not infer availability or tool support from a model family name.
• Treat a verified local file operation as the tool-calling acceptance test.
• Keep credentials, authentication headers, raw request bodies, and raw response bodies out of logs.
• Change one variable at a time when diagnosing a failure.

Sources checked

• CometAPI Quickstart documents the API root, environment-based credential handling, model catalog, and OpenAI SDK compatibility.
• Configure LLM Provider documents goose providers, model selection, OpenAI-compatible endpoints, and the importance of tool calling.
• goose Quickstart documents installation, goose configure, starting a session, and a small local build workflow.
• The aaif-goose repository confirms that goose is an open-source local agent with desktop, CLI, API, provider, and extension support.

Contract details to verify

Establish a clean local baseline

Install goose by following the platform-specific instructions in the official quickstart. Verify that the CLI resolves before configuring a provider, then create an empty working directory:

goose --version
mkdir goose-cometapi-check
cd goose-cometapi-check

If the first command is not found, fix the installation or shell path before touching provider settings. The goose quickstart specifically calls out path and keyring problems as setup issues. Mixing those local failures with an API diagnosis wastes time and can lead to unnecessary credential rotation.

Create the custom provider

Run the interactive configurator:

goose configure

Choose the custom-provider flow, add a provider, and use these values as the contract checklist:

• API type: OpenAI Compatible.
• Display name: CometAPI.
• Authentication required: yes.
• Credential: enter the real value only in the goose prompt. If a screenshot or transcript needs a placeholder, use [REDACTED].
• Available models: add one exact, current model ID from the CometAPI catalog.
• Streaming support: leave it disabled for the first diagnostic run, then enable it only after confirming that the chosen model and route support streaming.

CometAPI publishes the API root: https://api.cometapi.com/v1 . The current goose custom-provider configuration uses an API URL for an OpenAI-compatible request endpoint, so the complete value for this flow is the chat-completions route: https://api.cometapi.com/v1/chat/completions . Do not paste only the root into a field that expects the full request endpoint.

This is a version-sensitive distinction. If a future installed goose release explicitly labels the field as a base URL and states that it appends the chat path itself, follow that release’s provider guide and enter the documented root. Record whether goose expects a root or a full route; a mismatch normally appears as a path-level failure rather than a model-quality problem.

Select a model for an agent, not just chat

CometAPI’s quickstart describes a catalog spanning text and other media. That breadth does not mean every listed model is suitable for goose. The goose provider guide says the agent depends heavily on tool calling, so require all of the following before selecting a model:

1. The exact ID appears in the current CometAPI catalog available to your account.
2. The model accepts text chat through the configured endpoint family.
3. Its current route supports OpenAI-style tool calls.
4. The intended context and output limits fit the coding task.
5. Streaming support is known before you enable the goose streaming toggle.

Do not copy an old ID from a blog post or assume that a text-capable model can call tools. The model-catalog validation guide provides a separate checklist for catalog drift.

Run the happy path

Start goose from the empty directory:

goose session

First ask a short question that requires no tool. If the response succeeds, use this fixed tool test:

Create a file named goose-check.txt in the current directory.
Write exactly goose-ok followed by a newline.
Read the file back.
Report the exact content and do not change any other file.

Approve the local file action if your goose policy asks for confirmation. After goose finishes, verify the artifact independently in the shell:

printf 'goose-ok\n' | cmp -s - goose-check.txt
echo $?

An exit status of 0 means the file matches exactly. This is stronger evidence than a conversational message claiming that the file was written. The happy path passes only when configuration is saved, ordinary text works, the file is created, and the independent comparison succeeds.

Capture a sanitized result

Keep a compact operational record that can be compared across models without exposing message content or credentials:

timestamp_utc: 2026-08-31T00:00:00Z
test_case: goose-file-tool-check
goose_version: record-local-version
provider_display_name: CometAPI
endpoint_host: api.cometapi.com
endpoint_path: /v1/chat/completions
model_id: record-exact-selected-id
streaming_enabled: false
outcome: pass-or-fail
http_status_class: record-if-visible
latency_ms: 0
tool_file_created: false
file_content_matched: false
error_category: none-or-classified
retry_count: 0

Do not log the credential, authentication headers, keyring contents, full provider configuration, complete prompts, raw request bodies, or raw response bodies. Error text can sometimes repeat submitted data, so inspect and redact it before sharing. A stable error category, status class, sanitized host and path, model ID, goose version, and test outcome are usually enough to isolate the failing layer.

Follow the error path methodically

If either test fails, keep the model, prompt, directory, and streaming setting fixed while you classify the failure. Capture the safe fields above, then change only one axis:

1. For a local command or keyring failure, repair the goose installation or documented credential-store choice without changing the API route.
2. For an authentication failure, re-enter the credential through goose and retry once. Do not print it for comparison.
3. For a path failure, compare the configured root-versus-full-route behavior with the current goose provider guide.
4. For a model lookup failure, return to the current CometAPI catalog and copy the ID exactly.
5. For a tool-call failure after successful text, verify tool support or choose another currently documented tool-capable model.
6. For a streaming parser failure, disable streaming and repeat the same prompt.
7. For throttling or a transient upstream failure, wait and make one bounded retry. Do not treat repeated retries as a configuration test.

Once the fixed test passes, re-enable optional behavior one item at a time. That preserves a known-good baseline and makes any regression attributable.

Failure modes

Avoid changing the route and model together. Doing so can turn one clear failure into an ambiguous success and leave the original cause unknown. For deeper inspection after the connection works, use the same site’s guide to review tool-call payloads .

FAQ

Can every CometAPI model run goose?

No. A model can generate text yet still be unsuitable for an agent that relies on structured tool calls. Confirm current availability, the correct endpoint family, and explicit tool support. Then prove the behavior with the local file test instead of relying on a model-family assumption.

Should I use the CometAPI root or the chat-completions route?

For the custom-provider flow described here, use the complete chat-completions request route. Keep the published CometAPI root as the source of truth, and check the current goose field semantics when upgrading. If goose begins appending the request path itself, using the full route as a base could duplicate path segments; that is why the installed version and sanitized endpoint path belong in the test record.

Where should I store the credential?

Enter it only through the goose credential prompt or the documented platform credential mechanism. Do not place it in the disposable project, shell history, a committed provider file, screenshots, or logs. The guide to keeping CometAPI keys out of repositories covers the repository boundary in more detail.

Is a normal chat response enough to verify the integration?

No. It verifies basic authentication, routing, model lookup, and text generation, but it does not prove that the model can emit a usable tool call or that goose can execute it. Require the on-disk file and exact-content comparison before declaring the agent path healthy.

Should streaming be enabled immediately?

Start with it disabled because a non-streaming result is easier to classify. After text and tool use pass, enable streaming and repeat the same fixed prompt. If only the streaming run fails, you have isolated the problem without disturbing the known-good provider and model settings.

What should I share when asking for help?

Share goose version, provider display name, sanitized endpoint host and path, exact model ID, streaming flag, status class, stable error category, retry count, and whether the file appeared. Remove credentials, authentication headers, project contents, full prompts, and raw response bodies before sharing anything.

Reader next step

Create the disposable directory, configure one current tool-capable model, and run both the text and file checks. Keep the sanitized result as your baseline before enabling streaming, adding extensions, or opening goose in a real repository.

When you are ready to configure the provider, Start with CometAPI , then return to the fixed acceptance test above.