Use local models with AI agents

Use local models with AI agents when a model on your own computer fits the work better than a hosted model. A Prostir Worker connects that computer to Prostir. It can run an explicit task or supply the model for an existing Agent. Supported coding tools such as Claude Code, Codex, Gemini and GitHub Copilot are another option when installed, authenticated and qualified for the request. Those tools may still use their provider’s cloud: running a tool on your computer does not make every model local.

Open Workers in Prostir and follow its installation instructions. Start dotnet prostir in the folder you want to use. On the first run, browser sign-in lets you choose or create the Worker and connect that computer. Later runs reuse the connection saved in your operating system’s credential vault. The working folder is the folder where you start the command; choose a separate folder deliberately if the task needs it. The computer and CLI must stay running for work to reach them.

Prostir shows the providers and models the computer actually reports. Enable the provider you intend to use and check its readiness. Existing supported coding tools can be discovered; they still need a compatible version and their own usable account. Local services such as Ollama, llama.cpp or MLX, and supported ONNX model directories, need their own local setup. Selecting a model does not download its weights, start a missing engine or grant it extra tool capabilities. Availability depends on your platform, installation and model.

In an Agent’s model settings, choose Worker, then the exact computer, provider and model. This is a model-source choice alongside Prostir AI credit and your own provider key. The Agent’s instructions, conversation context, knowledge access and authorized tool actions remain controlled by Prostir; the Worker receives the bounded model turn needed for the request. A Flow can call that Agent or use an explicit Worker task step. The Flow still controls its sequence and run state in Prostir. A Worker is execution infrastructure, not a seventh marketplace product.

Connect only a computer you control and enable only the providers you want it to use. The computer’s local workspace, credentials and native permissions still matter. Product access and tool permissions in Prostir continue to apply. Do not assume that selecting a local model means all product data stays on the computer: the Agent remains in Prostir, and the request may include authorized context. Inspect progress, the result and any failure. A lost connection or uncertain process exit is not a successful task, and reconnecting does not silently repeat it.

A local model uses your hardware, storage and electricity. A coding tool or hosted provider may require its own subscription or usage payment; check that provider’s terms. Worker execution does not silently switch to a Prostir-hosted model or a different provider when the selected model is unavailable. Normal Agent and Flow plan allowances still apply. Supported models differ in context, tools and response capabilities. An offline computer or an incompatible model can stop the job, so this is a poor fit when you need an always-on service but cannot keep that computer available.

Start with one request whose result you can check. Connect the Worker, confirm that the chosen provider and model are ready, then send a small task. Inspect its live progress and final result before selecting it for an Agent. Try the Agent’s actual knowledge and tools, then a Flow if your process needs one. Workers is available only where your account and the feature configuration allow it. Provider and platform qualification vary; a connected computer alone is not proof that every model or action will work. Expand from the behavior you have verified.