choosing an agent setup

choose a setup around the work you need to finish and how you want to inspect it. a useful comparison includes the agent, its tools, the execution environment, and the time you spend steering and reviewing the result.

what am i choosing?

choice	question it answers
surface	where will you prompt, intervene, and review?
harness	what runs the agent loop, tools, context, and permissions?
model	what supplies the reasoning and generation?
execution host	where will files, commands, and services run?
coordination	how will independent tasks exchange context and results?

one product can cover several of these choices. Codex and Claude Code each provide several ways to work with their agent. Cursor combines editor features with agent workflows. OpenCode provides an open source agent with several model provider options. the Grok guide separates its conversational, coding, and Bot experiences.

changing one part can change the result. the same model receives different context and tools through different harnesses. a familiar editor may help you review faster. a remote host may have a dependency your laptop lacks. record those differences when comparing products.

which app should i use?

your main activity	a useful surface to try	tradeoff to inspect
tracing code and reviewing small patches	terminal or editor	how easily you can see commands, failures, and the complete diff
steering several independent tasks	desktop task view	whether ownership and blocked work remain visible
checking work away from your desk	mobile access to the relevant task	how much review the smaller screen supports
running work in a separate environment	cloud or remote project	dependency setup, access, and reproducibility

begin with one outcome in a surface you already understand. add coordination when there are independent tasks to manage. a task list becomes useful when it helps you make the next decision about the work.

how do i compare them?

choose a representative task with a known starting state. for example, use the same repository revision and ask each setup to fix the same search navigation bug. provide the same expected behavior and checks. give each attempt its own checkout, and keep the results separate until you review them.

record:

• the product, model selection, and settings you used.
• the repository revision, environment, and information supplied.
• time to a reviewable result and any interventions you made.
• whether the change passed the relevant checks and browser flow.
• remaining mistakes, unnecessary changes, and work needed to finish.

one attempt can expose a problem or a useful capability. try several tasks that resemble your work before treating the outcome as a reliable preference. change one major variable at a time when you want to understand why a result improved.

for a paid option, compare the value of completed, reviewed work against the cost and constraints shown in your account and the provider’s current pricing, such as Cursor’s plan page. model availability, included usage, and provider integrations change; inspect those terms before committing to a workflow that depends on them.

do i need a better computer?

with a hosted model, inference happens at the provider. local builds, browsers, containers, language servers, and tests still run wherever the task’s execution host is. several agents can put pressure on that host even while all their models run remotely.

pattern	where model inference runs	where project commands run
hosted model with local tools	provider	your computer
hosted model with a remote project	provider	remote host
cloud coding task	provider	configured cloud environment
local model with local tools	your computer	your computer

measure a representative workload while it is running. inspect memory pressure, CPU use, available storage, and the processes using them. identify whether the delay comes from model responses, dependency installation, builds, browser work, or waiting for your review.

worktrees keep separate checked out files, and each may accumulate dependencies or build output. local models add weights and runtime memory. estimate those needs from the model and runner you intend to use, then test the actual workload. a hardware specification alone cannot tell you whether a particular agent setup will feel responsive.

Karpathy posted about buying a Mac mini to experiment with claws. his post also raises the question of what private data and credentials to give an agent. your workload and access requirements should guide that choice.

Andrej Karpathy (@karpathy), february 2026.

should it run somewhere else?

remote execution can help when the necessary environment already lives on another machine, local resources are constrained, or the task should continue in a hosted environment. check how setup, files, permissions, and results move between the machines. Codex Remote controls a connected host; Codex cloud uses a separately configured environment.

local model execution gives you another deployment choice, with responsibility for model selection, runtime configuration, hardware, and evaluation. inspect all other connections as well when privacy or offline use is the reason for choosing it. the model’s location describes only one part of the data flow.

keep the setup whose benefits recur in your actual work. expand it when a specific limitation appears, and make the added component earn the time spent configuring, reviewing, and maintaining it.