メインコンテンツへスキップ
更新日: 2026-06-23
Dify is a strong fit for workflows, agents, knowledge bases, and internal AI application platforms. When connecting it to Crazyrouter, the recommended rollout is to start with the OpenAI-compatible provider path, get one chat model working first, and only then add embeddings or other model types.

​
Overview

Using Dify’s model provider configuration, you can add Crazyrouter as an OpenAI-compatible upstream:
  • Recommended protocol: OpenAI-compatible API
  • Recommended entry point: Settings → Model Provider
  • Base URL: https://api.crazyrouter.com/v1
  • Auth method: sk-... token
  • Recommended first validation model: gpt-5.5
Depending on your Dify version or plugin-based distribution, the provider may appear as OpenAI, OpenAI-API-compatible, OpenAI Compatible, or something similar. Pick the OpenAI-compatible provider that lets you set a custom API Base URL.
Official Dify docs treat a custom API Base URL as an optional field for proxy or compatible-upstream scenarios. For Crazyrouter, that is exactly the intended pattern, so use https://api.crazyrouter.com/v1 as the OpenAI-compatible upstream. Also, model-provider configuration is usually limited to workspace admins or owners; if you cannot see the entry, check your role first.

​
Best For

  • teams building workflows, agents, or knowledge-base apps
  • orgs that want chat and embedding models on the same upstream
  • internal AI platforms with visual orchestration
  • environments that need clean dev, staging, and production separation

​
Protocol Used

Recommended protocol: OpenAI-compatible API When connecting Crazyrouter in Dify, the usual OpenAI-compatible base URL is:
Do not enter:
  • https://api.crazyrouter.com
  • https://api.crazyrouter.com/v1/chat/completions
The exact UI label can move between Model Provider, Providers, localized labels, or plugin-related entry points across Dify versions. Keep the first-pass validation flow unchanged: save the provider first, add only one LLM model gpt-5.5, and validate with a minimal Chat app before adding anything else.

​
Prerequisites

Recommended starting whitelist:
  • gpt-5.5
  • claude-opus-4-8
  • text-embedding-3-large
  • text-embedding-3-small
If you plan to use a knowledge base, prepare at least one chat model and one embedding model.

​
5-Minute Quick Start

1

Create a dedicated Dify token

In the Crazyrouter dashboard, create a token named dify. For the first pass, allow gpt-5.5 and one embedding model such as text-embedding-3-large.
2

Open the model provider settings

Log in with a workspace admin-capable account and go to Settings → Model Provider.
3

Add an OpenAI-compatible provider

Choose the OpenAI or OpenAI-compatible provider entry and fill in:
  • API Key: your sk-...
  • API Base URL: https://api.crazyrouter.com/v1
4

Configure only one chat model first

For the first rollout, add a single LLM such as:
  • Model: gpt-5.5
  • Type: LLM
Then create a very simple Chat app or Workflow app for validation. Do not add chat, embeddings, rerank, and workflow tools all at once, or troubleshooting will get mixed together.
5

Run the first validation request

In the app, send Reply only OK. If it succeeds and appears in the Crazyrouter logs, the chat path is working. Add embeddings only after that.

​
Embeddings and Knowledge Base Guidance

If you want to use Dify knowledge bases, RAG, or document retrieval, add an embedding model as the second step: Recommended order:
  1. validate the chat model
  2. validate embeddings
  3. then import documents and tune retrieval
That keeps troubleshooting much cleaner. Recommended order: get the chat model working first, then add embeddings.

​
Token Setup Best Practices

​
Verification Checklist

  • Crazyrouter is saved in Model Provider
  • API Base URL is set to https://api.crazyrouter.com/v1
  • at least one LLM is configured successfully
  • the first Dify app request succeeds
  • the request appears in the Crazyrouter logs
  • at least one embedding model is configured if you need knowledge-base features
  • token quota and model whitelist match your rollout plan
  • dev, staging, and production use separate tokens

​
Common Errors and Fixes

​
Performance and Cost Tips

  • Keep gpt-5.5 as the workflow baseline during initial validation
  • For the first knowledge-base launch, import a small document set before indexing everything
  • Track chat and embedding traffic separately so cost sources stay visible
  • Set tighter quota caps for batch jobs, scheduled jobs, and internal test environments
  • If usage spikes, check Crazyrouter logs first to see whether the cause is retries, imports, or multiple apps sharing one token

​
FAQ

​
Which Base URL should I use in Dify?

Use https://api.crazyrouter.com/v1.

​
Why should I not use only the root domain here?

Because Dify’s OpenAI-compatible provider usually expects the OpenAI-compatible base, not the root domain.

​
Should I configure chat or embeddings first?

Configure chat first, confirm the app can answer, then add embeddings.

​
Can I configure rerank models directly?

That depends on your Dify version and installed provider plugins. Get chat and embeddings working first, then decide whether you need rerank support.

​
Why does this guide insist on starting with one chat model only?

Because Dify issues can come from the provider layer, model type, app configuration, or knowledge-base chain. Validating a single gpt-5.5 chat app first makes isolation much easier.

​
Should Dify use multiple tokens?

Yes. At minimum, separate dev and production. At higher volume, split chat and embeddings too.
Dify is best treated as an application and workflow platform, not just a chat frontend. That is why dedicated tokens, whitelist control, and per-environment quota strategy matter much more here.