Swap the model and publish your app
Change the model behind your app without rebuilding it
Dify is model-provider agnostic: you can swap between OpenAI, Anthropic, Groq, local Ollama/LM Studio and dozens more through one UI without changing the app. The app you built — its knowledge base, instructions, and chat URL — stays exactly the same; only the model doing the thinking changes. This lesson is where the GUI-builder design pays off.
- 1 Open your knowledge chatbot from the previous lesson in the Studio.
- 2 Find the model selector for the app. Note which provider/model is currently set.
- 3 Switch to a different provider — for example from a hosted model to a local one served by Ollama or LM Studio, or between two cloud providers. (You configure providers once in Dify's settings; then any app can use them.)
- 4 Re-ask the same grounded question you used before.
- 5 Compare the new answer to the old one — same knowledge base, different model.
The same app answered the same question on two different models, with no change to its knowledge base or instructions.
Why your apps are callable from your own code
Everything you have built in the GUI is also reachable programmatically. Dify exposes a Service API (its own chat-messages and completion-messages endpoints), so every app you build is callable from your own code with the app's API key — but the app itself is still BUILT in the GUI, not via the API.
Dify separates building from calling. You assemble the app visually — knowledge base, model, instructions — and publish it as a public chat URL or an embeddable widget for humans, AND as a Service API endpoint for your own scripts (Dify's own chat-messages or completion-messages endpoint, called with the app's API key). That means a chatbot you built by drag-and-drop can be invoked from Python or any HTTP client — and it carries your knowledge base and instructions with it.
- ?When you swapped models, did the citations stay grounded? Why does the knowledge base survive a model change?
- ?Which delivery surface fits your use case best — a public chat URL, an embedded widget, or the Service API?
- ?If you self-host Dify under the Dify Open Source License, who controls which models and data the app can reach?
Pick the model that fits your constraint
Model choice is a trade-off between quality, speed, cost, and privacy — and Dify makes it a dropdown, so you can decide with evidence instead of guesswork.
Run the same grounded question on two models and choose one as your app's default, with a stated reason.
- 1 Pick two models from different providers configured in your Dify (e.g. one cloud, one local).
- 2 Ask each the same question against your knowledge base.
- 3 Compare answer quality, speed, and what left your machine (a local model keeps data on-prem).
- 4 Set the winner as the app's model and write one sentence on why.
Your app set to a chosen model, plus a one-sentence justification (quality / speed / cost / privacy).