Choose where your prompts go before you connect a model
Portward works with three kinds of model: a cloud AI provider through a standard API endpoint, a model that runs locally on your PC, and the built-in model. Each choice decides where your prompts go, so make it before you point the agent at a server.
Three ways to connect a model
Cloud AI provider
A cloud provider connects through a standard API endpoint that you enter in the settings together with your own API key. Portward sends your prompts to that endpoint, and a prompt can include the text of any file or log the agent has read, so a cloud model receives that text. Your chats, working folders and API keys stay on your PC, and secrets in tool output are redacted before they reach the model. This route is common for long logs and large configuration files, because the model is not limited by your own hardware. Read the provider's own terms to see how it handles prompts, and press the Test button after you enter the endpoint.
Model on your PC
A model running locally on your PC keeps everything on the machine: with a local model nothing leaves it. You connect Portward to the local endpoint, and the Test button reports the response time and the context window. Speed and quality depend on the model and on your hardware, and a smaller model can make more mistakes on a long configuration file, so read each diff with care. This route fits notes and logs that you do not want to send to any provider, for example a copy of a mail configuration that contains private names.
Built-in model
The built-in model is ready to use without an endpoint of your own, so there is nothing to enter before the first task. Pick it when you want to look at the cards, the diffs and the approval modes before you connect anything else. You can switch to a cloud or a local model later if a task needs a bigger one. Quality varies from task to task, so read each result card and each diff before you accept it, and test the outcome on your server from a second session.
What the Test button checks
The Test button checks an endpoint, then shows the response time and the context window. Run it after you enter a cloud endpoint or a local one, before you give the agent a server task. The context window tells you how much text fits into one request, which matters when you paste a long log or a configuration file. If the test fails, check the endpoint address and the key, correct them and run the test again before you start the task.
Pick a model for the task
Use a bigger model for hard steps, such as reading a long log or planning a firewall change, and a smaller model for small edits, such as one line in a copied configuration file. The run_on_model tool sends a hard step to a bigger model while the rest of the chat stays on your default one. The task tool splits independent checks, for example disk space and service status, across parallel sub-agents. Cron runs a saved prompt on a schedule, and plans survive restarts, so a long job can continue after you close the app.
Quality varies between models, and any model can misread a log or suggest a wrong setting. Read the diff before you accept it. Ask first pauses before actions that change something, Plan only writes a plan and runs nothing, and Auto-run acts at once, so match the mode to the risk of the change. Test the result yourself, for example by logging in from a second session.
