Why does Dify still need separate model entries with one CometAPI key?

General
1

One CometAPI key is a shared connection, not a universal model configuration. In Dify, the credential and the model entry answer different questions: which provider connection to use, and which configured model the LLM node should call.

CometAPI’s Dify guide makes that distinction in its opening explanation and setup steps 2–4. Supported models can reuse the CometAPI connection, but the node still needs a selected model ID. Adding another model therefore does not mean replacing the shared key; it means configuring and checking another entry under that provider.

Configure the entry, then select it in the node

The guide describes this path:

  1. Use the configured CometAPI provider connection in Dify.
  2. Enable the model’s predefined ID, or use the provider’s custom-model option to add its exact current ID. Do not treat a model’s display name as a substitute for checking the ID.
  3. Keep completion mode at Chat, following the guide’s custom-model instructions. Check the context value rather than guessing it.
  4. Select that configured entry in the Dify LLM node and test it, keeping the shared credential unchanged.

Predefined entries and UI labels can vary with the installed plugin version. The guide is not proof that every example model ID is currently available to a particular account, so confirm the intended ID before building a workflow around it.

Shared authentication does not mean shared capabilities

CometAPI’s guide also cautions against treating model settings as interchangeable. Context limits, supported modalities, tool support, structured output and reasoning controls can differ. A Chat interface is not evidence that two models support the same workflow features.

That is why “another model works with this CometAPI key” is not enough to accept a new Dify model entry. It is useful information about the working entry, not a test of the new entry’s limits or behavior.

A per-entry acceptance check

My recommendation is to treat each model entry on the shared CometAPI connection as a separate acceptance-test target:

  • Confirm configuration: record the exact selected model ID and check its required capabilities and limits.
  • Check the basic path: run a minimal text prompt through the intended Dify node.
  • Check the actual task: run a representative input that exercises the features the workflow needs. A plain-text response alone cannot validate a tool-dependent or structured-output task.
  • Keep a small comparison record: capture the selected model, latency, token usage and normalized error details for each test, without recording the credential.

Stop rollout for that entry if its ID, limits or a required feature remain unverified. Do not use a successful sibling entry as a substitute for acceptance evidence, or assume a failed node identifies the cause by itself.

This checklist is an operational recommendation, not a report of integration tests performed here. The source is CometAPI’s September 1, 2026 guide, checked in the accepted source record on September 7; it documents configuration guidance, not measured reliability. The practical boundary is simple: reuse the CometAPI connection, but validate each Dify model entry separately.

2

The economic comparison should also stay at the model-entry level. A shared CometAPI credential is not a useful unit for deciding which Dify node configuration is cheaper for a particular task.

I would extend the acceptance record with cost per accepted task, rather than rank entries by token price alone:

  • Use the same representative inputs and an explicit acceptance rule for each entry—for example, a valid structured response with the required fields and correct task content.
  • Count the attributable billed cost of all attempts, including retries or fallback calls if the workflow uses them, then divide by the number of accepted tasks. Report failures separately; if nothing passes, the ratio is undefined, not zero.
  • Record end-to-end latency alongside that ratio, including any retry or fallback time. Only compare entries that meet the task’s quality and latency requirements.

Keep the model ID, configuration and pricing date with the result, and use applicable billing evidence rather than assuming token usage alone captures every charge. This is a proposed measurement method, not a claim about current prices or tested savings. An entry with a lower token rate can still be the more expensive route to an acceptable result; the shared connection does not resolve that tradeoff.