How to Add OpenAI, Claude, Gemini, and DeepSeek to Dify

What You Will Build

Which API service lets you add more AI models to Dify without setting up each provider separately? CometAPI is one practical option. Install its Dify model plugin once, save one CometAPI key, and use models from OpenAI, Anthropic, Google, and DeepSeek in the same Dify workspace.

One Key Does Not Mean One Model Configuration: CometAPI centralizes authentication and API access, but Dify still needs to know which model each LLM node should call. You may therefore configure multiple model IDs under the same provider connection.

By the end of this guide, you will have four text models available to Dify under one provider connection. You will also have a small Python smoke test that uses the same endpoint and key outside Dify, which makes it easier to separate a Dify configuration problem from an API problem.

After the provider connection is saved, add or enable each model ID as a separate selectable configuration. This keeps model-specific capabilities, limits, and routing decisions visible while the authentication and billing connection remains shared.

Before You Start

You need a Dify workspace where you can install model plugins, a CometAPI API key, and current model IDs. Keep the key in Dify's credential store or a server-side secret; do not place it in a public repository, browser bundle, screenshot, or shared workflow export.

The OpenAI-compatible base URL is https://api.cometapi.com/v1. The CometAPI Dify plugin sets this endpoint internally. If you use Dify's generic OpenAI-API-compatible provider instead, enter the same base URL manually.

Can You Add Multiple AI Models to Dify With One API Key?

Yes. A CometAPI provider connection lets Dify reuse one credential for supported models from OpenAI, Anthropic, Google, DeepSeek, and other providers. You still configure each model ID separately so every LLM node knows which route to call, but you do not need to maintain a different upstream credential and billing account for every model family.

Why Use CometAPI Instead of Connecting Each Provider Directly?

CometAPI reduces integration overhead by giving compatible chat workloads one base URL, one API key, and one usage account. That makes model evaluation and switching easier inside Dify while keeping model-specific choices visible. Direct provider connections may still be preferable when you need a provider-only feature, contract, regional deployment, or support arrangement, so test the exact model capabilities required by your workflow.

Which Models Can You Add to Dify?

The current IDs and CometAPI publication dates above were checked against the public catalog API on August 26, 2026. Use each linked CometAPI model page as the dynamic pricing source rather than copying a rate that may become stale. Availability, modalities, and Dify plugin support can also change, so confirm the exact model in your account before deployment.

How to Connect CometAPI to Dify

Step 1 — Install the CometAPI model plugin

Open Dify's Marketplace or Plugins section and search for CometAPI. Install the CometAPI model provider plugin. The exact navigation labels can vary between Dify Cloud and self-hosted versions, so use the plugin's current configuration screen rather than relying on a fixed menu path.

Step 2 — Configure the CometAPI provider

Open the CometAPI plugin's current configuration screen, paste your CometAPI key, and save the provider credential. Dify may validate it with a small model request. The plugin routes compatible chat workloads through https://api.cometapi.com/v1, so you do not need separate OpenAI, Anthropic, Google, and DeepSeek credentials.

If your Dify deployment cannot install the CometAPI plugin, install the official OpenAI-API-compatible model provider instead. Add each model as an LLM in Chat mode, reuse the same CometAPI key, and set API Base URL to https://api.cometapi.com/v1. This fallback path asks you to create one custom entry per model, but it still avoids separate provider accounts.

Step 3 — Add the four model IDs

Return to the CometAPI provider and look for the four IDs in the model list. If an ID is already predefined, enable it. If it is not yet visible in your installed plugin version, choose the provider's custom-model option and enter the exact current ID from the table above. Keep Completion mode set to Chat.

When Dify asks for a context size on a custom model, use the checked value rather than a guessed default. For multimodal switches, enable only the capabilities shown in the live catalog. A model can support Chat Completions without supporting images, tools, structured output, or reasoning controls in the same way as another model.

Step 4 — Select a model in your Dify app

Open a Chatflow, Workflow, Agent, or chatbot in Dify Studio. Add an LLM node, choose CometAPI as the provider, and select one of the configured model IDs. Use a short prompt such as “Reply with the model family in one sentence,” then run the node. Repeat with the other three models. Only the selected model ID changes; the provider credential stays the same.

How to Test the Connection With Python

Use this standalone smoke test to check the same four routes before involving Dify. Install the OpenAI Python SDK, store COMETAPI_KEY in your environment, and run the script from a trusted machine. A successful result verifies the key, endpoint, and current model IDs; it does not replace testing inside the actual Dify workflow.

import osfrom 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}")

Keep this test outside your Dify workflow. Its job is to verify the key, endpoint, and model ID. Once a model succeeds here, a Dify failure is more likely to come from plugin configuration, model capability settings, or the workflow itself.

How to Verify Model Availability Before Deployment

You can verify model availability through the current CometAPI model directory or Models API before deployment. Confirm that the exact model ID appears in your account, then run a small authenticated request before adding it to a Dify production workflow.

With your own key, a successful non-streaming call returns a Chat Completions object. The generated wording will vary, but the response should contain the following fields:

{  "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  }}

In Dify, the equivalent success signal is a completed LLM node with text in the output panel. Check Dify's run logs for the selected model, elapsed time, token usage, and any normalized provider error.

How to Choose the Right Model for Dify

Start with the workload rather than the provider name. Use a frontier model for difficult reasoning, large-codebase work, or high-value answers; choose a faster model for interactive chat and repeated workflow steps; and use a lower-cost text model for classification, extraction, or other bounded tasks. Compare models with the same prompt set and record answer quality, latency, token usage, tool behavior, and cost per successful run. Also confirm that the selected route supports every required input and feature. A shared CometAPI connection simplifies switching, but it does not make context limits, multimodal inputs, tools, structured output, or reasoning controls identical across models.

Common Troubleshooting Scenarios & Solutions

Dify rejects the credential with 401. Recopy the key from the CometAPI dashboard and remove any leading or trailing spaces. Do not include the word Bearer in Dify's API Key field; the plugin builds the authorization header.

The generic provider returns 404 or HTML. Use the full base URL https://api.cometapi.com/v1. Omitting /v1 or adding /chat/completions to Dify's base URL can produce a wrong final path.

The model does not appear in Dify. Update the CometAPI plugin, then compare the ID with the live catalog. If the current ID is not predefined, add it as a custom model under the same CometAPI provider. Do not substitute a similar-looking model name.

A text request works but images or tools fail. OpenAI compatibility describes the request surface, not identical model behavior. Recheck the model's listed modalities and the plugin's vision, tool-calling, structured-output, and reasoning settings.

The request exceeds the context window. Confirm the custom model's context size in Dify, shorten retrieved documents and conversation history, and reserve room for the output. A larger catalog context does not remove Dify workflow limits or provider-specific token rules.

You receive 429 or intermittent 5xx errors. Retry 429, timeout, and transient server errors with exponential backoff and jitter. Do not automatically retry authentication, invalid-model, or malformed-request errors.

Production Notes

Keep secrets server-side. Use separate CometAPI keys for development and production, set sensible quotas, rotate exposed keys, and avoid exporting real credentials with Dify apps.

Pin a tested model ID. Do not silently replace a model because a newer name appears in the catalog. Capability, latency, output style, and price can change across versions even when the provider is the same.

Measure per route. Record the model ID, latency, token usage, error code, and Dify app version for every production call. This makes it possible to compare models and investigate cost changes without relying on impressions.

Design fallback by capability. Use a lower-cost model for routine traffic and a stronger model for escalation, but only pair models that support the same inputs and required tools. Retry transient failures before switching models, cap the total latency budget, and test every fallback route. See CometAPI's model fallback guide for a production pattern.

Recheck prices before launch. The rates in this article are a dated snapshot, not a contract. Review the pricing guide and live model directory before setting a budget or publishing cost claims.

FAQs

How Do You Add OpenAI to Dify Through CometAPI?

Install the CometAPI model provider plugin, save your CometAPI key, and add gpt-5.6 as a selectable LLM model. Choose Chat mode when Dify requests a completion mode, then run a short text prompt before enabling the model in a production workflow. The current CometAPI catalog lists the route for compatible chat and Responses workloads, but Dify plugin support can vary by version. If the ID is not predefined, update the plugin or use its custom-model option. Keep the shared provider credential unchanged and validate any image input, tool calling, structured output, and reasoning settings separately before relying on them.

How Do You Add Claude to Dify Through CometAPI?

Under the same CometAPI provider connection, add claude-opus-5 as a separate LLM model and select it in the Dify node that needs Claude. The CometAPI catalog currently documents both Anthropic Messages and OpenAI-compatible chat routes for this model. Dify still needs its own model entry because the Claude ID, supported inputs, token limits, and behavior differ from the OpenAI route. Test one simple response and one representative long or tool-assisted task, then inspect the Dify run log for the actual model, latency, token usage, and normalized errors before making it the default.

How Do You Add Gemini to Dify Through CometAPI?

Add gemini-3.7-flash under the existing CometAPI provider, then choose that entry in the relevant Dify LLM node. CometAPI currently lists both the native Gemini generating-content route and an OpenAI-compatible chat route. For a basic Dify chat workflow, begin with text only and confirm a successful run before testing images, PDFs, audio, or video inputs. Those modalities may depend on the plugin version and node configuration even when the model catalog lists them. Keep Gemini as a distinct model configuration so you can set appropriate limits and compare its speed, quality, and cost with the other routes.

How Do You Add DeepSeek to Dify Through CometAPI?

Create a separate Dify model entry for deepseek-v4-flash while reusing the same CometAPI provider credential. The current CometAPI catalog lists this route for text-to-text chat workloads, so do not copy image settings from the OpenAI, Claude, or Gemini configurations. Test a short text prompt first, followed by the coding or reasoning task you actually plan to run. If the model is missing from Dify, update the plugin or add the exact current ID through the custom-model option. Recheck the live model page for dynamic pricing and availability before routing production traffic.

Can I use OpenAI, Claude, Gemini, and DeepSeek in the same Dify workflow?

Yes. Each LLM node can use a different model provider/model configuration. With CometAPI, supported models can share the same provider credential while the workflow selects different model IDs.

Can one CometAPI key really cover OpenAI, Claude, Gemini, and DeepSeek in Dify?

Yes. The Dify CometAPI model plugin stores one provider credential and uses it for supported models across those families. You still select or add each model ID so Dify knows which model to call.

Do I need to enter the CometAPI base URL in Dify?

Not when you use the dedicated CometAPI plugin; it sets https://api.cometapi.com/v1 internally. Enter that base URL manually only when you use Dify's generic OpenAI-API-compatible model provider.

Does Dify support Claude through an OpenAI-compatible API?

Dify can work with OpenAI-compatible model providers, but compatibility does not make Claude's API behavior identical to OpenAI's. Validate the model's supported parameters and capabilities before enabling tools, structured output, vision, or reasoning-specific features.

Can I use the same Dify settings for every model?

No. The endpoint and key can be shared, but context limits, modalities, tool support, reasoning controls, latency, and prices remain model-specific. Treat each model mapping as a tested configuration.

Which model should I make the default?

Choose after testing your own prompts. A low-cost model can handle routine classification or rewriting, while a stronger model can handle complex reasoning or higher-value responses. Avoid a universal “best” claim without workload data.

Conclusion

CometAPI lets a Dify workspace use OpenAI, Claude, Gemini, and DeepSeek through one provider credential and one unified API endpoint for compatible chat workloads. The setup is short: install the model plugin, save the key, map current model IDs, and test each route. The operational work is still model-specific—capabilities, context, pricing, and fallback behavior should be verified rather than assumed.