What is an agent runner?

A chat setup usually answers one request. An agent may take many steps before it stops. The agent runner is the part that manages those steps:

• Runs the loop. It decides what step happens next, sends work to the model, reads the reply, and continues until the task is done or a limit is hit.
• Executes tool calls. When the model asks to search, read a file, or hit an API, the agent runner is what actually runs that tool and feeds the result back.
• Handles retries. When a step fails or times out, the runner decides whether to retry, back off, or stop, so one bad call does not end the whole task.
• Keeps memory and state. It tracks what has happened so far, so the agent does not start from scratch on every step, and can pick a task back up later.
• Schedules or stays on. It can run a task on a schedule or stay always on, waiting for the next message or trigger.

These two get mixed up, and the difference matters for both setup and cost. A Model runner loads a model and serves text from it. An agent runner sits on top and manages the task around the model.

• Model runner. Loads and serves the model. You give it input, it returns output. That is the whole job. It does not decide what to do next, call tools, or remember anything between calls.
• Agent runner. Runs the loop that uses the model. It calls the model (which may be an API model or a local model behind a Model runner), executes tools, retries, and keeps state. It manages the work; it does not serve the model itself.

An agent runner does not make a weak model strong. It changes how the model is used, what tools it can reach, and how the work is managed, not the quality of the model underneath.

The agent runner is where the extra agent cost comes from. A Model runner answering one request is a single call. An agent doing the same task can turn that into many calls, plus work that has to keep running. The main cost drivers:

• Steps. Each step is usually its own model call, and the running record of the task is often resent each time, so a multi-step task uses far more than a single answer would.
• Tool calls and retries. Every tool call and every retry can add another round trip to the model, and a task that retries a few times multiplies that.
• Memory and state. Carrying history between steps means more input each call, and storing state between runs is its own small cost.
• Always-on hosting. An agent that waits for messages or runs on a schedule needs something kept running, which is a cost even in the hours it is idle.

For how these add up, see what it costs to run an AI agent, agent model usage cost, and AI agent hosting cost.

An agent runner often needs two interfaces, and it helps to plan for both:

• Where users talk to the agent. The user-facing Interface: Slack, Discord, Telegram, email, a web UI, or an API. This is how people send work to the agent and get results back.
• Where the owner controls it. The operator Interface: logs, an admin panel, or a terminal to configure the agent, watch what it did, and stop or approve steps. A terminal is often how the owner controls the agent, not how end users reach it.

Which Interface fits depends on where the work comes from. See the best interface for an AI agent. If the agent works the web, the runner also needs a browser and more memory; see what an agent needs to work the web.

• Cloud agent runner. Runs on a Cloud host you rent, which is easier to keep always on. It usually calls an API model, so you pay by tokens for usage and a fixed amount to keep the host running. A small Cloud host plus an API model is a common low-cost path for a cheapest always-on AI agent.
• Local agent runner. Runs on Local hardware you own. There is no host bill, but the agent stops when the machine sleeps or disconnects, so it fits tasks that do not need to stay always on. It can call an API model or a local model behind a Model runner. Do not rent a Cloud GPU only because the workload is called an agent. A rented GPU is only needed if the model itself has to run on your server.

• Treating the agent runner and the Model runner as the same thing. They are two different layers. The Model runner serves the model; the agent runner manages the task around it. Sizing one as if it were the other leads to a wrong estimate.
• Assuming an agent costs the same as a chat. A single answer is one call; an agent can take many steps, each its own call, so the usage side grows with how the runner works, not only the model you picked.
• Renting a Cloud GPU for an agent that uses an API model. The agent runner needs somewhere to stay running, which can be a small Cloud host. A rented GPU only pays off when the model itself runs on your server.

AIStackPicker keeps the Agent runner and the Model runner as separate parts of a setup instead of blending them. The Builder treats the agent runner as the layer that runs the loop, the Interface as how people use and control it, and the model (API or local) as what the runner calls. Keeping them apart is what lets the estimate show where the extra agent cost actually comes from rather than hiding it inside one number.

• Cost to run an LLM
• Cost to run an AI agent
• Local LLM vs cloud API
• Run a local LLM
• GPU hosting vs model API
• Browse all stack parts
• Read the FAQ