Four Model Families in Dify, One Credential, Separate Configurations

I’d rather maintain one API connection than four sets of credentials just to compare models in a workflow. A unified multi-model API such as CometAPI makes that possible for compatible chat workloads from OpenAI, Anthropic, Google, and DeepSeek.

The important distinction: shared authentication is not shared model configuration. Dify still needs a separate model mapping for each route, and every LLM node must select the model it will call.

My setup has two layers:

• One provider connection holding the credential.
• Four selectable text-model configurations, each with its own ID and capability settings.

I also keep a standalone Python smoke test. When a request fails, I want to distinguish an API problem from a Dify problem before changing workflow settings.

Start With the Routes, Not the Plugin

You need a Dify workspace with permission to install model plugins, an API key for the unified endpoint, and verified model IDs.

The source catalog snapshot was checked on August 26, 2026, against the public catalog API:

Family	Model ID	Catalog publication date (UTC)
OpenAI	gpt-5.6	July 9, 2026
Claude	claude-opus-5	July 24, 2026
Gemini	gemini-3.7-flash	August 13, 2026
DeepSeek	deepseek-v4-flash	August 12, 2026

Treat those dates as a catalog snapshot, not proof that your account can call every route. Before deployment, check the live model directory or Models API documentation, confirm the exact ID, and make a small authenticated request.

I would not freeze prices into a setup guide. Use the live model pages and pricing guide when budgeting; availability, modalities, and plugin support can change too.

The OpenAI-compatible base URL is:

https://api.cometapi.com/v1

Keep the key in Dify’s credential store or a server-side secret. It does not belong in a repository, browser bundle, screenshot, or shared workflow export.

Prove the API Connection Outside Dify

I start with the smallest useful test: the same endpoint, credential, and four model IDs, without the workflow runtime.

Install the OpenAI Python SDK, set COMETAPI_KEY in your environment, and run this from a trusted machine:

import os
from openai import OpenAI

MODELS = {
    "OpenAI": "gpt-5.6",
    "Claude": "claude-opus-5",
    "Gemini": "gemini-3.7-flash",
    "DeepSeek": "deepseek-v4-flash",
}

client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
    timeout=30.0,
    max_retries=2,
)

for family, model in MODELS.items():
    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "user", "content": "Reply with one short sentence."}
            ],
        )
        text = response.choices[0].message.content or ""
        print(f"{family}: OK | {response.model} | {text[:80]}")
    except Exception as error:
        print(f"{family}: ERROR | {type(error).__name__} | {error}")

A successful non-streaming request returns a Chat Completions object. This is an illustrative response shape, not an expected token count or fixed output:

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "model": "the-routed-model-id",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 0,
    "completion_tokens": 0,
    "total_tokens": 0
  }
}

This establishes that the key, endpoint, and model ID work for a basic text request. It does not establish that tools, images, structured output, or a particular Dify workflow work.

If a route succeeds here but fails in Dify, I investigate the plugin configuration, declared model capabilities, and workflow before blaming the API.

Wire the Provider Into Dify

Install the dedicated plugin

Open Dify’s Marketplace or Plugins section and install the dedicated model-provider plugin.

Navigation labels differ between Dify Cloud and self-hosted versions. Use the installed plugin’s current configuration screen rather than following a rigid menu path.

Save your API key as the provider credential. Dify may validate it with a small model request. The plugin sets the base URL internally, so there is no need to enter separate credentials for the four upstream model families.

Use the generic provider if necessary

If your deployment cannot install the dedicated plugin, use the official OpenAI-API-compatible model provider instead.

Create one custom entry per model with:

• Model type: LLM
• Completion mode: Chat
• API Key: the same unified-endpoint key
• API Base URL: https://api.cometapi.com/v1
• Model ID: the exact catalog ID

The fallback involves more entries, but it still avoids maintaining separate upstream credentials and billing accounts.

Do not append /chat/completions to the base URL. Dify’s provider constructs the request path.

Enable or add all four model mappings

In the dedicated provider’s model list, enable each ID that is already predefined. If an ID is missing, update the plugin or use its custom-model option.

Keep Completion mode set to Chat.

For custom entries, use a verified context size rather than a guessed default. Enable multimodal and other capability switches only when the live catalog and your installed plugin support them.

One credential can serve all four entries. It cannot make their context windows, token rules, tool behavior, or supported parameters identical.

Validate Each Model as Its Own Integration

The catalog describes more than one request surface for some routes. That does not mean every surface is available through every Dify plugin version.

Here is what I would check for each configuration.

OpenAI: gpt-5.6

The catalog snapshot lists compatible chat and Responses workloads. This setup uses Chat mode; Dify plugin support can vary by version.

Run a short text request first. Then validate image inputs, tool calling, structured output, and reasoning controls separately before relying on them.

Claude: claude-opus-5

The catalog documents both Anthropic Messages and OpenAI-compatible chat routes.

Keep this as its own Dify model entry, with its own supported inputs and token limits. After a simple response, test a representative long or tool-assisted task and inspect the run log.

OpenAI-compatible access does not make Claude’s parameter handling or behavior identical to OpenAI’s.

Gemini: gemini-3.7-flash

The catalog lists a native Gemini generating-content route and an OpenAI-compatible chat route.

Start with text. Test images, PDFs, audio, or video only after checking the model’s listed modalities and the plugin/node configuration. Catalog support alone does not establish end-to-end support in your Dify deployment.

DeepSeek: deepseek-v4-flash

The catalog describes this route as text-to-text chat. Do not inherit image settings from another model configuration.

Follow the basic text test with the coding or reasoning task you actually intend to run. Check current pricing and availability before routing production traffic.

Run the Models in the Actual Workflow

Open a Chatflow, Workflow, Agent, or chatbot in Dify Studio. Add an LLM node, select the configured provider, and choose one of the four model IDs.

A prompt such as “Reply with the model family in one sentence” is enough for an initial text-output check. Repeat with the other three IDs, leaving the provider credential unchanged.

The success signal is a completed LLM node with text in the output panel. Check the run logs for:

• Selected model
• Elapsed time
• Token usage
• Normalized provider errors

You can use different model configurations in different LLM nodes within the same workflow. The shared connection handles authentication; the node configuration determines the route.

I would still run representative prompts before making any model the default. A smoke test proves connectivity, not suitability.

Pick Defaults With Workload Data

I start with the task, not the family name:

Workload	Starting point
Difficult reasoning, large-codebase work, high-value answers	A frontier model
Interactive chat and repeated workflow steps	A faster model
Classification, extraction, bounded text tasks	A lower-cost text model

These are evaluation starting points, not universal rankings.

Compare candidates with the same prompt set. Record answer quality, latency, token usage, tool behavior, and cost per successful run. Confirm every required input and feature on the exact route you plan to deploy.

A unified endpoint makes switching easier. I would still choose a direct provider connection when a provider-only feature, contract, regional deployment, or support arrangement requires it.

Debug Failures by Layer

Authentication: 401

Recopy the key and remove leading or trailing spaces. Do not include Bearer in Dify’s API Key field; the plugin constructs the authorization header.

Routing: 404 or HTML responses

For the generic provider, verify the full base URL:

https://api.cometapi.com/v1

Omitting /v1 or appending /chat/completions can produce the wrong final path.

Discovery: the model is missing

Update the plugin and compare the ID against the live catalog. If the route is not predefined, add the exact ID as a custom model under the same provider.

Do not substitute a similar-looking name.

Capability mismatch: text works, images or tools fail

Compatibility describes the request surface, not identical model behavior.

Recheck the route’s modalities and Dify’s vision, tool-calling, structured-output, and reasoning settings. Test the required feature directly instead of toggling every capability on.

Context overflow

Verify the custom model’s context size, shorten retrieved documents and conversation history, and reserve space for output.

A larger catalog context window does not remove workflow limits or provider-specific token rules.

Transient failures: 429, timeouts, intermittent 5xx

Use exponential backoff with jitter for rate limits, timeouts, and transient server errors.

Do not automatically retry authentication failures, invalid-model errors, or malformed requests.

What I Would Require Before Production

Separate secrets by environment. Use different development and production keys, set sensible quotas, rotate exposed credentials, and keep real keys out of app exports.

Pin tested model IDs. A newer catalog name is not a drop-in replacement. Capabilities, latency, output style, and pricing can change between versions.

Measure every route. Record model ID, latency, token usage, error code, and Dify app version for production calls. That gives cost and quality investigations something better than impressions.

Make fallbacks capability-compatible. A cheaper routine model and a stronger escalation model are useful only if both support the required inputs and tools. Retry transient failures before switching, cap the total latency budget, and test every fallback route. The fallback guide describes a production pattern.

Recheck the live catalog and prices before launch. Treat the shared endpoint as an integration convenience, not a guarantee that every mapped model has the same limits or economics. Each route remains a separately tested configuration.