Dify says shared LLM references survive DSL export/import. For a CometAPI-backed workflow, that is a useful feature—but not yet proof that the imported app will call the intended model on your installed plugin version.
The distinction matters when a creative workflow has several text-planning steps: one turns a brief into a shot list, another writes material and lighting notes, and a third checks the brief for missing constraints. If those steps are meant to use the same model configuration, a successful import alone is a weak acceptance signal.
What the two sources establish
Dify’s 1.17.0 release notes describe reusable LLM environment variables: define provider, model, mode and parameters once, then reference that configuration from LLM nodes. The notes explicitly say those references survive DSL import/export.
CometAPI’s Dify integration guide draws a separate boundary: one provider credential does not mean one model configuration. The dedicated CometAPI plugin handles its endpoint internally, while Dify still needs selectable model entries. Capabilities and settings remain model-specific.
Together, these suggest a two-part acceptance check: preserve the shared Dify reference, then verify that it resolves to the intended CometAPI provider/model configuration. Neither document proves that combination on every Dify/plugin version.
A round-trip check before promotion
Here is a proposed test, not a report of a completed migration:
- Record the starting configuration. Note the Dify and CometAPI plugin versions. In a test workflow, use an illustrative shared configuration such as
creative_brief_textfor the shot-list and lighting-notes LLM nodes. Record its provider, exact model ID, mode and parameters, plus which nodes should reference it. Leave any deliberately different review node separate. - Export safely. Inspect the DSL for credentials before sharing it. Keep the CometAPI key in the credential store; do not put it in the export or comparison notes. Configure the destination’s provider credentials separately as needed.
- Import into a separate test app. Compare the expected node-to-configuration mapping with the imported one. Check both the shared reference and its resolved provider/model/mode/parameters. A matching display name is not enough for this test.
- Check that sharing still behaves as intended. In the disposable app, make a supported, reversible parameter change to the shared configuration. Inspect whether each intended node reflects it and whether deliberately separate nodes remain separate. Restore the original value before the route test.
- Exercise the CometAPI route. Confirm the exact model ID is available to the destination account and run a short text prompt, then the representative creative brief. Inspect Dify’s run logs for the selected model, token usage and errors. If the route fails, the official guide recommends a small request outside Dify to help separate endpoint/key/model problems from plugin or workflow configuration problems.
For promotion, I would require both the structural comparison and successful route tests. If either fails, keep the imported app in testing rather than silently replacing shared references with unrelated node settings.
This example is deliberately about text preparation for image work, not image generation. A coherent shot list does not establish vision support, tool support, or consistent rendered materials. Those need their own capability checks and evaluation inputs.
The practical question is therefore not just “did the DSL import?” It is “do the same intended nodes still share the same configuration, and does that configuration resolve to the tested CometAPI route?”