Connect the LLM CLI to CometAPI for Terminal Prompts

Last reviewed: November 11, 2026 (Asia/Shanghai); primary references fetched November 11 UTC.

Direct answer

For an LLM CLI CometAPI setup, register CometAPI’s documented v1 base URL with llm openai endpoint add, give the registration a distinct local model ID, and select a stored CometAPI key by name. Then run llm -m cometapi-text explicitly. Start with non-streaming text and disable local prompt logging before sending the first request.

The LLM project’s Other models guide documents custom endpoint registration and the distinction between a local model ID and the provider’s model name. The CometAPI Chat Completions reference supplies the matching base URL and /v1/chat/completions operation. Together they let you use an existing terminal tool without writing a request client.

Who this is for

This guide is for developers using Simon Willison’s llm command-line tool for short terminal prompts or reviewed text pipelines. The commands assume a Bash or Zsh terminal, an installed pipx command, and a CometAPI account with a suitable text model.

The procedure follows the maintained LLM documentation checked on November 11. Its stable URLs can advance, so record your installed version and check that it exposes the endpoint subcommands shown below. No CLI installation test or authenticated CometAPI request was performed for this article; the acceptance steps describe what to verify in your own environment.

Key takeaways

• Keep the local name cometapi-text, the upstream model ID, and the stored key name cometapi distinct.
• Supply the /v1 base URL; the client adds the Chat Completions operation path.
• Use a dedicated LLM_USER_PATH so this example’s settings and stored credentials have a clear location.
• Disable SQLite logging deliberately: LLM normally records prompts and responses locally.
• Treat model registration as configuration, then verify account access with one small request.

Install the tool and isolate its profile

The LLM setup guide documents installation through pipx:

pipx install llm
llm --version
llm openai endpoint add --help

If LLM is already installed, check its version and help first. Upgrade through the package manager that owns that installation if the documented subcommand is missing. Avoid maintaining multiple installations with different configuration expectations.

Choose a private profile for this example before storing a key or making a prompt:

umask 077
export LLM_USER_PATH="$HOME/.config/llm-cometapi-demo"
mkdir -p "$LLM_USER_PATH"
chmod 700 "$LLM_USER_PATH"
llm logs off
llm logs status

The setup guide defines LLM_USER_PATH as the location for stored keys, templates, preferences, and logs. Keep that variable set in every terminal running this example. Opening a new terminal without it can select another profile, including different logging settings and model registrations.

The logging reference says logging is enabled by default and documents llm logs off. Confirm that the status command reports logging off in this profile. Turning it off does not delete older records, suppress terminal output, or change CometAPI’s handling of submitted data.

Store the credential and choose the upstream model

Run the interactive key command:

llm keys set cometapi
llm keys path

Paste the credential only at the key prompt. The setup reference explains that stored keys live in keys.json; the path command identifies the active file. Protect that file and its directory with your normal local secret controls. This is a local credential file, not a documented encrypted secret vault. Keep it outside repositories, shared folders, and copied support bundles.

In this article, cometapi is a key name. Do not replace it in later --key cometapi examples with a literal credential. LLM also accepts literal key values through that option, which can put a secret into shell history or process arguments. The site’s repository key-handling guide provides the related source-control checks.

Next, consult the current CometAPI model catalog reference . It documents public GET /api/models access without an Authorization header, exact model IDs, model categories, capability tags, endpoint hints, and an upcoming flag. Choose a currently offered text model whose documentation supports Chat Completions. Set this nonsecret variable to its exact ID, replacing the placeholder:

export COMETAPI_MODEL='REPLACE_WITH_VERIFIED_CHAT_MODEL_ID'

The catalog’s display name and a model name from another provider are not substitutes for its request ID. Catalog presence also does not prove account access. Use the model’s endpoint documentation when interpreting capability hints, and leave optional model parameters out of this first check.

Register a named CometAPI endpoint

With the profile, stored key, and model variable ready, copy the SDK base URL from the CometAPI reference . It must use HTTPS, host api.cometapi.com, and path /v1. Enter that public URL at the prompt below, then register the model:

printf '%s' 'CometAPI base URL: '
read -r COMETAPI_BASE_URL
llm openai endpoint add "$COMETAPI_BASE_URL" \
  -m "$COMETAPI_MODEL" \
  --id cometapi-text \
  --key cometapi \
  --no-stream

The custom endpoint documentation says this command writes extra-openai-models.yaml. Its record should express the following mapping:

The YAML stores the key name rather than the credential. Changing either configuration variable later does not update an existing registration: the command saved its values at registration time.

Keep the base URL separate from the operation path. Appending /chat/completions to api_base would give the client an operation URL where it expects a base. LLM documents Chat Completions as the default family for this integration; --responses selects a different family. Leave Responses, legacy completion mode, tools, and attachments out of the initial registration.

Inspect the local configuration:

llm openai endpoint list
llm openai endpoint list --json
llm models --options -m cometapi-text

Review the stored endpoint, upstream model name, key name, and streaming setting. A listed model proves registration, not a successful generation. The documentation also states that configuring a custom api_base does not send the ordinary configured OpenAI key by default; the explicit CometAPI key association matters.

If cometapi-text already exists in the configuration file, the add command reports an error. Inspect the existing record first. Use the documented --replace option only when you intend to overwrite that registration, then repeat the configuration review. Do not solve a naming collision by dropping explicit model selection from later prompts.

Run one prompt, then a small text pipeline

Send a harmless prompt with the registered model selected explicitly:

llm -m cometapi-text --no-stream --no-log \
  'Explain idempotency in one short sentence.'

The usage guide documents -m for model selection and --no-stream for returning the answer after completion. The logging guide documents --no-log for an individual prompt. Using it here keeps the intended retention choice visible alongside the profile-wide setting.

Check for an ordinary completed text answer and a successful command exit. Record the actual observation rather than treating an expected sentence as a test result. A short successful prompt establishes this account, model, endpoint, and client path at that moment; it does not verify every optional feature or long-running workload.

Once that check passes, try a synthetic text pipeline:

printf '%s\n' 'Use an idempotency key for each user action.' | \
  llm -m cometapi-text --no-stream --no-log \
  'Summarize this note in one sentence.'

LLM’s usage guide explains that piped standard input is combined with the prompt argument, with the argument following the piped content. Both pieces therefore become model input. Review a real file before piping it; local logging being off does not prevent that text from being sent remotely. Keep generated output as text to inspect before using it in another program.

Separate invocations start new conversations by default. This procedure does not use --continue, which the usage guide says resends the previous conversation’s prompts and responses. Decide on retention and context boundaries before adding continuation to scripts.

Contract details to verify

For that last check, use a model ID you have confirmed is absent from the local model list, such as cometapi-text-absent-check. Keep the harmless prompt and other options unchanged. LLM should reject an unknown local ID; do not confuse this with testing an unavailable upstream model, which can reach the service.

Retain the time, llm --version, local and upstream model IDs, configured base, logging verdict, observed exit status, and result category. Omit the key, prompt contents, output contents, and raw error bodies from shared diagnostic notes. No timing, token-cost, or availability claim follows from the configuration listing.

Failure modes

The endpoint subcommand is missing. Compare the installed version and its help with the maintained documentation. Fix the installation mismatch before adapting the commands.

A key exists, but the request is unauthenticated. Check the active profile and the registration’s api_key_name. A stored credential under another name or directory does not establish the intended association.

The wrong provider or model receives the prompt. Keep -m cometapi-text explicit and inspect its saved record. An unqualified llm command can use a different default model.

The model rejects a parameter or route. Recheck its CometAPI documentation and the saved API family. Local capability flags configure client behavior; they do not discover remote capabilities.

Prompt text appears in SQLite. Verify the running process’s profile and logging status. --no-log affects that prompt; neither it nor logs off erases previous history.

A request fails after dispatch. Stop and identify the failure stage before rerunning it. A timeout can leave remote execution uncertain. This guide adds no retry loop and does not establish the client’s effective upstream attempt count. For explicit transport deadlines and response acceptance rules, use the separate Python HTTPX client guide .

Sources checked

Six distinct primary public references returned HTTP 200 on November 11, 2026 UTC:

• LLM: Other models — endpoint registration, model and key-name mapping, configuration inspection, replacement, API families, and streaming flags.
• LLM: Setup — pipx installation, stored keys, key paths, environment configuration, and LLM_USER_PATH.
• LLM: Usage — explicit model selection, non-streaming prompts, standard input, and conversation continuation.
• LLM: Logging to SQLite — default prompt and response logging, profile-wide controls, per-prompt suppression, and logging status.
• CometAPI: Create a chat completion — provider base URL, Chat Completions route, messages, and model-specific request behavior.
• CometAPI: List available models — public catalog access, exact request IDs, categories, capability hints, and upcoming-model metadata.

These maintained technical references support an evergreen integration task. The LLM stable documentation is a moving reference; compare it with your installed release. Profile isolation, the small acceptance procedure, and the diagnostic record are recommendations derived from those documented interfaces.

FAQ

Does the local model name need to match CometAPI’s model ID?

No. model_id identifies the local registration, while model_name supplies the upstream request ID. A distinct local name makes the intended provider easier to select and review.

Does disabling logs keep the prompt on my computer?

No. The command still sends its prompt to the configured service. The logging switches control LLM’s local SQLite record, while shell history, terminal capture, and remote data handling remain separate concerns.

Can this discover models through a compatibility endpoint?

LLM documents llm openai endpoint BASE --models, which requests a models resource relative to that base. CometAPI’s public catalog reference documents /api/models instead. This guide uses that documented catalog and does not assume a /v1/models discovery contract.

Reader next step

Create the dedicated profile, verify logging is off, and register one reviewed Chat Completions model under cometapi-text. Inspect the saved mapping before sending the short prompt, then record what actually happened. Add pipelines or conversation state only after that baseline is clear.

Need the account and credential for the first check? Start with CometAPI , then return to the same small terminal procedure.