Pick the AI model that edits your routing files
Segment Route does not run on one fixed model. You connect a cloud AI provider through a standard API endpoint, a model running locally on your PC, or the built-in model, and the choice decides where your prompts go and what a mistake costs you.
Three ways to connect a model
A cloud AI provider
A cloud provider is reached through a standard API endpoint, and you paste the endpoint address and your API key into the app. The key stays on your PC. Larger cloud models often cope better with a long route file or a tangled redirect chain. The privacy consequence is plain: your prompt, including the text of any file the agent reads, goes to that provider. The provider may also charge for its own usage, which is a matter between you and the provider. Think before you let the agent read a file that holds internal host names.
A model on your own PC
A model running locally on your PC is the choice when route files must not leave the machine. With a local model nothing leaves the PC, because your prompts go only to the model endpoint that you pick and that endpoint is on your own computer. Local models are usually smaller than cloud models, so expect to read the diff more carefully and to break a big job into small steps. Use the Test button to see the response time and the context window before you start.
The built-in model
The built-in model is ready to use without your own endpoint, so it is the quickest way to try Segment Route after the installation. You do not enter an address or a key. It suits a first small task, such as reading a route list and proposing one redirect, and it lets you see how cards, diffs and approval modes behave. When a job grows beyond what it handles well, connect a larger model and run the same task again.
Check the connection with the Test button
The Test button checks an endpoint before you rely on it. It shows the response time and the context window, which is the amount of text the model can hold at once. A short response time makes a long session with many cards more pleasant, and a small context window tells you to work on one route file at a time instead of pasting a whole configuration. If the test fails, check the endpoint address and the key first, and then test again. Run the test whenever you connect a different model or endpoint, so that you know its response time and context window before the first task.
Match the model to the job
Use a bigger model for work with many moving parts: restructuring a long route file, reasoning about why a redirect chain loops, or comparing the rules of two layers. Use a smaller model for small edits, such as changing one code from 302 to 301 or adding one path. The run_on_model tool sends a single hard step to a bigger model, so the rest of the chat can stay on a smaller one. That keeps the large model for the moment when it matters, and you still read every card and every diff yourself.
Quality varies from model to model, and no model is always correct. Treat every proposal as a draft. Read the diff, run your own config test command, and request the address to see the real status code. Ask first is a sensible default for live files, because the agent pauses before actions that change something, and Plan only lets you read a plan before anything runs.
