Ways to drive a session

How you use Kasm Session Runtime comes down to two independent questions.

1. Who drives? Your own agent (Claude Code or any other MCP client, or a Chrome DevTools Protocol client such as Playwright), or the runtime’s own guarded loop with a model you choose.
2. When does reasoning happen? On every run, with a decision made live each time, or once, after which every run repeats the same steps.

The second question decides whether a task is repeatable. Reasoning once and replaying gives the same actions and the same checks on every run, and the model is not asked again unless something has changed.

	Reasoning every run	Reasoning once, then replay
Your agent drives	Your agent calls the runtime’s MCP tools, or drives the browser through the /cdp/ proxy. No model in the runtime. Example: 05-mcp-drive	Your agent, or a person, writes a scenario once. Every run after that executes the same steps, with no model unless the scenario asks for visual checks. Examples: 01-cdp-chrome, 04-atspi-libreoffice
The runtime’s loop drives	A goal: scenario. The loop decides each action with the model on every run. Example: 07-agentic-discovery	A goal: run once, compiled with compile-plan into a plan:. Later runs replay the plan with no model and fall back to the loop only when a postcondition fails. Example: 08-parallel-agentic-goals

The examples are directories in the SDK.

Choosing a way to drive

• If you already have an agent and want it to use a Kasm session, let your agent drive on every run. The runtime gives it tools that act on a real desktop session and a record of every action it took. See Using it with your own agent.
• If the job is known and must run the same way each time, in CI or across many sessions, write a scenario. A coding agent can write the scenario YAML as well as a person can. See Write a scenario.
• If no data may leave your network and the task needs judgement at run time, use the runtime’s loop with a model on your own hardware. See Run it with a local model.
• If the same task runs often and the application changes now and then, run the loop once and compile a plan from it. You pay for the model only on runs where the application stopped matching the plan. See Plans and postconditions.

A test can also drive the session with no agent at all, through Kasm’s viewer or the plain HTTP interface, and use the runtime only to confirm that its input arrived. See Driving without an agent.

Requirements of each

Setup	Model in the runtime
Your agent, over MCP or CDP	None
A scenario of scripted steps	None, unless it uses observe:, expect:, click_grounded or a screen postcondition
The runtime’s loop (goal:)	Required, with tool calling
A compiled plan	None while the plan’s postconditions hold; required for the fallback to the loop

See When you need a model for the full list.

Next

• A run from start to finish
• Plans and postconditions
• Using it with your own agent