Amp

Amp's distinctive part is orbs: remote sandboxes where the agent works on a copy of your tree instead of your laptop, which is the setup step most terminal agents leave to you. Day to day that changes one habit: you stop reading every command before it runs, because a wrong one lands in a disposable machine. The editor integrations are fine; the terminal is where it is strongest.

Pick it if isolation without running Docker yourself is the trait you have been missing. Pick Claude Code or Codex CLI if you want a larger included quota from one vendor and are content to supervise the shell yourself.

The pricing page is the failure mode. A subscription that includes a dollar amount of usage is a meter wearing a hat: a long run in the expensive mode burns the allowance, paid credits start, and nothing on the page says where the line is until you cross it. An agent has no reason to stop early, and a budget denominated in its own consumption gives it none.

Treat the included amount as a deposit and set an alert below it. What it does right: an execute mode built for CI, so runs can be scripted, bounded by a timeout, and killed by something that is not you.

Amp's architecture is documented by its docs and its price list, and that is the whole evidence base. 1. Work is routed across GPT-5.6 and Claude Fable 5.1 by the mode selected, so cost is allocated to difficulty by the user's choice rather than a measured router. 2. Remote sandboxes hold the working tree, which makes execution reproducible in principle. 3. No benchmark is published, so whether the routing improves outcomes per token is asserted, not demonstrated.

The design would be cheap to measure: one task set run in each mode with cost recorded. Until then, the modes are named after power units and priced like them.

Amp is the newest cap table on this board, carved out of Sourcegraph in December 2025, which makes the founding story a spin-out rather than a garage, and the first eighteen months a test of whether the asset deserved its own company. The product wraps two labs' frontier models, sold by companies shipping their own agents; routing and orbs are engineering, and engineering is a lead measured in quarters, not a moat.

The most likely acquirer is a hyperscaler that wants the sandbox layer and the team that built it. Position: use it; do not build a team process on it until the next funding event says who is paying.

The demo is an agent working in a remote sandbox while the engineer does something else. Procurement has no number: teams pay API pricing for tokens and orb hours, so sixty seats cost whatever sixty engineers spend, and the ten most enthusiastic will set the budget for the year. SSO, directory sync and minimal data retention are enterprise add-ons behind a contact form, which means the security questionnaire waits on a sales call.

Onboarding is easy; forecasting is not. Not yet: I need a per-seat price, a spend cap per workspace, and the add-on terms in writing before this goes past a pilot team.

Amp scores low on my checklist. open_source false, local_models false, and a bring-your-own-model that spends my Anthropic key on Amp's own modes; the $20 plan's high mode also wants a linked ChatGPT subscription I already pay for. Nothing runs offline, and if the company folds there is no repository to fork, only an install script pointing at a dead endpoint.

What I can change: amp.mcpServers takes local commands and remote SSE URLs, so my own tool servers plug in from a settings file I can version. That is a socket, not ownership. Grudging respect for the sandbox, the one part I would have built the same way.