Congratulations on installing Amp. This manual helps you get the most out of it.

Introduction

What is Amp?

Amp is a frontier coding agent built by Sourcegraph. It runs in VS Code (and compatible forks like Cursor, Windsurf, and VSCodium) and as a command-line tool. It’s also multiplayer — you can share threads and collaborate with your team.

Principles

1. Amp is unconstrained in token usage (and therefore cost). Our sole incentive is to make it valuable, not to match the cost of a subscription.
2. No model selector, always the best models. You don’t pick models, we do. Instead of offering selectors and checkboxes and building for the lowest common denominator, Amp is built to use the full capabilities of the best models.
3. We assume that you want to access the raw power these models have to offer. In a sense, when you’re using Amp, you aren’t using Amp — you’re talking directly to a model and Amp is the shell around your conversation with the model.
4. Built to evolve. Products that lock themselves into specific model behaviors become obsolete in months. We stay current with the best, not tied to the past.

Getting Started

Install

Sign in to ampcode.com and follow the instructions for VS Code, Cursor, and Windsurf to install the extension and authenticate. You can also use the Install button at the bottom of the Amp dashboard for quick access to installation instructions for all platforms.

Command Line Interface

curl -fsSL https://ampcode.com/install.sh | bash

amp

echo "What is today's date?" | amp

echo "what animal is the most disagreeable because it says neigh?" > riddle.txt
cat riddle.txt | amp -x "solve this riddle"

npm install -g @sourcegraph/amp

amp

echo "What is today's date?" | amp

echo "what animal is the most disagreeable because it says neigh?" > riddle.txt
cat riddle.txt | amp -x "solve this riddle"

pnpm add -g @sourcegraph/amp

amp

echo "What is today's date?" | amp

echo "what animal is the most disagreeable because it says neigh?" > riddle.txt
cat riddle.txt | amp -x "solve this riddle"

yarn global add @sourcegraph/amp

amp

echo "What is today's date?" | amp

echo "what animal is the most disagreeable because it says neigh?" > riddle.txt
cat riddle.txt | amp -x "solve this riddle"

npx @sourcegraph/amp

echo "What is today's date?" | npx @sourcegraph/amp

echo "what animal is the most disagreeable because it says neigh?" > riddle.txt
cat riddle.txt | npx @sourcegraph/amp -x "solve this riddle"

For non-interactive environments (e.g. scripts, CI/CD pipelines), you’ll need to export your API key as an environment variable:

export AMP_API_KEY=your-api-key-here

Supported Platforms

Amp officially supports macOS, Linux, and Windows via WSL (Windows Subsystem for Linux). While Amp also works on Windows outside of WSL, this configuration is not officially supported—you may encounter issues, but many users run it successfully.

Using Amp

How to Prompt

Amp currently uses Claude Sonnet 4.5 for most tasks, with up to 1 million tokens of context. For the best results, follow these guidelines:

• Be explicit with what you want. Instead of “can you do X?”, try “do X.”
• Keep it short, keep it focused. Break very large tasks up into smaller sub-tasks, one per thread. Do not ask the agent to write database migrations in the same thread as it previously changed CSS for a documentation page.
• Don’t try to make the model guess. If you know something about how to achieve what you want the agent to do — which files to look at, which commands to run — put it in your prompt.
• If you want the model to not write any code, but only to research and plan, say so: “Only plan how to implement this. Do NOT write any code.”
• Use AGENTS.md files to guide Amp on how to run your tests and build steps and to avoid common mistakes.
• Abandon threads if they accumulated too much noise. Sometimes things go wrong and failed attempts with error messages clutter up the context window. In those cases, it’s often best to start with a new thread and a clean context window.
• Tell the agent how to best review its work: what command or test to run, what URL to open, which logs to read. Feedback helps agents as much as it helps us.

The first prompt in the thread carries a lot of weight. It sets the direction for the rest of the conversation. We encourage you to be deliberate with it. That’s why we use Cmd/Ctrl+Enter to submit a message in Amp — it’s a reminder to put effort into a prompt.

Here are some examples of prompts we’ve used with Amp:

• “Make observeThreadGuidanceFiles return Omit<ResolvedGuidanceFile, 'content'>[] and remove that field from its return value, and update the tests. Note that it is omitted because this is used in places that do not need the file contents, and this saves on data transferred over the view API.” (See Thread)
• “Run <build command> and fix all the errors”
• “Look at <local development server url> to see this UI component. Then change it so that it looks more minimal. Frequently check your work by screenshotting the URL”
• “Run git blame on the file I have open and figure out who added that new title”
• “Convert these 5 files to use Tailwind, use one subagent per file”
• “Take a look at git diff — someone helped me build a debug tool to edit a Thread directly in JSON. Please analyze the code and see how it works and how it can be improved. […]” (See Thread)
• “Check git diff --staged and remove the debug statements someone added” (See Thread)
• “Find the commit that added this using git log, look at the whole commit, then help me change this feature”
• “Explain the relationship between class AutoScroller and ViewUpdater using a diagram”
• “Run psql and rewire all the threads in the databaser to my user (email starts with thorsten)” (See Thread)

Also see Thorsten Ball’s How I Use Amp.

If you’re in a workspace, use Amp’s thread sharing to learn from each other.

AGENTS.md

Amp looks in AGENTS.md files for guidance on codebase structure, build/test commands, and conventions.

Amp includes AGENTS.md files automatically:

• AGENTS.md files in the current working directory (or editor workspace roots) and parent directories (up to $HOME) are always included.
• Subtree AGENTS.md files are included when the agent reads a file in the subtree.
• $HOME/.config/AGENTS.md is always included.

If a file named AGENT.md (without an S) exists in any of those locations, and no AGENTS.md exists, the AGENT.md file will be used for backward compatibility.

In a large repository with multiple subprojects, we recommend keeping the top-level AGENTS.md general and creating more specific AGENTS.md files in subtrees for each subproject.

To see the agent files that Amp is using, run /agent-files (CLI) or hover the X% of 968k indicator after you’ve sent the first message in a thread (editor extension).

Writing AGENTS.md Files

Amp offers to generate an AGENTS.md file for you if none exists. You can create or update any AGENTS.md files manually or by asking Amp (“Update AGENTS.md based on what I told you in this thread”).

To include other files as context, @-mention them in agent files. For example:

See @doc/style.md and @specs/**/*.md.

When making commits, see @doc/git-commit-instructions.md.

• Relative paths are interpreted relative to the agent file containing the mention.
• Absolute paths and @~/some/path are also supported.
• @-mentions in code blocks are ignored, to avoid false positives.
• Glob patterns are supported (such as @doc/*.md or @.agent/**/*.md).

Granular Guidance

To provide guidance that only applies when working with certain files, you can specify globs in YAML front matter of mentioned files.

For example, to apply language-specific coding rules:

1. Put See @docs/*.md anywhere in your AGENTS.md file.

2. Create a file docs/typescript-conventions.md with:

   ---
   globs:
     - '**/*.ts'
     - '**/*.tsx'
   ---
   
   Follow these TypeScript conventions:
   
   - Never use the `any` type
   - ...

3. Repeat for other languages.

Mentioned files with globs will only be included if Amp has read a file matching any of the globs (in the example above, any TypeScript file). If no globs are specified, the file is always included when @-mentioned.

Globs are implicitly prefixed with **/ unless they start with ../ or ./, in which case they refer to paths relative to the mentioned file.

Other examples:

• Frontend-specific guidance: globs: ["src/components/**", "**/*.tsx"]
• Backend guidance: globs: ["server/**", "api/**"]
• Test guidance: globs: ["*.test.ts", "__tests__/*"]

Uploading Images

Amp supports image uploads, allowing you to share screenshots, diagrams, and visual references with the AI. Images can provide important context for debugging visual issues or understanding UI layouts.

In the editor extension, you can:

• Paste images directly into the input
• Hold Shift and drag images over the input
• Mention images by file path

In the CLI, you can:

• Drag images into the terminal (and paste them if the image is copied from a file)
• Mention images by file path

Thinking Hard

If Extended Thinking is enabled (it is by default), Amp can dynamically adjust the thinking budget given to Claude Sonnet 4.5. The higher the budget, the more tokens it uses to “think”.

If you tell the model to “think hard” (or “think a lot” and variations) the thinking budget will be more than doubled.

If you tell the model to “think really hard” (or “think very hard”) it will be increased even more.

Mentioning Files

You can mention files directly in your prompts by typing @ followed by a pattern to fuzzy-search. It can help speed up responses by avoiding the need to search the codebase.

Queueing messages

You can queue messages to be sent to the agent once it ends its turn.

That way you can already send a message to, for example, ask the agent to perform a follow-up task without interrupting what it’s currently doing.

In the editor extension:

• Press Cmd-Shift-Enter (macOS) or Ctrl-Shift-Enter (Windows/Linux) to queue your input instead of sending it.
• Queued messages appear below the thread. Click a queued message to restore it to the editor, or use the × button to remove it.
• Up to 5 messages can be queued per thread.

In the CLI, you can use the /queue [message] command to enqueue a message and /dequeue to dequeue all enqueued messages.

CLI

After installing and logging in, run amp to start the Amp CLI.

Without any arguments, it runs in interactive mode:

$ amp

If you pipe input to the CLI, it uses the input as the first user message in interactive mode:

$ echo "commit all my changes" | amp

Use -x or --execute to start the CLI in execute mode. In this mode, it sends the message provided to -x to the agent, waits until the agent ended its turn, prints its final message, and exits:

$ amp -x "what files in this folder are markdown files? Print only the filenames."
README.md
AGENTS.md

You can also pipe input when using -x:

$ echo "what package manager is used here?" | amp -x
cargo

If you want to use -x with the agent using tools that might require approval, make sure to either use --dangerously-allow-all or configure Amp to allow them:

$ amp --dangerously-allow-all -x "Run `sed` to replace 2024 with 2025 in README."
Done. Replaced 8 occurrences of 2024 in README.md

Execute mode is automatically turned on when you redirect stdout:

$ echo "what is 2+2?" | amp > response.txt

When you pipe input and provide a prompt with -x, the agent can see both:

$ cat ~/.vimrc | amp -x "which colorscheme is used?"
The colorscheme used is **gruvbox** with dark background and hard contrast.

```vim
set background=dark
let g:gruvbox_contrast_dark = "hard"
colorscheme gruvbox
```

You can use the --mcp-config flag with -x commands to specify an MCP server without modifying your configuration file.

$ amp --mcp-config '{"everything": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-everything"]}}' -x "What tools are available to you?"

To see more of what the CLI can do, run amp --help.

Slash Commands

The Amp CLI supports slash commands. Type / followed by the name of a command to execute it.

• /help - Show help and hotkeys
• /new - Start a new thread
• /continue - Continue an existing thread
• /queue [message] - Queue a message to send when inference completes
• /dequeue - Dequeue all messages and restore them to the prompt editor
• /generate-agent-file - Generate an AGENTS.md file in the current workspace
• /agent-files - List AGENTS.md guidance files in use for the current thread
• /compact - Compact the thread to reduce context usage
• /editor - Open your $EDITOR to write a prompt
• /permissions - Edit permission rules in $EDITOR
• /quit - Exit Amp

Custom Slash Commands

You can also create your own, custom slash commands. They allow you to reuse prompts or dynamically generate them.

To create a custom slash command, create a Markdown file or an executable in one of the following locations:

• .agents/commands in the current workspace
• ~/.config/amp/commands (uses the $XDG_CONFIG_HOME directory if set)

Each file in these directories, if it’s a Markdown file ending in .md or an executable file (having the execute bit set or a shebang on the first line), will be turned into a slash command. The name of the slash command will be the filename without the extension.

Custom slash commands based on Markdown files will, when invoked, insert the contents of the file into the prompt input.

Custom slash commands based on executable files will execute the file and the combined stdout/stderr output of the file (max 50k characters) will be sent as a user message. Slash commands based on executables can also take arguments which will then be passed to the executable when it’s invoked.

Here are two examples:

• The file .agents/commands/pr-review.md will be turned into the slash command /pr-review and the contents of pr-review.md will be inserted into the prompt input.
• ~/.config/amp/commands/outline is an executable that will be turned into the slash command /outline and can be used with arguments: /outline src/utils

And here are real-world examples that you can take a closer look at:

• work-on-linear-issue
• resolve-pr-comments
• code-review.md

Shell Mode

Execute shell commands directly in the CLI by starting your message with $. The command and its output will be included in the context window for the next message to the agent.

Use $$ to activate incognito shell mode, where commands execute but aren’t included in the context. This is useful for noisy commands or quick checks you’d normally run in a separate terminal.

Writing Prompts in the CLI

In modern terminal emulators, such as Ghostty, Wezterm, Kitty, or iTerm2, you can use shift-enter to insert a newline in your prompts.

Additionally you can also use type \ followed by return to insert a newline.

If you have the environment variable $EDITOR set, you can use the /editor slash command to open your editor to write a prompt.

Streaming JSON

Amp’s CLI supports streaming JSON output format, one object per line on stdout, for programmatic integration and real-time conversation monitoring.

Use the --stream-json flag with --execute mode to output in stream JSON format instead of plain text.

Basic usage with argument:

$ amp --execute "what is 3 + 5?" --stream-json

Combining —stream-json with amp threads continue:

$ amp threads continue --execute "now add 8 to that" --stream-json

With stdin input:

$ echo "analyze this code" | amp --execute --stream-json

You can find the schema for the JSON output in the Appendix.

Input can be also be provided on stdin with the --stream-json-input flag:

$ echo '{
  "type": "user",
  "message": {
    "role": "user",
    "content": [
      {
        "type": "text",
        "text": "what is 2+2?"
      }
    ]
  }
}' | amp -x --stream-json --stream-json-input

The --stream-json flag requires --execute mode. It cannot be used standalone. And --stream-json-input requires --stream-json.

When using --stream-json-input, the behavior of --execute changes in that Amp will only exit once both the assistant is done and stdin has been closed.

This allows for programmatic use of the Amp CLI to have conversations with multiple user messages.

#!/bin/bash

send_message() {
  local text="$1"
  echo '{"type":"user","message":{"role":"user","content":[{"type":"text","text":"'$text'"}]}}'
}

{
  send_message "what's 2+2?"
  sleep 10

  send_message "now add 8 to that"
  sleep 10

  send_message "now add 5 to that"
} | amp --execute --stream-json --stream-json-input

See the Appendix for the schema of the output, example output, and more usage examples.

Keyboard Shortcuts

Shortcuts for macOS and VS Code

Shortcuts for macOS and Cursor

Shortcuts for macOS and Windsurf

Shortcuts for Windows and VS Code

Shortcuts for Windows and Cursor

Shortcuts for Windows and Windsurf

Shortcuts for Linux and VS Code

Shortcuts for Linux and Cursor

Shortcuts for Linux and Windsurf

Customize Layout in Cursor

Third party extensions are automatically placed in the primary sidebar in Cursor. To customize the position of Amp in Cursor please follow these steps:

• Open the Command Pallete using Ctrl/⌘ + Shift + P
• Search for View: Move View
• Select Amp from the drop down list
• Choose your desired location (New Panel Entry and New Secondary Side Bar Entry are the most common)

Threads

Threads are conversations with the agent, containing all your messages, context, and tool calls. Your threads are synced to ampcode.com. If you’re in a workspace, your threads are also shared with your workspace by default, just like Git branches on a shared remote repository.

Including links to Amp threads with your changes when submitting for code review helps provide context. Reading and searching your workspace’s threads can help you see what’s going on and how other people are using Amp.

Privacy & Permissions

Threads can be public (visible to anyone on the internet with the link), workspace-shared (visible to your workspace members), or private (visible only to you).

If you’re in a workspace, your threads are shared by default with your workspace members.

If you are not in a workspace, your threads are only visible to you by default.

You can change a thread’s visibility at any time through the sharing menu at the top of the thread.

Managing Context

As you work with Amp, your thread accumulates context within the model’s context window. Amp shows your context window usage and warns when approaching limits.

When approaching the thread context limit, you can hover over the context window indicator and use the following:

• Compact Thread — Summarizes the existing conversation to reduce context usage while preserving important information
• New Thread with Summary — Creates a new thread that starts with a summary of the current conversation

File Changes

Amp tracks changes that the agent makes to files during your conversation, which you can track and revert:

• Hover over the files changed indicator (located just above the message input) to see which files were modified and by how much
• Revert individual file changes, or all changes made by the agent

Editing a message in a thread automatically reverts any changes the agent made after that message

Amp Tab

Amp Tab is our in-editor completion engine, designed to anticipate your next actions and reduce the time spent manually writing code.

It uses a custom model that was trained to understand what you are trying to do next, based on your recent changes, your language server’s diagnostics, and what we call semantic context.

Amp Tab can suggest regular single or multi-line edits to change entire code blocks, next to your cursor, further away in the document or even in other files.

Enabling

Enable Amp Tab by setting "amp.tab.enabled": true in your editor settings.

How to Use

• Begin typing in your editor. Amp Tab automatically presents relevant suggestions.
• Press the Tab key to accept and apply the suggested edits.
• Press the Tab key again to instantly jump to additional edits further from your cursor.
• If you get a suggestion to jump to another file, press the Tab key to preview the file and then press Tab again to jump to it.
• To ignore suggestions, simply continue typing or press Esc.

If you’re using Vim extensions in VS Code and need to press Esc twice to dismiss suggestions and enter normal mode, configure amp.tab.dismissCommandIds to specify which commands should run on Esc. Defaults cover popular extensions like VSCodeVim and vscode-neovim.

Currently, Amp Tab is free to use as a research preview for all Amp users.

Workspaces

Workspaces provide collaborative environments where knowledge can be shared across your organization. Create a workspace from the settings page.

To join a workspace, you need an invitation from an existing workspace member. Enterprise workspaces can also enable SSO to automatically include workspace members.

Sharing

Workspace threads are visible to all workspace members by default, making it easy to learn from others and build on their work.

See Privacy & Permissions for all thread visibility options.

Note that Enterprise workspaces can configure additional sharing controls - see Workspace Thread Visibility Controls for more details.

Workspace Usage

Workspaces provide pooled billing of usage, making it easier to manage costs across your organization. If a member of your workspace joins with free personal usage available, their free usage will be used before the paid workspace usage.

To learn more, refer to the pricing section.

Leaderboard

Each workspace includes a leaderboard that tracks thread activity and contributions from workspace members, encouraging engagement and highlighting active participants.

Tools

Tools are what the underlying model uses to assist with tasks. For the highest quality results we recommend you use a curated set of tools, with prompts adjusted to fit the underlying model.

Built-in Tools

Amp comes with a curated set of built-in tools specifically designed for coding. You can find the list of built-in tools inside Amp’s extension settings.

Custom Tools (MCP)

You can add additional tools using MCP (Model Context Protocol) servers, which can be either local or remote. These can be configured in amp.mcpServers in your configuration file. You can also press + Add MCP Server under Settings in the VS Code.

Configuration options for local MCP servers:

• command - executable
• args - command arguments (optional)
• env - environment variables (optional)

Configuration options for remote (HTTP/SSE) MCP servers:

• url - server endpoint
• headers - HTTP headers to send with requests (optional)

Amp automatically detects the appropriate transport type (HTTP or SSE) based on the server’s response headers.

If the remote MCP server requires authorization with OAuth, you can use either use mcp-remote or pass authentication headers directly via the headers option.

Example configuration:

"amp.mcpServers": {
    "playwright": {
        "command": "npx",
        "args": ["-y", "@playwright/mcp@latest", "--headless", "--isolated"]
    },
    "semgrep": {
        "url": "https://mcp.semgrep.ai/mcp"
    },
    "sourcegraph": {
        "url": "https://sourcegraph.example.com/.api/mcp/v1",
        "headers": {
            "Authorization": "token sgp_your-token-here"
        }
    },
    "linear": {
        "command": "npx",
        "args": [
            "mcp-remote",
            "https://mcp.linear.app/sse"
        ]
    },
    "monday": {
        "url": "https://mcp.monday.com/sse",
        "headers": {
            "Authorization": "Bearer your-token-here"
        }
    }
}

You can also add MCP servers using the CLI with header options:

$ amp mcp add sourcegraph --header "Authorization=token sgp_your-token-here" https://sourcegraph.example.com/.api/mcp/v1

Too many available tools can reduce model performance, so for best results, be selective:

• Use MCP servers that expose a small number of high-level tools with high-quality descriptions.
• Disable MCP tools that you aren’t using, by hovering over a tool name in the extension’s Settings interface and clicking so it’s shown as tool_name, or by adding them to amp.tools.disable in your configuration file.
• Consider using CLI tools instead of MCP servers.

Amp also supports MCP prompts and resources, both available under the @ mentions menu.

Toolboxes

Toolboxes allow you to extend Amp with simple scripts instead of needing to provide an MCP server.

When Amp starts it invokes each executable in the directory indicated by AMP_TOOLBOX, with the environment variable TOOLBOX_ACTION set to describe.

The tool is expected to write its description to stdout as a list of key-value pairs, one per line.

#!/usr/bin/env bun

const action = process.env.TOOLBOX_ACTION

if (action === 'describe') showDescription()
else if (action === 'execute') runTests()

function showDescription() {
	process.stdout.write(
		[
			'name: run-tests',
			'description: use this tool instead of Bash to run tests in a workspace',
			'dir: string the workspace directory',
		].join('\n'),
	)
}

When Amp decides to use your tool it runs the executable again, setting TOOLBOX_ACTION to execute.

The tool receives parameters in the same format on stdin and then performs its work:

function runTests() {
	let dir = require('fs')
		.readFileSync(0, 'utf-8')
		.split('\n')
		.filter((line) => line.startsWith('dir: '))

	dir = dir.length > 0 ? dir[0].replace('dir: ', '') : '.'

	require('child_process').spawnSync('pnpm', ['-C', dir, 'run', 'test', '--no-color', '--run'], {
		stdio: 'inherit',
	})
}

If your tool needs object or array parameters, the executable can write its tool schema as JSON instead to stdout. In this case it’ll also receive inputs as JSON.

We recommend using tools to express specific, deterministic and project-local behavior, like:

• querying a development database,
• running test and build actions in the project,
• exposing CLIs tools in a controlled manner.

See the Appendix for the full technical reference.

Permissions

Before invoking a tool, Amp checks the user’s list of permissions for the first matching entry to decide whether to run the tool.

If no match is found, Amp scans through its built-in permission list, rejecting the tool use in case no match is found there either.

The matched entry tells Amp to either allow the tool use without asking, reject the tool use outright, ask the operator, or delegate the decision to another program.

Permissions are configured in your configuration file under the entry amp.permissions:

"amp.permissions": [
  // Ask before running command line containing git commit
  { "tool": "Bash", "matches": { "cmd": "*git commit*" }, "action": "ask"},
  // Reject command line containing python or python3
  { "tool": "Bash", "matches": { "cmd": ["*python *", "*python3 *"] }, "action": "reject"},
  // Allow all playwright MCP tools
  { "tool": "mcp__playwright_*", "action": "allow"},
  // Ask before running any other MCP tool
  { "tool": "mcp__*", "action": "ask"},
  // Delegate everything else to a permission helper (must be on $PATH)
  { "tool": "*", "action": "delegate", "to": "my-permission-helper"}
]

Using in VS Code

Complex objects must be configured in VS Code’s Settings JSON.

A JSON schema for permissions is integrated into VS Code to offer guidance when editing permissions.

Rules with action ask only work for the Bash tool in VS Code.

Using in the CLI

Using amp permissions edit you can edit your permissions rules programmatically and interactively using $EDITOR.

The amp permissions test command evaluates permission rules without actually running any tools, providing a safe way for verifying that your rules work as intended.

$ amp permissions edit <<'EOF'
allow Bash --cmd 'git status' --cmd 'git diff*'
ask Bash --cmd '*'
EOF
$ amp permission test Bash --cmd 'git diff --name-only'
tool: Bash
arguments: {"cmd":"git diff --name-only"}
action: allow
matched-rule: 0
source: user
$ amp permission test Bash --cmd 'git push'
tool: Bash
arguments: {"cmd":"push"}
action: ask
matched-rule: 1
source: user

Running amp permissions list displays known permissions rules in the same format understood by amp permissions edit:

$ amp permissions list
allow Bash --cmd 'git status' --cmd 'git diff*'
ask Bash --cmd '*'

Refer to the output of amp permissions --help for the full set of available operations.

Delegating the decision to an external program

For full control, you can tell Amp to consult another program before invoking a tool:

{ "action": "delegate", "to": "amp-permission-helper", "tool": "Bash" }

Now every time Amp wants to run a shell command, it will invoke amp-permission-helper:

#!/usr/bin/env python3
import json, sys, os

tool_name = os.environ.get("AGENT_TOOL_NAME")
tool_arguments = json.loads(sys.stdin.read())

# allow all other tools
if tool_name != "Bash":
    sys.exit(0)

# reject git push outright - stderr is passed to the model
if 'git push' in tool_arguments.get('cmd', ''):
    print("Output the correct command line for pushing changes instead", file=sys.stderr)
    sys.exit(2)

# ask in any other case
sys.exit(1)

The error code and stderr are used to tell Amp how to proceed.

See the Appendix for the full technical reference.

Subagents

Amp can spawn subagents (via the Task tool) for complex tasks that benefit from independent execution. Each subagent has its own context window and access to tools like file editing and terminal commands.

Subagents are most useful for multi-step tasks that can be broken into independent parts, operations producing extensive output not needed after completion, parallel work across different code areas, and keeping the main thread’s context clean while coordinating complex work.

However, subagents work in isolation — they can’t communicate with each other, you can’t guide them mid-task, they start fresh without your conversation’s accumulated context, and the main agent only receives their final summary rather than monitoring their step-by-step work.

Amp may use subagents automatically for suitable tasks, or you can encourage their use by mentioning subagents or suggesting parallel work.

Oracle

Amp has access to a powerful “second opinion” model that’s better suited for complex reasoning or analysis tasks, at the cost of being slightly slower, slightly more expensive, and less suited to day-to-day code editing tasks than the main agent’s model.

This model is available to Amp’s main agent through a tool called oracle, and it currently uses GPT-5.

The main agent can autonomously decide to ask the oracle for help when debugging or reviewing a complex piece of code. We intentionally do not force the main agent to always use the oracle, due to higher costs and slower inference speed.

We recommend explicitly asking Amp’s main agent to use the oracle when you think it will be helpful. Here are some examples from our own usage of Amp:

• “Use the oracle to review the last commit’s changes. I want to make sure that the actual logic for when an idle or requires-user-input notification sound plays has not changed.”
• “Ask the oracle whether there isn’t a better solution.”
• “I have a bug in these files: … It shows up when I run this command: … Help me fix this bug. Use the oracle as much as possible, since it’s smart.”
• “Analyze how the functions foobar and barfoo are used. Then I want you to work a lot with the oracle to figure out how we can refactor the duplication between them while keeping changes backwards compatible.”

IDE CLI Integration

The Amp CLI can connect directly to your IDE using the --ide flag for Neovim and VS Code, and --jetbrains for JetBrains IDEs.

Features:

• View current file and selected code — Amp can see which files are open and what code you have selected
• Direct file editing — Reading and writing files through your IDE with full undo support
• Diagnostics integration — Access to build errors and IDE insights

Requirements:

• Latest version of the Amp CLI
• Node.js 21+

Visual Studio Code

Run amp --ide from your project root with the Amp VS Code extension installed. The CLI will connect to the IDE in the current workspace.

Neovim

Run amp --ide from your project root with the Neovim plugin installed. The CLI will connect to the IDE in the current workspace.

JetBrains IDEs

Run amp in the integrated JetBrains terminal, or amp --jetbrains anywhere else. After installing the plugin and restarting your IDE, you can launch Amp by clicking on the Amp logo in your JetBrains toolbar, or by going to Tools > Start Amp. The --jetbrains flag is active by default in the IDE terminal.

Supports all JetBrains IDEs (IntelliJ, WebStorm, GoLand, etc.).

Requirements:

• JetBrains IDE 2025.1+. We recommend 2025.2.2+ for the best CLI experience.

Configuration Settings

Amp can be configured through settings in your editor extension (e.g. .vscode/settings.json) and the CLI configuration file.

The CLI configuration file location varies by operating system:

• Windows: %APPDATA%\amp\settings.json
• macOS: ~/.config/amp/settings.json
• Linux: ~/.config/amp/settings.json

All settings use the amp. prefix.

Settings

Editor Extension and CLI

Editor Extension Only

CLI only

Enterprise managed settings

Enterprise workspace administrators can enforce settings that override user and workspace settings by deploying their policies to the following locations on machines running Amp:

• macOS: /Library/Application Support/ampcode/managed-settings.json
• Linux: /etc/ampcode/managed-settings.json
• Windows: C:\ProgramData\ampcode\managed-settings.json

This managed settings file uses the same schema as regular settings files, with one additional field:

Proxies and Certificates

When using the Amp CLI in corporate networks with proxy servers or custom certificates, set these standard Node.js environment variables in your shell profile or CI environment as needed:

export HTTP_PROXY=your-proxy-url
export HTTPS_PROXY=your-proxy-url
export NODE_EXTRA_CA_CERTS=/path/to/your/certificates.pem

Account

Security

See the Amp Security Reference document.

Signup Restrictions

If you see a “Signup is restricted” message, this likely means we cannot provide access to your region due to US export restrictions. Amp is available in most countries worldwide, but we cannot provide access to countries under US embargo to comply with applicable laws. If you believe this is a mistake, please contact [email protected].

Support & Community

Join the Amp Discord to connect with the Amp team and other Amp users, share tips and tricks, and get help from the community.

For billing questions, contact [email protected].

Pricing

Prepay only

Amp uses prepaid credits. You’ll never be charged more than you prepay — unless you turn on auto-reload.

Usage

Upon signing up, most users get $10 USD in free usage. You can purchase more as an individual or for your team. Unused credits expire after one year of account inactivity.

Usage is consumed based on LLM usage and usage of certain other tools (like web search) that cost us to serve. We pass these costs through to you directly with no markup, for individuals and non-enterprise workspaces.

Workspace usage is pooled and shared by all workspace members.

Enterprise

Enterprise usage is 50% more expensive than individual and team plans, and includes access to:

• SSO (Okta, SAML, etc.) and directory sync
• Zero data retention for text inputs in LLM inference
• Advanced thread visibility controls
• Managed user settings
• Configurable thread retention (on request)
• Support for user groups for cost attribution and per-group thread visibility options (on request)
• APIs for workspace analytics and data management (on request)
• IP allowlisting for workspace access (on request)

For more information about Amp Enterprise security features, see the Amp Security Reference.

To start using Amp Enterprise, go to your workspace and click “Change Plan” in the top right corner. This requires a special one-time $1,000 USD purchase, which grants your workspace $1,000 USD of Amp Enterprise usage and upgrades your workspace to Enterprise.

With Amp Enterprise Premium, invoice payments are offered for purchases of $5,000+ USD, and volume discounts are available for purchases of $25,000+ USD. Contact [email protected] for access to these purchasing options and for general information about Amp Enterprise.