Amp Code

Amp is a coding agent that can inspect a repository, edit files, run commands, use external tools, and continue working through a task in a persistent thread.

It is not a language model. Amp is the agent harness around several models. The harness manages the conversation, tool loop, repository context, execution environment, review workflow, and thread history. Amp can change the model and reasoning strategy behind a mode without changing how you invoke the agent.

This makes Amp different from calling an OpenAI or Anthropic model API directly. A raw model API gives an application inference and tool-calling primitives. Amp supplies an opinionated coding workflow on top of those primitives.

The Current Amp System

Amp can be used through several connected surfaces:

• CLI for interactive or one-shot terminal work
• web and mobile for starting, following, steering, and reviewing threads
• IDE connections for sending editor context to the agent
• orbs for running work on managed remote machines
• local runners for remote control while execution remains on your machine
• SDKs for embedding Amp threads in TypeScript or Python applications

flowchart TB
    U["User<br/>CLI, web, mobile, or IDE"] --> T["Persistent Amp thread"]
    T --> M["Effort mode<br/>low, medium, high, or ultra"]
    M --> A["Agent loop<br/>model, instructions, and tools"]
    A --> E{"Execution location"}
    E -->|Local| L["Repository on local machine"]
    E -->|Remote| O["Managed orb"]
    L --> R["Diff, tests, and review evidence"]
    O --> R
    R --> T

Amp’s surfaces change faster than the underlying workflow. The current manual should be treated as the source of truth for commands and feature availability.

What A Beginner Should Understand

When you ask Amp to fix a bug, the request can trigger several model calls and tool calls:

1. inspect repository files
2. search for related code
3. decide on an approach
4. edit one or more files
5. run tests or builds
6. inspect failures
7. revise the implementation
8. summarize the result

The thread stores that progression. A mode determines how much effort Amp should spend, while permissions and the execution environment determine what it can affect.

The final response is not proof that the task is correct. Review the diff and run the project’s real verification checks.

Install And Start

The current official installation methods include:

# macOS or Linux
curl -fsSL https://ampcode.com/install.sh | bash

# Homebrew
brew install ampcode/tap/ampcode

# Update an existing installation
amp update

On Windows PowerShell:

powershell -c "irm https://ampcode.com/install.ps1 | iex"

Start an interactive thread in a repository:

cd path/to/repository
amp

Then describe the outcome, constraints, and verification target:

Fix the expired-session redirect bug.

Preserve the current behavior for active sessions.
Follow the authentication patterns already used in this repository.
Add a regression test and run the relevant test and build commands.
Do not change dependencies or deployment configuration.

Common Commands

Commands can change. Verify them with amp --help and the current Amp manual.

Command	Purpose
amp	Start or continue an interactive CLI thread
amp -x "task"	Run a task in non-interactive execute mode
amp -ox "task"	Start a task on a managed orb
amp app	Open the web application
amp review	Run Amp’s code-review workflow
amp usage	Inspect usage and cost
amp tools list	List available tools
amp sync <thread>	Synchronize work from a thread
amp update	Update the CLI

Effort Modes

Amp currently exposes four modes. In July 2026, these replaced earlier product-specific mode names.

Mode	Practical use
low	Clear, local, inexpensive tasks such as small edits and routine questions
medium	Default feature work, debugging, and repository exploration
high	Ambiguous or important work that needs more investigation and verification
ultra	The most difficult work where additional latency and cost are acceptable

A mode can bundle model choice, instructions, tool access, and reasoning effort. It should be selected from task risk, not from file count alone.

Use a higher mode when the agent must discover architecture, cross boundaries, or reason about costly failures. Use a lower mode when the transformation is obvious and a deterministic check will catch mistakes quickly.

See Agent Modes and Effort Routing and Amp’s current The Dial explanation.

Repository Instructions With AGENTS.md

Amp reads AGENTS.md files for persistent repository guidance. A root file can explain:

• how the project is structured
• which commands verify a change
• style and architecture conventions
• files that should not be edited
• security or data-handling constraints

Example:

# Repository guidance

- Run `npm test` and `npm run build` before finishing.
- Keep API validation in `src/http/validators`.
- Do not edit generated files in `src/generated`.
- Database changes require a migration and rollback note.

Subtree-specific AGENTS.md files can provide instructions only when Amp works in that part of the repository. This keeps unrelated guidance out of the active context.

Store stable, shared conventions here. Keep task-specific requirements in the task, issue, or thread.

Threads Are The Unit Of Work

An Amp thread preserves prompts, tool calls, results, edits, and follow-up messages. Threads can be resumed, searched, referenced, shared, and controlled from another device.

This is useful for:

• continuing a long task without reconstructing the conversation
• letting another engineer inspect how a change was produced
• reviewing tool output and rejected approaches
• sharing effective agent techniques across a team
• steering local work from web or mobile

Thread history is supporting provenance. The repository, tests, issue tracker, and pull request remain the durable sources of truth.

Visibility needs an explicit check

Amp supports private, unlisted, group, and workspace visibility. The current manual says non-workspace threads default to private, while workspace threads normally default to shared unless an administrator changes that policy.

Before placing proprietary code, customer data, logs, or credentials in a thread, check its actual visibility. Do not infer privacy from the URL being difficult to guess.

Tools, Skills, MCP, And Plugins

These extension layers solve different problems.

Layer	Use it for	Context behavior
Built-in tools	Core file, shell, search, and agent operations	Available as part of the selected mode
Skills	Reusable instructions, scripts, and task-specific knowledge	Skill metadata is discoverable; detailed content loads when needed
MCP servers	External services and data exposed through a standard protocol	Best kept selective or loaded through a relevant skill
Plugins	TypeScript code that adds tools, commands, events, or policies	Runs as code in the Amp process

Amp supports skills in locations such as:

.agents/skills/
~/.config/agents/skills/

A skill can package an mcp.json file so its MCP server and tools remain hidden until that skill is relevant. This is often better than exposing a large catalog of unrelated tools to every request.

Too many tools create several costs:

• tool definitions consume context
• similar tools make selection ambiguous
• every external system adds a trust boundary
• failures become harder to attribute and reproduce

Prefer a small set of high-level, task-oriented tools.

Plugins are trusted code

Amp plugins can register tools and observe or modify agent behavior. A plugin is not just a prompt. It can execute code with the permissions of the Amp process.

Review third-party plugins before installing them, pin or control their source, and avoid loading untrusted plugins in repositories containing valuable credentials.

See the current Plugin API and SDK documentation.

Local Execution, Runners, And Orbs

There are two separate decisions:

1. Where the conversation is controlled.
2. Where tools and code actually execute.

A remote web or mobile interface can control a local runner, so remote control does not necessarily mean the code moved to a managed machine.

An orb is Amp’s managed remote execution environment. It starts a machine for the thread, prepares the code and agent environment, and lets the task continue away from the local laptop. Orbs are useful for:

• long-running work
• parallel tasks
• fresh reproducible environments
• work that should not consume local resources

They also require deliberate secret, network, and data controls. A fresh remote machine is an isolation boundary, not permission to expose production credentials.

Amp announced standalone orb usage at $1.66 per hour, billed by the minute, in June 2026. Current subscriptions also include orb-hour allowances, so use the live pricing page rather than treating the announcement rate as permanent.

Reviewing Changes

Amp’s current workflow includes:

• amp review for a local code review
• natural-language review focused on a specific concern
• repository checks stored in .agents/checks/
• separate review subagents for separate criteria
• diffs and comments in web and mobile thread views
• interactive staging and requests for changes

A good repository check is narrow and evidence-based:

Check whether changed API handlers preserve authentication,
authorization, and error-response conventions. Report only
actionable findings with file and line references.

Run review after deterministic checks, not instead of them. A reviewer model can share the implementation model’s assumptions and miss the same defect.

See Reviewing Agent-Generated Code for the complete workflow.

Pricing

Amp pricing is not directly comparable to one raw model API request because an agent task can include several model calls, tool executions, retries, and remote compute.

The current pricing structure as of July 26, 2026 includes:

Option	Current structure
Pay as you go	Purchase at least $5 in credits; Amp says individual and non-enterprise workspace usage passes through model and tool-provider cost with zero markup
Megawatt	$20 per month; includes $20 of agent usage, low and medium modes, and 750 small-orb hours
Gigawatt	$200 per month; includes $200 of agent usage, all four modes, and 1,000 large-orb hours

The subscription program is in beta and its allowances can change. Check Amp’s live subscription announcement and manual before making a purchasing decision.

Amp credits versus direct model APIs

Amp	Direct OpenAI or Anthropic API
You pay for an agent workflow through Amp credits or a subscription	You pay the model provider for API usage
Amp chooses and can change the model mix behind a mode	Your application selects the provider, model, and parameters
Threads, coding tools, review, remote control, and orbs are integrated	Your application must build or adopt the agent harness, storage, tools, review, and execution environment
One task may trigger many model and tool calls	One API request has explicit input, output, and tool-call billing
Less infrastructure to assemble, but more product dependence	More implementation work, but direct control over architecture and provider contracts

Compare the cost of an accepted task, not the cost of one model call. Include retries, engineer review time, remote compute, and failed attempts.

Security And Privacy

Amp is a high-privilege development tool. Its current behavior deserves explicit attention:

• Amp does not ask for approval before every tool call by default.
• A prompt injection in a repository, issue, webpage, or tool result can influence the agent.
• MCP servers and plugins extend the executable trust boundary.
• Shared threads can expose prompts, tool output, and partial code.
• Remote execution can reach any credential or network resource made available to it.

Use:

• an isolated environment for untrusted repositories or inputs
• least-privilege credentials
• policy plugins or permission controls for dangerous commands
• protected branches and human merge approval
• explicit thread-visibility checks
• normal secret scanning and dependency review

Amp’s security page says its cloud stores account and thread data, including partial code associated with threads, but not a complete copy of the codebase. Teams with contractual, residency, or confidentiality requirements should validate the current policy rather than relying only on this summary.

Current Amp Compared With Earlier Versions

Amp’s interface and product model have changed substantially. Older articles, videos, and screenshots may show behavior that is no longer current:

Earlier Amp behavior	Current Amp direction
A dedicated editor experience was central	Amp retired the old editor extensions and now emphasizes CLI, web/mobile control, and IDE context connections
Modes used names such as Smart, Rush, and Deep	Modes are now low, medium, high, and ultra
MCP was discussed as a source of tool overload	Amp supports MCP, with selective loading and skill packaging recommended
Pricing was primarily usage-credit based	Pay-as-you-go credits remain, and monthly subscriptions are now in beta
Work was mainly shown on a developer machine	Managed orbs and local runners now support remote and background work

The product screens and feature names will continue to change. The useful architectural idea is that agent quality depends on how context, tools, effort, execution, review, and provenance are designed together.

When Amp Fits

Amp is worth considering when you want:

• one coding agent across several model providers
• persistent, shareable threads
• integrated local and remote execution
• first-class review workflows
• web or mobile control of long-running tasks
• an opinionated system instead of building an agent harness

It may be a weaker fit when you need:

• a fully open-source, self-hosted coding agent
• direct control over every model request and system prompt
• strict per-action approval by default
• a workflow that cannot send thread data or partial code to a hosted service
• predictable cost without monitoring multi-step agent usage

Run a trial on representative repository tasks. Measure accepted changes, review effort, escaped defects, latency, and total cost.

Resources

• Amp Code: Next Generation AI Coding - Beyang Liu
• Amp Manual
• The Dial: Current Amp Modes
• Amp Subscriptions
• Agents in Orbs
• Amp Code Review
• Diffs in Amp
• Amp SDK
• Amp Plugin API
• Amp Security
• sourcegraph/amp-examples-and-guides