Cloud and local execution: where an agent runs
Understand ACP cloud jobs, paired-machine execution, credential location, and availability limits.
Cloud is the ordinary path
ACP can run a job in its cloud environment. Depending on deployment settings, a cloud job runs on the backend service or on a separate ACP Runner. Both count as cloud execution and use cloud-authorized credentials. A separate runner is an internal isolation choice, not the same thing as sending work to your laptop.
Free Solo is currently platform funded: the platform wallet pays for supported agent runs under fair-use caps. You do not need to paste a personal model API key to get started. Plan availability and any future paid checkout are described on Pricing, rather than implied by the presence of a model picker.
A paired machine is a separate execution target
Where an operator enables local execution, a paired machine can claim eligible jobs and bind a local repository. Its provider credentials stay on that machine. Pairing does not copy your local provider secrets into ACP's cloud vault, and a cloud credential cannot silently fill in for a missing local one. If the requested target or its credentials are unavailable, the run should stop at preflight rather than quietly moving to another location.
Local execution is gated by deployment and account settings. Do not assume it is available on every account merely because the agent package exists. Check the execution choices offered by your workspace before planning a workflow around a paired machine.
Choose based on the repository and secrets
Cloud is simplest when the project and approved credentials can live in the hosted environment. A paired machine helps when a repository or tool must stay on hardware you control, subject to local-execution eligibility. For either path, inspect the job's chosen target and stage evidence when diagnosing a block; a network problem on one target will not be repaired by changing an unrelated model setting.