Choose the model that reads your logs and configs
Cascadia Merge sends your request to a model, and the model decides which tool to call next. You choose the model, and that choice changes where your prompt text goes. The tools stay the same, from read_file and grep to Shell, whichever model you connect.
Where your prompt text goes
Cloud AI provider
A cloud AI provider connects through a standard API endpoint, which you enter in the app together with your own API key. With a cloud model, the prompt text goes to that provider, and so does the text of any file the agent reads, such as a server log or serverconfig.json. Keep the server password out of the chat if you do not want the provider to see it. Secrets in tool output are redacted before they reach the model, and prompts go only to the endpoint you pick. Your API key stays on your PC. The provider may charge for its own usage under its own terms. Choose a cloud model when you already have an account with a provider.
Model on your own PC
A model running locally on your PC is the choice for your most private material. With a local model nothing leaves the machine: the prompt text and the text of the files the agent reads stay on your PC. The agent still runs the same tools, and every action still appears as a card with its real result. Web search is optional, and if you use it, a search query goes out; the other optional network features are described on the privacy page. A local model suits work on a config file that holds your server password, or any other job where you would not send file text to a provider.
Built-in model
The built-in model is ready to use without your own endpoint, which makes it the shortest path to a first session. It suits learning how the cards, the diffs and the three approval modes behave before you connect anything else: ask it to list the data folder with list_dir, then to read serverconfig.json with read_file. You can connect a cloud or a local model whenever you like. The cards look the same whichever model you use, so you can run one small job with two models and compare the answers side by side.
Check the connection with the Test button
The Test button checks an endpoint, shows the response time and shows the context window. The context window is the amount of text a model can read in one go, so it tells you whether a long server log is likely to fit. Run the test after you enter an endpoint and again after you change it. Response time is how long the model takes to answer a short test request, which helps when you compare two providers. The result describes the connection only. It says nothing about how well the model reads your files, so you still read the cards yourself, and a small test job such as listing the Mods folder tells you more.
Choosing a model for a server job
A bigger model is a reasonable choice for a long log or for a change that touches several files, and a smaller model is enough for a small edit such as changing MaxClients in serverconfig.json. The run_on_model tool sends one hard step to a bigger model while the rest of the session stays with the model you picked. The task tool starts sub-agents that work on separate files in parallel, for example the config file and the Mods folder, and each sub-agent reports back in the chat. Split big jobs. Shorter inputs are easier for any model, and quality still differs between models.
Quality varies between models and providers, and a model can misread a log or suggest a wrong value, so read the diff before you accept a change. Ask first pauses before actions that change something and shows the diff to accept, Plan only writes the steps as a plan and runs nothing, and Auto-run acts at once. Cascadia Merge runs your tools. It does not make a model more correct, and it does not replace a test on a copy of your saves.
