Rode apps do Dify em um endpoint compatível com OpenAI-API.

Resposta rápida: instale o provedor, adicione modelos por id.

No Dify, abra Settings e vá para Model Provider. Desde o Dify 1.0, provedores são plugins: encontre OpenAI-API-compatible (publicado por langgenius) na lista ou instale-o pelo Marketplace, depois clique em Add Model no card dele. O diálogo é por modelo: escolha o Model Type (LLM para modelos de chat), digite o id exato do catálogo em Model Name, cole sua chave em API Key, e defina API Base URL como https://api.apisrouter.com/v1. Deixe Completion mode em Chat, depois defina Model context size e Upper bound for max tokens para os limites documentados do id que você está adicionando. Salve, e o modelo aparece na lista do provedor, selecionável a partir do dropdown de modelo de todo app. Repita o diálogo para cada id que você quiser; dois minutos por modelo, uma vez.

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

Como o Dify fala com um provedor compatível.

O Dify (langgenius no GitHub, cerca de 149 mil estrelas) é a principal plataforma de apps de LLM open-source: workflows visuais, nós de agente, pipelines de RAG sobre bases de conhecimento, e apps publicados com seus próprios endpoints de API. Todo nó de LLM nessa stack se resolve para um modelo registrado sob algum provedor. O provedor OpenAI-API-compatible é deliberadamente genérico. Cada modelo que você adiciona é um registro autocontido, id, endpoint, chave, limites, e o Dify envia requisições padrão de chat-completions para a base url configurada com seu Model Name como a string do modelo. Nada na requisição se importa com qual fornecedor treinou o modelo, então claude-sonnet-4-6 e deepseek-v4-pro são tão válidos aqui quanto qualquer id GPT, e modelos diferentes podem até apontar para endpoints diferentes se você algum dia precisar disso. O registro por modelo que parece fricção também é a superfície de controle: os valores de tamanho de contexto e max-tokens que você digita são o que o orquestrador do Dify usa para orçar prompts, cortar histórico de conversa, e validar configurações de nó. Digite números honestos da documentação do modelo. Superestimar o contexto produz requisições que o endpoint rejeita; subestimá-lo trunca silenciosamente o contexto que seus nós de RAG trabalharam para recuperar.

Os campos que fazem trabalho de verdade.

Model Name é o valor de fio: precisa corresponder à listagem /v1/models do gateway caractere por caractere, já que viaja em toda requisição. O nome de exibição opcional do modelo só relabela a UI. Completion mode deve ficar em Chat para todo modelo no catálogo atual; a opção Completion existe para endpoints legados de conclusão de texto e produz requisições malformadas contra modelos de chat. Model context size e Upper bound for max tokens são o par que as pessoas apressam. O tamanho do contexto é a janela total do modelo; o limite superior limita quantos tokens de saída um nó pode requisitar. O Dify define os dois em 4096 por padrão, o que fica bem abaixo do que os modelos atuais suportam, e deixar os padrões prejudica silenciosamente RAG de documento longo e geração de texto longo. Defina-os pela documentação do modelo, não pelo hábito. Os seletores de capacidade importam quando seus apps os usam: Vision Support só para ids que aceitam entrada de imagem, e a configuração de function-call para corresponder ao suporte de uso de ferramenta do modelo, já que nós de agente dependem disso. Uma alegação de capacidade errada falha em tempo de execução dentro do workflow, o que é um lugar mais lento para depurar do que esse diálogo. Se seu workspace também usa modelos de embedding ou rerank, o mesmo provedor os registra sob suas próprias entradas de Model Type contra a mesma base url; confirme que os ids específicos são servidos pelo endpoint antes de conectar configurações de base de conhecimento a eles.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

Escolhendo modelos para workflows e agentes.

As próprias páginas de visão geral do Dify mostram tokens por app, mas a visão de uso por chave no console da APIsRouter adiciona a divisão por modelo em todos os apps na mesma página, que é o número que decide qual id fica com a vaga.

• Nós de LLM de workflow são volume: etapas de classificação, extração, roteamento, sumarização que disparam a cada execução. claude-haiku-4-5-20251001, gpt-5.4-mini, e gemini-3.5-flash mantêm o custo por execução estável.
• Nós de agente e etapas de raciocínio complexo merecem claude-sonnet-4-6, e seu uso de ferramenta confiável importa mais em agentes do que pontuações de benchmark cruas.
• Nós de resposta de RAG carregam contexto recuperado em toda chamada, então o preço de entrada domina; deepseek-v4-pro vale a pena testar onde a recuperação é pesada e as respostas são longas.
• Registre um id rápido e um id forte para o mesmo papel e faça A/B por nó: no Dify, trocar o modelo de um nó é um dropdown, não uma migração.
• Apps publicados herdam as escolhas de modelo dos seus nós, então a decisão de dropdown que você faz no editor é a economia unitária do app que você lança.

Pague pelo uso · abaixo do preço oficial

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modos de falha específicos do Dify.

Provedor faltando na lista significa que o plugin não está instalado: desde o Dify 1.0 o provedor OpenAI-API-compatible vem como um plugin de Marketplace, e instâncias auto-hospedadas recém-criadas começam sem ele. Instale-o uma vez por workspace. Um modelo que salva mas erra no primeiro uso geralmente é uma de três coisas: um Model Name que não corresponde à grafia do catálogo, uma base url faltando seu /v1 (o Dify anexa caminhos de rota como /chat/completions ao que você digita), ou valores de contexto/max-tokens além do que o modelo aceita. O erro aparece no log do app ou workflow; a correção está de volta no diálogo Add Model. Nós de agente falhando enquanto nós de chat simples funcionam aponta para a configuração de capacidade de function-calling, ou para um modelo cujo uso de ferramenta não atende ao que a estratégia do agente espera. Teste agentes contra claude-sonnet-4-6 primeiro para separar problemas de configuração de escolha de modelo. E em instâncias auto-hospedadas atrás de regras de egresso rígidas, lembre que é o container api do Dify que precisa alcançar o endpoint, não seu navegador; um curl de dentro daquele container resolve rapidamente questões de conectividade.

Quem roteia o Dify por um gateway.

• Times construindo apps de LLM que querem Claude, GPT, Gemini e DeepSeek selecionáveis por nó sem manter uma conta de fornecedor por provedor.
• Auto-hospedeiros rodando o Dify para ferramentas internas, onde uma chave em um provedor mantém todo o gasto em nuvem do workspace em um único log de uso.
• Criadores comparando modelos em workflows reais: cada candidato é um diálogo Add Model e uma troca de dropdown, não uma nova integração.
• Desenvolvedores sem acesso ao faturamento de um determinado fornecedor. O acesso baseado em recarga sem exigência de cartão remove a dependência de cadastro por provedor.
• Agências lançando apps de clientes no Dify que precisam de chaves por projeto para que o gasto de modelo de cada cliente se reporte sozinho.

Verifique o endpoint e depure a primeira execução.

Faça curl na listagem de modelos primeiro e registre ids a partir da saída dela; Model Names digitados à mão são a principal causa de erros not-found porque o campo é texto livre. Depois rode uma chat completion contra o id que você registrou, com a mesma chave. Dentro do Dify, teste em um app de rascunho antes de conectar workflows de produção: adicione um nó de LLM, selecione o novo modelo, rode uma vez. Erros de autenticação apontam para o campo API Key; not-found para Model Name; erros de conexão para a base url ou egresso do container; erros de tamanho para os valores de contexto e max-tokens. Assim que as execuções fluem, o console da APIsRouter mostra modelo, contagens de token e gasto por requisição. Workflows multiplicam chamadas de LLM de formas difíceis de estimar de olho no editor, e o log de uso é onde o perfil real de tokens de um pipeline de cinco nós se torna visível, por modelo, por dia.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

Perguntas frequentes