Suppose you have tested a Claude LLM entry through CometAPI in one Dify workflow and want to make it the workspace default. Which other apps might change with it?
Start with model selection, not node names. Dify’s Model Providers documentation says apps and nodes that do not pick a model fall back to workspace defaults. It lists separate defaults for System Reasoning, Embedding, Rerank, Speech-to-Text and Text-to-Speech. A successful LLM test is therefore not a reason to change every default.
That rule identifies what to inspect; it does not give a version-independent list of affected node types or establish when already-saved or published apps resolve a changed default.
Identify which apps and nodes inherit the affected default
Before changing System Reasoning, make a small inventory of the workflows you intend to keep working. For each relevant app or node, record:
- its job: reasoning, embedding, reranking or speech;
- whether it has an explicit model selection or appears to rely on a workspace default;
- its current effective provider and model, where observable;
- a representative input and the output behavior it must preserve.
For example, an explicitly selected LLM and an LLM with no selection belong in different test cases. A passing run of the explicitly selected entry does not demonstrate what the inheriting case will use after promotion. If the configuration is unclear, mark it unresolved rather than assuming inheritance.
Validate the candidate route before changing defaults
The official CometAPI Dify guide recommends creating Claude as its own LLM entry, testing a simple response and a representative long or tool-assisted task, then inspecting the actual model, latency, tokens and normalized errors before making it the default. The linked guide is in Traditional Chinese; this is an English paraphrase of its test sequence, not a report of a completed integration.
Apply that sequence to the specific CometAPI entry you intend to promote:
- Verify the installed Dify provider plugin and available model entry. Do not assume an example model identifier or tool capability applies to your installation.
- Select that entry explicitly in a representative test workflow. Run the simple-response check, then the longer or tool-assisted case your application needs.
- Record the actual model and the latency, token-use and error observations. Decide whether the results meet your application’s requirements before involving default-dependent apps.
This separates two questions: “Does this CometAPI route handle the required task?” and “Which Dify configurations will resolve to it?” Neither answer substitutes for the other.
Stage the CometAPI default change by job
My recommended rollout is to record the previous System Reasoning default, then promote only the tested CometAPI LLM entry. Leave embedding, rerank and speech defaults unchanged unless they have their own evaluation.
Next, rerun the inventoried default-dependent cases in your target Dify version and check the effective model wherever it is observable. Keep explicitly configured cases as comparison checks, not proof of inheritance. If a required case fails or the effective route cannot be established, pause broader adoption. Restore the recorded default if needed, then rerun the affected cases; changing the setting back is not by itself proof that behavior has recovered.
This is a proposed rollout procedure, not a documented automatic rollback feature. The sources establish the fallback rule and the CometAPI pre-promotion checks, but do not prove runtime compatibility, model availability, savings, or saved-app resolution timing in your environment.
The useful promotion checkpoint is not simply “Claude responded.” It is “the intended CometAPI entry passed the required task checks, and the apps relying on the affected Dify default have been identified and verified.”