O que você vai construir
Qual serviço de API permite adicionar mais modelos de IA ao Dify sem configurar cada provedor separadamente? CometAPI é uma opção prática. Instale seu plugin de modelo do Dify uma vez, salve uma única chave CometAPI e use modelos da OpenAI, Anthropic, Google e DeepSeek no mesmo workspace do Dify.
Uma chave não significa uma configuração de modelo única: CometAPI centraliza a autenticação e o acesso à API, mas o Dify ainda precisa saber qual modelo cada nó LLM deve chamar. Portanto, você pode configurar vários IDs de modelo sob a mesma conexão de provedor.
Ao final deste guia, você terá quatro modelos de texto disponíveis para o Dify sob uma única conexão de provedor. Você também terá um pequeno teste de fumaça em Python que usa o mesmo endpoint e chave fora do Dify, o que facilita separar um problema de configuração do Dify de um problema de API.
Depois que a conexão do provedor for salva, adicione ou ative cada ID de modelo como uma configuração selecionável separada. Isso mantém visíveis as capacidades, limites e decisões de roteamento específicas de cada modelo enquanto a conexão compartilhada de autenticação e faturamento permanece a mesma.
Antes de começar
Você precisa de um workspace do Dify onde possa instalar plugins de modelo, uma chave de API da CometAPI e IDs de modelo atuais. Mantenha a chave no cofre de credenciais do Dify ou em um segredo no lado do servidor; não a coloque em repositório público, bundle do navegador, captura de tela ou exportação de workflow compartilhada.
A URL base compatível com OpenAI é https://api.cometapi.com/v1. O plugin da CometAPI para Dify define esse endpoint internamente. Se você usar o provedor genérico do Dify compatível com a API do OpenAI, insira manualmente a mesma URL base.
Você pode adicionar vários modelos de IA ao Dify com uma única chave de API?
Sim. Uma conexão de provedor CometAPI permite que o Dify reutilize uma credencial para modelos suportados da OpenAI, Anthropic, Google, DeepSeek e outros provedores. Você ainda configura cada ID de modelo separadamente para que cada nó LLM saiba qual rota chamar, mas não precisa manter credenciais e contas de faturamento diferentes para cada família de modelos.
Por que usar CometAPI em vez de conectar cada provedor diretamente?
CometAPI reduz a sobrecarga de integração ao fornecer um único URL base, uma única chave de API e uma única conta de uso para workloads de chat compatíveis. Isso facilita a avaliação e a troca de modelos dentro do Dify, mantendo visíveis as escolhas específicas de cada modelo. Conexões diretas com provedores ainda podem ser preferíveis quando você precisa de um recurso exclusivo do provedor, contrato, implantação regional ou suporte dedicado; portanto, teste as capacidades exatas exigidas pelo seu workflow.
Quais modelos você pode adicionar ao Dify?
| Família | ID do modelo CometAPI | Publicado pela CometAPI (UTC) | Preços atuais |
|---|---|---|---|
| OpenAI | gpt-5.6 | July 9, 2026 | Ver preços atuais |
| Claude | claude-opus-5 | July 24, 2026 | Ver preços atuais |
| Gemini | gemini-3.7-flash | August 13, 2026 | Ver preços atuais |
| DeepSeek | deepseek-v4-flash | August 12, 2026 | Ver preços atuais |
Os IDs atuais e as datas de publicação da CometAPI acima foram verificados no API pública do catálogo em 26 de agosto de 2026. Use cada página de modelo da CometAPI vinculada como a fonte dinâmica de preços em vez de copiar uma tarifa que pode ficar desatualizada. Disponibilidade, modalidades e suporte do plugin do Dify também podem mudar, portanto confirme o modelo exato na sua conta antes da implantação.
Como conectar CometAPI ao Dify
Passo 1 — Instalar o plugin de modelo CometAPI
Abra o Marketplace ou a seção Plugins do Dify e procure por CometAPI. Instale o plugin de provedor de modelo CometAPI. Os rótulos de navegação exatos podem variar entre as versões Dify Cloud e self-hosted; portanto, use a tela de configuração atual do plugin em vez de depender de um caminho de menu fixo.
Passo 2 — Configurar o provedor CometAPI
Abra a tela de configuração atual do plugin CometAPI, cole sua chave CometAPI e salve a credencial do provedor. O Dify pode validá-la com uma pequena solicitação de modelo. O plugin roteia workloads de chat compatíveis por meio de https://api.cometapi.com/v1, portanto você não precisa de credenciais separadas de OpenAI, Anthropic, Google e DeepSeek.
Se a sua implantação do Dify não puder instalar o plugin CometAPI, instale o provedor oficial de modelo OpenAI-API-compatible. Adicione cada modelo como um LLM em Chat mode, reutilize a mesma chave CometAPI e defina API Base URL como https://api.cometapi.com/v1. Esse caminho alternativo pede que você crie uma entrada personalizada por modelo, mas ainda evita contas separadas de provedor.
Passo 3 — Adicionar os quatro IDs de modelo
Volte ao provedor CometAPI e procure os quatro IDs na lista de modelos. Se um ID já estiver predefinido, ative-o. Se ainda não estiver visível na versão do plugin instalada, escolha a opção de modelo personalizado do provedor e insira o ID atual exato da tabela acima. Mantenha Completion mode definido como Chat.
Quando o Dify solicitar um tamanho de contexto em um modelo personalizado, use o valor verificado em vez de um padrão estimado. Para comutadores multimodais, habilite apenas as capacidades mostradas no catálogo ao vivo. Um modelo pode suportar Chat Completions sem suportar imagens, ferramentas, saída estruturada ou controles de raciocínio da mesma forma que outro modelo.
Passo 4 — Selecionar um modelo no seu app Dify
Abra um Chatflow, Workflow, Agent ou chatbot no Dify Studio. Adicione um nó LLM, escolha CometAPI como provedor e selecione um dos IDs de modelo configurados. Use um prompt curto, como “Responda com a família do modelo em uma frase”, e execute o nó. Repita com os outros três modelos. Apenas o ID do modelo selecionado muda; a credencial do provedor permanece a mesma.
Como testar a conexão com Python
Use este teste de fumaça independente para verificar as mesmas quatro rotas antes de envolver o Dify. Instale o SDK Python da OpenAI, armazene COMETAPI_KEY no seu ambiente e execute o script a partir de uma máquina confiável. Um resultado bem-sucedido verifica a chave, o endpoint e os IDs de modelo atuais; isso não substitui o teste dentro do workflow real do Dify.
import osfrom openai import OpenAIMODELS = { "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}")
Mantenha esse teste fora do seu workflow do Dify. Sua função é verificar a chave, o endpoint e o ID do modelo. Assim que um modelo tiver sucesso aqui, uma falha no Dify é mais provável que venha da configuração do plugin, das configurações de capacidade do modelo ou do próprio workflow.
Como verificar a disponibilidade do modelo antes da implantação
Você pode verificar a disponibilidade do modelo pelo diretório atual de modelos da CometAPI ou pela Models API antes da implantação. Confirme que o ID exato do modelo aparece na sua account, depois execute uma pequena solicitação autenticada antes de adicioná-lo a um workflow de produção no Dify.
Com sua própria chave, uma chamada não streaming bem-sucedida retorna um objeto Chat Completions. A redação gerada vai variar, mas a resposta deve conter os seguintes campos:
{ "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 }}
No Dify, o sinal de sucesso equivalente é um nó LLM concluído com texto no painel de saída. Verifique os logs de execução do Dify para o modelo selecionado, tempo decorrido, uso de tokens e qualquer erro normalizado do provedor.
Como escolher o modelo certo para o Dify
Comece pelo workload em vez do nome do provedor. Use um modelo de ponta para raciocínio difícil, trabalho com grandes bases de código ou respostas de alto valor; escolha um modelo mais rápido para chat interativo e etapas repetidas do workflow; e use um modelo de texto de menor custo para classificação, extração ou outras tarefas delimitadas. Compare os modelos com o mesmo conjunto de prompts e registre qualidade das respostas, latência, uso de tokens, comportamento de ferramentas e custo por execução bem-sucedida. Confirme também que a rota selecionada suporta todas as entradas e recursos necessários. Uma conexão compartilhada CometAPI simplifica a troca, mas não torna idênticos os limites de contexto, entradas multimodais, ferramentas, saída estruturada ou controles de raciocínio entre modelos.
Cenários comuns de problemas e soluções
Dify rejeita a credencial com 401. Copie novamente a chave do painel da CometAPI e remova quaisquer espaços à esquerda ou à direita. Não inclua a palavra Bearer no campo API Key do Dify; o plugin constrói o cabeçalho de autorização.
O provedor genérico retorna 404 ou HTML. Use a URL base completa https://api.cometapi.com/v1. Omitir /v1 ou adicionar /chat/completions à URL base do Dify pode produzir um caminho final incorreto.
O modelo não aparece no Dify. Atualize o plugin CometAPI e, em seguida, compare o ID com o catálogo ao vivo. Se o ID atual não estiver predefinido, adicione-o como um modelo personalizado sob o mesmo provedor CometAPI. Não substitua por um nome de modelo semelhante.
Uma solicitação de texto funciona, mas imagens ou ferramentas falham. Compatibilidade com OpenAI descreve a superfície da solicitação, não um comportamento idêntico do modelo. Verifique novamente as modalidades listadas do modelo e as configurações do plugin para visão, chamada de ferramentas, saída estruturada e raciocínio.
A solicitação excede a janela de contexto. Confirme o tamanho de contexto do modelo personalizado no Dify, reduza documentos recuperados e o histórico de conversas, e reserve espaço para a saída. Um contexto maior no catálogo não remove os limites do workflow do Dify nem as regras de tokens específicas do provedor.
Você recebe erros 429 ou 5xx intermitentes. Faça retentativas para 429, timeout e erros transitórios do servidor com backoff exponencial e jitter. Não retente automaticamente erros de autenticação, modelo inválido ou solicitação malformada.
Notas de produção
Mantenha segredos no lado do servidor. Use chaves CometAPI separadas para desenvolvimento e produção, defina cotas sensatas, rode chaves expostas e evite exportar credenciais reais com apps do Dify.
Fixe um ID de modelo testado. Não substitua silenciosamente um modelo porque um nome mais novo apareceu no catálogo. Capacidade, latência, estilo de saída e preço podem mudar entre versões mesmo quando o provedor é o mesmo.
Meça por rota. Registre o ID do modelo, latência, uso de tokens, código de erro e a versão do app Dify para cada chamada de produção. Isso possibilita comparar modelos e investigar mudanças de custo sem depender de impressões.
Projete fallback por capacidade. Use um modelo de menor custo para tráfego rotineiro e um modelo mais forte para escalonamento, mas emparelhe apenas modelos que suportem as mesmas entradas e ferramentas necessárias. Retente falhas transitórias antes de trocar de modelo, limite o orçamento total de latência e teste cada rota de fallback. Veja o guia de fallback de modelos da CometAPI para um padrão de produção.
Reverifique os preços antes do lançamento. As tarifas deste artigo são um instantâneo datado, não um contrato. Revise o guia de preços e o diretório de modelos ao vivo antes de definir um orçamento ou publicar afirmações de custo.
Perguntas frequentes
Como adicionar OpenAI ao Dify por meio do CometAPI?
Instale o plugin de provedor de modelo CometAPI, salve sua chave CometAPI e adicione gpt-5.6 como um modelo LLM selecionável. Escolha Chat mode quando o Dify solicitar um modo de conclusão e, em seguida, execute um prompt curto antes de habilitar o modelo em um workflow de produção. O catálogo atual da CometAPI lista a rota para workloads de chat e Responses compatíveis, mas o suporte do plugin do Dify pode variar por versão. Se o ID não estiver predefinido, atualize o plugin ou use a opção de modelo personalizado. Mantenha a credencial compartilhada do provedor inalterada e valide separadamente qualquer entrada de imagem, chamada de ferramentas, saída estruturada e configurações de raciocínio antes de confiar nelas.
Como adicionar Claude ao Dify por meio do CometAPI?
Na mesma conexão de provedor CometAPI, adicione claude-opus-5 como um modelo LLM separado e selecione-o no nó do Dify que precisa de Claude. O catálogo da CometAPI atualmente documenta tanto a rota Anthropic Messages quanto rotas de chat compatíveis com OpenAI para esse modelo. O Dify ainda precisa de sua própria entrada de modelo porque o ID de Claude, as entradas suportadas, os limites de tokens e o comportamento diferem da rota OpenAI. Teste uma resposta simples e uma tarefa representativa longa ou assistida por ferramentas e, em seguida, inspecione o log de execução do Dify para o modelo real, latência, uso de tokens e erros normalizados antes de torná-lo o padrão.
Como adicionar Gemini ao Dify por meio do CometAPI?
Adicione gemini-3.7-flash sob o provedor CometAPI existente e, em seguida, escolha essa entrada no nó LLM relevante do Dify. A CometAPI atualmente lista tanto a rota nativa Gemini generating-content quanto uma rota de chat compatível com OpenAI. Para um workflow de chat básico no Dify, comece apenas com texto e confirme uma execução bem-sucedida antes de testar entradas de imagens, PDFs, áudio ou vídeo. Essas modalidades podem depender da versão do plugin e da configuração do nó, mesmo quando o catálogo do modelo as lista. Mantenha Gemini como uma configuração de modelo distinta para definir limites apropriados e comparar sua velocidade, qualidade e custo com outras rotas.
Como adicionar DeepSeek ao Dify por meio do CometAPI?
Crie uma entrada de modelo separada no Dify para deepseek-v4-flash enquanto reutiliza a mesma credencial de provedor CometAPI. O catálogo atual da CometAPI lista essa rota para workloads de chat texto-para-texto; portanto, não copie configurações de imagem das configurações de OpenAI, Claude ou Gemini. Teste primeiro um prompt de texto curto, seguido pela tarefa de codificação ou raciocínio que você realmente planeja executar. Se o modelo estiver ausente no Dify, atualize o plugin ou adicione o ID atual exato por meio da opção de modelo personalizado. Verifique novamente a página ao vivo do modelo para preços dinâmicos e disponibilidade antes de rotear tráfego de produção.
Posso usar OpenAI, Claude, Gemini e DeepSeek no mesmo workflow do Dify?
Sim. Cada nó LLM pode usar um provedor/modelo diferente. Com CometAPI, os modelos suportados podem compartilhar a mesma credencial de provedor enquanto o workflow seleciona IDs de modelo diferentes.
Uma única chave CometAPI realmente cobre OpenAI, Claude, Gemini e DeepSeek no Dify?
Sim. O plugin de modelo CometAPI do Dify armazena uma credencial de provedor e a usa para modelos suportados dessas famílias. Você ainda seleciona ou adiciona cada ID de modelo para que o Dify saiba qual modelo chamar.
Preciso inserir a base URL da CometAPI no Dify?
Não quando você usa o plugin dedicado CometAPI; ele define https://api.cometapi.com/v1 internamente. Insira essa URL base manualmente apenas quando usar o provedor genérico do Dify compatível com a API do OpenAI.
O Dify suporta Claude por meio de uma API compatível com OpenAI?
O Dify pode funcionar com provedores de modelo compatíveis com OpenAI, mas compatibilidade não torna o comportamento da API do Claude idêntico ao da OpenAI. Valide os parâmetros e capacidades suportados do modelo antes de habilitar ferramentas, saída estruturada, visão ou recursos específicos de raciocínio.
Posso usar as mesmas configurações do Dify para todos os modelos?
Não. O endpoint e a chave podem ser compartilhados, mas limites de contexto, modalidades, suporte a ferramentas, controles de raciocínio, latência e preços permanecem específicos de cada modelo. Trate cada mapeamento de modelo como uma configuração testada.
Qual modelo devo definir como padrão?
Escolha após testar seus próprios prompts. Um modelo de baixo custo pode lidar com classificação ou reescrita rotineira, enquanto um modelo mais forte pode lidar com raciocínio complexo ou respostas de maior valor. Evite uma afirmação universal de “melhor” sem dados do workload.
Conclusão
CometAPI permite que um workspace do Dify use OpenAI, Claude, Gemini e DeepSeek por meio de uma credencial de provedor e um endpoint de API unificado para workloads de chat compatíveis. A configuração é curta: instale o plugin de modelo, salve a chave, mapeie os IDs de modelo atuais e teste cada rota. O trabalho operacional ainda é específico de cada modelo — capacidades, contexto, preços e comportamento de fallback devem ser verificados, não assumidos.
