Why I love Amp

If you’ve worked on a software team, these will sound familiar:

An engineer wants to show you what they built, but first they have to deploy it somewhere, or you wait for the next demo.
A product manager understands the feature, the customers, and the edge cases better than anyone, yet can’t write the code. Every small change becomes a ticket and a wait.
A non-technical teammate wants to run the project locally. Containers simplify this for engineers, but expecting a PM or designer to learn Docker isn’t always reasonable.

Amp addresses all three, which is why I love it. The agent runs in the cloud, and everything it produces is shareable by URL. That opens development to the people on a team who don’t write code every day.

The work happens in the cloud, not on your machine

Each Amp thread can run on its own cloud machine, which Amp calls an orb. The repository and tooling are already installed, and the agent works there rather than on your computer.

As a result, hardware stops being a prerequisite. A browser is sufficient, and Amp offers native apps for Mac, iPhone, and iPad. You can start a task at your desk, close the laptop, and check its progress from your phone. When you return, the environment is exactly as you left it.

No dev setup for the rest of the team

An engineer configures the project once, or delegates that to Amp. From then on, a PM, designer, or support lead can open a thread and start contributing without installing a language runtime, a database, or anything else.

Any thread can be shared with your team or with anyone who has the link. Reviewers see the full reasoning behind a change, not just the diff.

The running app is shareable as well. Ask the agent to start it, and you receive a preview link you can explore like any website. If something looks wrong, annotate it and send the feedback directly to the agent.

This folds user acceptance testing into the everyday workflow. Teammates can try the app from within the thread, and clients or stakeholders can receive temporary access to the preview without an Amp account and without seeing the conversation.

Work on the same thread together

Multiplayer lets you invite teammates into a thread. Once inside, they can prompt the agent, test the app, and work in the same environment you do. You can even start a voice or video call without leaving the thread.

Collaboration becomes a matter of taking turns. A designer drives the UI refinements, an engineer steps in when the agent stalls on a migration, then hands control back. A less technical teammate can start the work and invite help, rather than filing a ticket and waiting.

You are not locked in

By default, Amp supplies both the AI models and the cloud machines, but you can substitute your own for either.

Bring your own models. You can route some or all of Amp’s model usage through your own API keys, subscriptions, or cloud accounts, billed directly by your provider. Supported options include Anthropic, OpenAI, Google, AWS, Azure, OpenRouter, and any compatible endpoint. Amp covers whatever you leave unassigned.

Bring your own compute. You can run the cloud machines on your own infrastructure, whether that’s Docker, Kubernetes, or a sandbox provider you already use, so the machines live on your network. Self-hosting is free on Amp’s individual and team plans; you pay only for your own infrastructure.

Works with your ChatGPT subscription

My favorite perk: you can sign in with your ChatGPT account, and Amp bills its OpenAI model usage to that subscription instead of charging per token. If you already pay for ChatGPT Plus or Pro, the agent draws on a plan you already have rather than generating a second bill that scales with every prompt.

A flat monthly fee is also easier to budget than usage-based API pricing, particularly for teammates who are new to agents and still calibrating how much to ask of them. The cloud machines are billed separately, but model usage comes out of your existing plan. GitHub Copilot subscriptions work the same way.

What it costs

Amp’s pricing is modest. There’s a free tier, the individual plan is $20 a month, and team workspaces carry no extra charge. Amp doesn’t mark up model providers’ API prices for individuals and non-enterprise teams, cloud machines cost nothing while paused, and on those same plans, self-hosted machines are free.

The savings I notice most come from shorter handoffs. Without Amp, a small change can pass through several people: a PM writes a ticket, it waits to be prioritized, an engineer rebuilds the context the PM already had, makes the change, deploys it somewhere reviewable, and waits for feedback. Each step adds delay and drops a little information.

With Amp, the person who holds the knowledge, whether a PM, a designer, a support lead, or a compliance specialist, can make the change, see it running, and bring in an engineer only when the work calls for one. Subject matter experts apply their expertise directly instead of translating it into tickets, and engineers spend more of their time on problems that require engineering.

It also removes a piece of infrastructure. Preview environments need pipelines, configuration, cleanup, and access control, and someone has to maintain them. Every Amp thread already has a running app and a shareable link, so for day-to-day review, much of that work goes away.

What Amp changes

Amp’s real value is who gets to do the work. The people closest to a problem can now act on it directly, and the people who need to see the result can open it from wherever they are.

The engineer sends a preview link instead of deploying. The PM turns product knowledge into a working change instead of a ticket. The designer contributes without ever setting up the project. Engineers stay involved, but on the problems that need them.

The result is less waiting and fewer handoffs, at a price that’s easy to justify. That’s why Amp has become my favorite way to build with a team.