Cloud, local or built-in: pick the model that fits

Gridberry runs on Windows 10/11 and talks to the model you choose. Use a cloud AI provider through a standard API endpoint, a model on your own PC, or the built-in model, and switch whenever a task calls for a different one.

Three ways to connect a model

Cloud AI provider

A cloud AI provider suits harder steps, such as a long troubleshooting session across several logs. You enter the provider's standard API endpoint and your key in Gridberry, and the key stays on your PC. The prompt text goes to that provider, including the text of any file the agent reads, so keep secrets out of those files. Gridberry redacts secrets in tool output before they reach the model. A cloud AI provider may charge for usage, and that is set by the provider, not by Gridberry.

A model on your own PC

A model running on your own PC suits work where the prompt must stay on your machine. With a local model nothing leaves the PC through the model connection. Other features still use the network when you switch them on, for example web search or update checks, and an SSH session to your server is a network connection by nature. Speed and context window depend on your hardware, so run the Test button and read both numbers before you rely on the model.

Built-in model

The built-in model is ready to use without your own endpoint. It suits a first try: install Gridberry, open a chat and ask the agent to explain what adduser does. Switch to Plan only to read a plan with nothing executed, then move to Ask first when you want to approve single commands on a test machine. You can connect a cloud or local model later. Review every command card and every diff with this model as you would with any other.

Check the connection with Test

The Test button checks an endpoint. It shows the response time and the context window of the model you connected. Run it after you enter a new endpoint or a new key, and again when you switch models, so you notice a problem with the endpoint before you start a chat. A long response time means every step waits longer. A small context window means the agent holds less of a long log or a long configuration file at once. Compare two endpoints with the same button and keep the one that suits your task. The result describes the connection only. It does not tell you whether the model writes correct commands, so you still review every card and every diff.

Choose a model for the job

Pick a bigger model for steps with many moving parts, such as a long troubleshooting session across logs and configuration files, and a smaller one for short steps such as creating one account or reading one group list. The run_on_model tool sends a hard step to a bigger model while the rest of the chat stays on the model you chose, and you decide when to use it. A bigger model may be slower to answer, and it needs stronger hardware on a local PC, so match the model to the step. Review the result either way.

Quality varies between models, and any model can write a wrong command with full confidence. Read the diff or the command card before you accept it. Ask first pauses before actions that change something, so you see the exact line before it runs. Plan only writes a plan and runs nothing, which is a sensible first step with a model you have not used before. Try new models on a machine you can rebuild.