Choose the model that powers your test runs
FlowLatch works with the model you pick. Connect a cloud AI provider through a standard API endpoint, run a model on your own PC, or start with the built-in model, then use the Test button to check the connection before the first task.
Three ways to connect a model
A cloud AI provider
A cloud provider is reached through a standard API endpoint: you provide the endpoint address, your API key and the model you want. It suits large refactors and hard debugging, because bigger models usually follow a long test suite better. Be clear about the cost to privacy. Your prompt, including the text of any file the agent reads, goes to that provider, so keep secrets and real customer data out of the working folder. FlowLatch keeps the API key on your PC, and secrets in tool output are redacted before they reach the model. The provider may charge for its own use.
A model on your own PC
A local model runs on your PC and FlowLatch talks to it through an endpoint on the same machine. It suits private projects, because with a local model nothing leaves the machine: prompts, file text and results stay with you. The trade-off is hardware. A smaller local model may write weaker selectors or miss a cause that a larger model would find, so read each diff with care. Use the Test button to check that the endpoint answers and to see how much context the model can hold.
The built-in model
The built-in model is ready to use without your own endpoint, which makes it the quickest way to try FlowLatch on a small test project. You can open a chat, point it at a working folder and ask for a first sign-in test straight away. It suits learning how the cards, the diffs and the three approval modes work. When a task grows, such as a long migration or a hard flaky failure, you can connect a cloud provider or a local model and work in the same folder.
Check the connection with the Test button
The Test button checks a model endpoint before you rely on it. It sends a small request and shows the response time and the context window, which is how much text the model can take in one turn. A long response time is worth knowing before a big task. A small context window is a hint to work on one test file at a time. If the test fails, check the endpoint address, the API key and the model name, then press the button again.
Pick a model to match the task
Use a bigger model for refactors and complex logic, such as moving a long suite to another framework or untangling a failure that depends on the order of tests. A smaller model is enough for small edits, such as renaming a test or changing one selector. The run_on_model tool sends one hard step to a bigger model, so the rest of the chat can stay on the model you chose. Mixing sizes in this way is your decision, and the cards show every step that was run.
Model quality varies between providers and versions, and every model can be wrong. Read the diff before you accept a change, and run the tests yourself. Ask first pauses before actions that change something, so you see each edit before it is written. If a model misreads a failure, reject the change and say what is wrong in the chat.
