Pick the AI model that drives your debugging sessions

StatusRivet needs a model to think with, and you decide where it lives: a cloud AI provider through a standard API endpoint, a model running on your PC, or the built-in model. This page explains the three choices and how to test a connection.

Three places for the model to run

Cloud AI provider

A cloud AI provider suits large codebases and long logs. You enter a standard API endpoint and your key. The key stays local. Every prompt goes to the provider you picked, including the text of any file or log the agent reads for that step, so read the provider's own policy before you send source code that is not public. Keep the work to software you wrote or are authorised to debug. The provider may charge for usage under its own terms, and StatusRivet is independent of every provider. Choose it when your logs and source files need a big context window.

Model on your PC

A model running on your PC suits code you cannot send anywhere. Your PC does the work. Point StatusRivet at the local endpoint and the prompts go to your own machine, so nothing leaves it. The trade-off is hardware: the speed and the context window depend on what your PC can run, and a long log may not fit. Use the Test button to see the window before a long session. Updating or swapping the model is your job. It fits lab machines and unpublished drivers well, as long as you accept those limits.

Built-in model

The built-in model is ready to use without your own endpoint, so it is the shortest path from installation to a first chat. No endpoint is needed. Use it to try the approval modes, to read a short log and to see what a diff card looks like before you set up anything else. When a task needs more, connect a cloud AI provider or a model on your PC and run the same chat again to compare the answers. Review every diff the same way, whichever model wrote it.

Test the connection before a long session

Press the Test button next to an endpoint to try the connection. The result shows the response time and the context window of that model. Response time tells you whether the endpoint answers at a pace you can work with. The context window tells you how much of a log or a source file fits into one request, which matters when a long call stack is part of the prompt. Run the test again after you change the endpoint or the model. A failed test points at the connection, not at your code. Fix that first.

Choose a model size for the task

Use a bigger model for hard reasoning, such as tracing a fault through several modules or reviewing a larger change, and a smaller one for small edits such as adding a null check. The skill run_on_model lets the agent send one hard step to a bigger model while the rest of the session stays on the smaller one. That keeps routine steps on the smaller model while the difficult step gets more capacity. Pick by task, not by habit, and use the Test button to compare context windows before a long crash log goes in. Fit the log first.

Model quality varies between providers and versions, so treat every answer as a draft. Drafts need review. Read the diff, rebuild with your build command and run your test command before you keep a change. Ask first pauses before actions that change something, which gives you a place to stop and read. Plan only writes a plan and runs nothing, which helps when you want to see the steps before you switch to Auto-run or Ask first. The agent works from text output, so a result is only as good as the logs you give it.