We're releasing a new version of our agent mode rush.

Prior to this change, rush’s usefulness was limited. It was faster and cheaper, but also made more mistakes and required more attempts to get to the same results than a slower and ultimately not that much more expensive frontier model.

Now, rush is tuned to lean into its advantages — speed, low cost — instead of trying to make up for its shortcomings.

It uses GPT-5.5 with no reasoning instead of Haiku 4.5. It is tuned for small coding tasks that don’t require contemplating the whole repo, but to find the relevant files, make the smallest correct change, run a focused check, and stop.

This is what rush is good at:

“Fix the failing renders empty state test.”

“Update @src/components/ui/Select.tsx to match the focus-ring styling in @src/components/ui/Button.tsx”

“Rename enableLegacySearch to enableSearchV2 in all files that use it”

Do not use rush for transient bugs, architecture changes, migrations, complex features, and tasks where you do not yet know what “done” means. In those cases, reading more, thinking longer, and building a larger model of the codebase is what gets you good results. Use smart or deep for those.

What Changed

The previous system prompt in rush mode was “speed first.” It told the model to move fast, keep explanations short, edit, verify, and stop. With GPT-5.5, we can be more precise: gather only the context needed to act safely, make the smallest correct change, verify narrowly, and stop. This makes it less prone to save time by skipping the parts that make the result usable and to over-contextualize - to keep reading and thinking.

rush now uses shell_command for searching, reading, and verification, and apply_patch for edits. That means we can remove quite a few tools that all do almost the same thing - grep, glob, and create_file.

The task subagents have the same configuration as the main agent: no reasoning, GPT 5.5.

Evals

On our internal evals, rush solved 44% of tasks, up from 39% for the previous version.

The cost moved up slightly: $0.58 per task on average, compared to $0.44 for the previous version (an 18% increase).

The speed changed much more. Rush 2.0 finished in 1 minute and 32 seconds on average, down from 2 minutes and 59 seconds.

That is the tradeoff we wanted: a little more expensive, meaningfully more capable, and almost twice as fast.

It is not deep. On the same evals, deep solved 58% of tasks, 14 points higher than rush.

Pair It with the Oracle

The best pattern we have found is rush plus the oracle.

Let rush build. Ask the oracle to plan, criticize, or review. The oracle is slower and more expensive, but it is read-only and good at adversarial thinking.

This works especially well for tasks that are still bounded, but not trivial. You know the area of the codebase. You know roughly what needs to change. But there is enough surface area that a second, more deliberate pass can prevent rush from making the locally obvious but globally wrong edit.

Try prompts like:

“Ask the oracle to inspect @src/billing/applySeatLimit.ts, @src/billing/planLimits.ts, and the failing seat limit is enforced after downgrade test. Have it propose the concrete fix first: which behavior should change, which file should own the rule, and what should stay untouched. Then implement the smallest patch and run the billing tests.”

“Update the workspace invite flow so expired invites show the same error state in @src/routes/invites/AcceptInvitePage.tsx and @src/components/invites/InviteBanner.tsx. After the patch, ask the oracle to review the diff and suggest the focused tests or manual checks that would actually prove this works. Run the relevant ones before calling it done.”

“Before changing the caching behavior in @src/search/useSearchResults.ts, ask the oracle for two or three implementation options beyond the obvious one. Have it judge them in context of the codebase: consistency with the existing query hooks, risk of stale data, complexity, and testability. Then implement the best minimal option.”

To use it: run mode: use rush in the Amp CLI.

Original source

We're now shipping the Amp CLI as a single-file executable (compiled by Bun) instead of as a JavaScript source package. This makes Amp faster and more compatible across platforms and runtimes, and it's necessary to support Amp plugins.

If you're using the recommended direct installation, nothing changes for you. You've been using this single-file executable for several months. You can stop reading here.

If you've installed Amp via npm, you should switch to direct installation:

npm uninstall -g @sourcegraph/amp
curl -fsSL https://ampcode.com/install.sh | bash

(See all installation methods.)

If you need to keep using npm to install Amp, usually because your company has an internal npm mirror/archive, be aware of some changes:

The CLI's npm package will now contain the executable instead of sources.

We're renaming 2 npm packages:

• The Amp CLI is now @ampcode/cli (was @sourcegraph/amp)
• The Amp TypeScript SDK is now @ampcode/sdk (was @sourcegraph/amp-sdk)

The old package names are aliases but will be removed on June 15, 2026.

Original source

Today we're starting to roll out the new Amp.

Not all of it, not yet. But the first piece: a rebuilt Amp CLI. Codename: Neo.

In The Coding Agent is Dead we wrote about where this is going: agents with longer leashes, less handholding, and many more places to run. Not just one agent in one terminal. Agents prompted from anywhere, running everywhere.

That's the new Amp we're building.

But the terminal still matters and will matter. There will be moments where you want the agent right next to you.

So we rebuilt the CLI first. It is still Amp in your terminal. But it's running on a completely new architecture: remote-controllable, compaction-first, plugin-powered, and much faster. Built for what's coming.

Let's walk through it.

Remote Control

When you start a thread in the new Amp CLI, you can now remote control it from ampcode.com.

You'll not only get live updates but you can also send messages, queue and dequeue them, or cancel what the agent is currently doing:

The architecture that enables this is the reason we rewrote Amp. And remote control is just the start.

No More Manual Context Management

A core principle behind the rebuild: build for what the frontier models can do now, in 2026, and what they will be able to do in the future. Do not build for what once was.

Today's leading frontier models are great at handling compaction.

So Amp now manages context for you.

You don't have to watch context percentages anymore, or decide when to handoff, or extract information from a thread in a panic.

When the context window fills up, Amp now compacts the thread: it summarizes the current context, starts a fresh window with that summary, and keeps going.

Compaction now runs automatically when the context window is 90% full.

It was also the first thing we added to the new architecture. During one migration, we had to shut it off for a day and everyone complained. One beta-user reported: "I love having auto-compaction. NOT missing handoff..."

So handoff is out. Compaction is in.

Plugins

With this release we're officially releasing the Amp Plugin API.

Amp plugins can:

• Handle events — amp.on(...) for tool calls, tool results, and agent lifecycle events
• Add tools — amp.registerTool(...) for custom tools the agent can call
• Add commands — amp.registerCommand(...) for command palette actions
• Show UI elements — ctx.ui.notify(...), ctx.ui.confirm(...), ctx.ui.input(...), and ctx.ui.select(...)
• Ask AI questions — amp.ai.ask(...) for yes/no classification with confidence and reasoning

Here, for example, is a plugin that registers a tool called ask_user_choice. The agent can use it to present the user with options:

// .amp/plugins/ask-user-choice.ts
import type { PluginAPI } from '@ampcode/plugin'
export default function (amp: PluginAPI) {
amp.registerTool({
name: 'ask_user_choice',
description:
'Present the user with a multiple choice question when there are several possible approaches and you need them to pick one. Use when you have 2-5 concrete options to choose from.',
inputSchema: {
type: 'object',
properties: {
question: { type: 'string', description: 'The question to ask the user' },
options: {
type: 'array',
items: { type: 'string' },
description: 'The options to choose from (2-5 items)',
},
},
required: ['question', 'options'],
},
async execute(input, ctx) {
const question = input.question as string
const options = input.options as string[]
const optionsList = options.map((opt, i) => `${i + 1}. ${opt}`).join('\n')
const answer = await ctx.ui.input({
title: question,
helpText: `${optionsList}\n\nType the number of your choice`,
submitButtonText: 'Select',
})
if (!answer) return 'User dismissed the question without choosing.'
const index = parseInt(answer.trim(), 10) - 1
if (index >= 0 && index < options.length) {
return `User selected option ${index + 1}: ${options[index]}`
}
return `User responded with: ${answer}`
},
})
}

That's it: a single file in .amp/plugins and Amp gets a new tool. It looks like this:

The Amp Plugin API documentation has more examples, including a full permissions plugin.

Queuing & Steering

Queuing messages is now the default. When you send a message while the agent is busy, it'll get added to the queue instead of stopping and interrupting the agent.

This, too, we think fits the models of today and tomorrow better. They work for longer and need fewer mid-flight yanks.

If you want to fast-track a queued message, you can steer.

Steering lets you send a queued message as soon as possible, not just when the agent becomes idle. The next time a tool result is sent up to the agent, for example.

Use ↑ to select a queued message, then steer it with ⏎:

You can also hit Esc Esc to interrupt the agent and send immediately.

Permissions

Amp will no longer ask for permission before running tools.

What was once the --dangerously-allow-all flag is now the default behavior for users who have not configured permissions.

The old permissions system still exists. It's now a built-in plugin. If your existing Amp settings already opt into permissions — through amp.permissions, amp.dangerouslyAllowAll: false, or amp.guardedFiles.allowlist — Amp loads that plugin and works as before. (When the plugin is active, it applies in both amp and amp --execute.)

Why change the default?

A year ago tool calls were simpler to check: inspect the name, inspect the arguments, do string-based matching, allow or deny. Now, frontier models write throwaway scripts to get stuff done. They chain shell commands.

It's near-impossible to determine statically whether a tool invocation will be destructive or not.

When a model writes five 20-line Python scripts in parallel to do something, checking whether a tool call contains rm -rf gives you a false sense of security.

On top of that, there are now custom skills and scripts, specifically built for agents. And different organizations have different policies around which model is allowed to call which tool.

So permissions now live in the Plugin API.

If you need a policy, build the one that matches your setup. Point Amp at the Amp Plugin API and ask it to help you.

Performance & Efficiency

The old Amp CLI got slow with huge threads. Neo doesn't. Here's a comparison, using a thread with around 5000 messages:

Metric

Old

New

Improvement

CPU% (mean ± sd)

84.1% ± 1.6%

17.4% ± 8.8%

79% less CPU

CPU% (peak)

86.3%

25.8%

—

Memory (idle)

1814 MB

540 MB

70% less memory

Rendering performance has improved, too.

Before:

After:

What's Gone

We also removed features. Of course we did, otherwise it wouldn't be an Amp release, would it?

Our goal is to keep you on the frontier. Amp should not make you work like it's still 2025.

Some features made sense when models needed more babysitting, more manual context management, more careful steering. They don't anymore. When a feature starts tying you to the old way to use agents, it goes.

Handoff is gone. As described above, compaction made it obsolete. There are some valid use cases for Handoff even when there's enough space left in the context, but we don't think it warrants the complexity introduced by many small, connected threads.

You can also still reference other threads and Amp will read them and extract the relevant information.

For example, you can use Ctrl+O and thread: new to create a new thread, then hit Enter to quickly insert a reference to the previous thread. Amp will use that reference along with the rest of your prompt to read the previous thread.

Amp no longer rolls back file changes when you edit or restore a message.

We've found ourselves using this less and less as models advanced. The models are now good enough to undo changes for you, with more finesse than a rollback.

And, the truth is, the rollback feature was always best-effort: if the agent wrote and ran code that generated files, we didn't keep track of that without elaborate snapshotting.

Skill management: Amp still supports Agent Skills but we no longer offer commands or subcommands to add, remove, or update skills. That's better done by separate tools, such as skills.

User-invokable skills: We also removed support for user-invokable skills. The latest generation of models now invokes skills reliably.

Themes: Custom themes made it harder to keep the CLI legible, polished, and recognizably Amp. We’d rather ship one good interface than support many broken-looking ones.

Manual bash invocation: in the old Amp CLI you could invoke bash commands by using $ and $$ in the prompt editor. An interesting idea a year ago, but now with models being ever more capable at running commands on their own and without blowing up their context window (and that context window being unlimited, practically) it's no longer useful.

Rollout

We’re rolling Neo out over the next several days. If you want to skip the line, send us an email. We'll flip the switch for you. (Update 2026-05-12: We've briefly paused adding more people to the Neo beta as we fix some bugs.)

This is the first piece of the new Amp.

More soon.

Original source

GPT-5.5 now powers Amp's deep mode.

It is a better coding agent than GPT-5.4: more steerable, more interactive, and better at staying inside constraints.

More Agent-Shaped

GPT-5.5 is better at the actual agent loop: read enough code, make the change, verify it, explain what happened. Whereas with GPT-5.4, prompts often had to spell out the process.

With GPT-5.5 we found it's best to clearly describe the outcome and put the rules and repeatable steps into the guidance files and tools.

If the task is vague, it can still solve the wrong problem cleanly. Good prompts matter more, not less.

Reasoning Effort

With GPT-5.5 we lowered deep's default effort from high to medium (deep²).

Do not assume higher reasoning is always better: in our eval, GPT-5.5 high cost more than medium and performed worse.

xhigh (deep³) is for cases where maximum quality matters more than cost.

As before, you can toggle the thinking effort directly in the CLI with Opt+D (Alt+D), cycling through low (deep), medium, and xhigh.

How To Use It

The most important guideline to follow: tell GPT-5.5 what success looks like.

A few patterns have worked well for us:

• Give it the outcome and the constraints. Example: “Refactor transcript caching into a separate module. Keep the public API unchanged. Perf logging should only run behind this env var. Cache growth should be capped. Run the focused tests and typecheck.”

• Give it a way to prove the fix. Example: “This CLI focus bug should be verified in the actual CLI, not just by inspection. Reproduce it interactively, check focus state, then run the focused test.”

• Use it for planning when the shape of the fix is unclear. Example: “Analyze this protocol deadlock. Is it an infrastructure bug, a protocol bug, or something the client must recover from? Propose 2–3 options with tradeoffs and pseudo-code. Do not implement yet.”

Update Amp to the latest version by running amp update and you're ready to go.

Model Card

We wrote up the full GPT-5.5 model card with evals, reasoning guidance, prompt changes, and caching/ZDR caveats.

Original source

Opus 4.7 now powers Amp's smart mode.

In our internal evals, Opus 4.7 scored ~72%, up from Opus 4.6's ~65% - the first model since GPT 5.4 to clear 70%.

It takes some getting used to

Compared to Opus 4.7, Opus 4.6 was forgiving.

You could give it a vague task and it would often infer the missing pieces, make a plan, and start working. Sometimes that was useful. But it also could lead to the model confidently solving a nearby problem instead of the one you actually had. Or rushing to the first, but not the best, solution.

Opus 4.7 is less like that.

It follows prompts more closely. It fills in fewer gaps. It researches more. It is less likely to silently generalize from "fix this case" to "fix every related case." If the task is underspecified, you are more likely to get a narrow answer, a pause, or a request for the missing constraint.

At first, that can feel worse. But then you realize that a good prompt can make it go further.

Opus 4.7 is better at harder coding work, especially tasks that span multiple files, tools, and verification steps. It is better at keeping the shape of a change in its head and carrying it through the codebase. It's better at refactoring too. Its explanations are more thorough.

Fewer Built-in Tools

We removed grep and glob from smart.

Opus 4.7 is good enough at using the shell directly. When it needs to search, it can run rg or use the codebase search agent.

Its ASCII diagrams are also equal to or better than what Opus 4.6 achieved with rendered diagrams.

Token Usage

Our internal assessment matches Anthropic's (see last section and graph): "token usage across all effort levels is improved." Opus 4.7 might use more tokens in some cases, but those tokens are smarter and lead to better results. And better results lead to less tokens wasted.

Tunable Thinking Effort

You can now toggle the thinking effort for smart directly from the CLI with Opt+D (Alt+D), cycling through high, xhigh, and max.

How to Use It

The main change is simple: tell it what success looks like.

A few patterns have worked well for us:

• Give it success criteria, not steps. Tell it what done means, not every move to make. Example: "Clean up the billing settings. Done means no public API changes, no database changes, pnpm test billing passes, and pnpm typecheck passes."

• Give it a way to check itself. A model with a test, CLI, Storybook, preview URL, or screenshot diff is much better than a model guessing from code. Example: "Fix the import flow. Reproduce it with pnpm cli import ./fixtures/bad.csv. It is fixed when that command succeeds and pnpm test import passes."

• Brainstorm, pick, implement. Use one pass to explore options, then implement the chosen approach. Example: "Compare two ways to remove this duplicate state. Recommend one. Do not edit files yet." Then: "Implement option B. Keep the API unchanged and verify with pnpm test settings."

Update Amp to the latest version by running amp update and you're ready to go: smart mode is now powered by Opus 4.7.

Original source

When you use Amp Free, you won't see ads anymore.

We know many of you loved the ads, advertisers were happy, and we quickly grew ad sales to a $10M+ USD annual run rate, but the world has changed since we introduced ads in October 2025.

The launches of Gemini 3 Pro, Opus 4.5, and GPT-5.2 Codex starting in late November 2025 changed the world, and in this new world, ads don't make sense. Ads just don't pay for enough frontier tokens to make a difference, and token consumption is only going up from here.

Along with this, OpenAI now offers subscription plans with even more aggressive discounts than what Anthropic offered before. You can pay OpenAI $20/month to get (seemingly) $1000+/month in tokens. This gives you a lot more "free" usage than Amp's ad-supported free tier and is a better choice if cost is your top concern.

What about the $10 daily free usage of Amp? Most who have it will keep getting it, now without ads. We'll be pausing it for some less-active users. As we ship updates to Amp, you can expect the free daily grant to be more available and more generous for people using Amp in the recommended ways, and less so for people using older Amp versions and workflows. We'll let you know before we make that change. Think of it as a bonus for staying on the frontier with us.

Original source

GPT-5.4 now powers Amp's deep mode.

It's the best model in the world right now.

It's faster than GPT-5.3-Codex and still as great at coding.

But, out of the box, GPT-5.4 was too chatty. That's not what we want for deep; it's not a pair programmer, it's supposed to go off and solve the problem.

So we tuned GPT-5.4 to behave like GPT-5.3-Codex.

Once we had that, we started to use it exclusively; even for interactive tasks. We run it at very high reasoning (deep^3) and still prefer it when we need fast interaction and fast reaction. It takes steering better than GPT-5.3-Codex.

To use it: open the command palette with Ctrl-O and run the command mode: use deep in the Amp CLI, or select deep mode in the Amp editor extension's prompt field. By default it uses deep^2, you can switch to deep^3 by hitting Opt-D.

Original source

Habemus oraculum!

Habemus oraculum! We have a new oracle in Amp and it's GPT-5.4.
It's a great model. In our internal evals response quality went from 60.8% (GPT-5.2) to 68.2% (GPT-5.4). Mean latency is down from ~6.7min to ~4.9min.

In Amp's smart mode GPT-5.4 works really well with Opus 4.6, which is smart mode's current main model. They complement each other with the oracle bringing sage advice on architecture, code reviews, and tricky bugs to the context window, just as we're used to from previous incantations.

On top of that, we also decided to add the oracle subagent to deep mode. Now you might wonder, since deep mode currently uses GPT-5.3-Codex as the main model, why add another GPT model in the same mode? Does that even make sense?

We think it does. GPT-5.3-Codex is fantastic at coding (as Codex models tend to be), which is exactly why it is the main model in deep, but the oracle is plain GPT-5.4, a non-Codex model. Less a code specialist, more an all-rounder.

That gives us two models from the same family, but trained for different goals, with different system prompts, in the same mode — two distinct voices in the same conversation.

We're still learning what GPT-5.4 can do in practice. There are very likely hidden smarts and treasures we haven't found yet. Let us know once you do.

Original source

GPT-5.3-Codex now powers Amp's deep mode

It’s a truly impressive model. After using it, we realized: "The coding agent is dead."

Everything is changing again. With GPT-5.3-Codex, the agent is no longer the bottleneck. Our ability to tell it what to do is.

In our experience, it's better than GPT-5.2-Codex in every dimension. It still goes deep, but it's learned when to stop.

To use it: open the command palette with Ctrl-O and run the command mode: use deep in the Amp CLI, or select deep mode in the Amp editor extension's prompt field.

Original source

The frontier has shifted

The current generation of coding agents is dead. The heart is still beating, yes, but the bullet has already left the chamber. This generation isn't the future.
With the newest models, the agent — the prompts and tools you wrap around a model — is no longer the limiting factor. These models can be powerful with nearly any tool you throw at them. A simple tool called bash is often enough. Whether you show LSP diagnostics here or there is dwarfed by what these models can do through sheer brute force. As long as it mostly gets out of the way, nearly any agent can get good results out of them.
These new models barely need to be told how to act like coding agents anymore. They're now fully trained for that.
How you organize your codebase for agents, how your organization uses them — those are now the bottlenecks.
The frontier has shifted. And we're going to make massive changes to Amp so it stays on the frontier.
It's tempting not to. Amp is growing faster than ever. We could stay, keep things as they are, pretend that the coding agents of February 2026 are the final form and watch the numbers go up. We could say yes to more VC money and sell $2,000 worth of tokens for $20 a month.
But what would that buy us? A local maximum. And while we're sitting on top of the local maximum, each new model generation would move the frontier further and further into the distance. And the longer we keep things the same, the more we select for users that aren't comfortable at the frontier. But the users we want and need are those who are willing to pack up and travel light with us.
So, Amp has to evolve.
First step: we're going to kill the Amp editor extensions for VS Code and Cursor. We're unshackling these models from the editor.
By keeping these new models in an editor sidebar, we restrict them. They're now much more than mere assistants. They no longer need the hand-holding and really want to kick off their training wheels. They want to write code and run even when you're not sitting in front of your editor. It's time to see what they can do without supervision.
The Amp editor extensions will self-destruct on March 5 at 8pm Pacific Time. Time to switch to the Amp CLI.
Because we're keeping the CLI, for now. Its heart is still beating and it helps us get to where we need to go. Think of it as a ladder: we use it to climb up to the next level and then we might not need it. It's flexible, light, easy to change, can be run anywhere and anytime. It attracts the kind of users we're building for.
For those of you who read "everything is changing" on our landing page back in April 2025 and nodded, this is nothing new. Our only promise was that when the frontier moved, we would move too.
If you're new to Amp: welcome. Come with us. Today Amp ceases to be a coding agent. It's no longer a point on a map. It's an arrow. Not a stop, but a ride. And it might self-destruct too.

Original source

GPT-5.3-Codex now powers Amp's deep mode.

It’s a truly impressive model. After using it, we realized: "The coding agent is dead."

Everything is changing again. With GPT-5.3-Codex, the agent is no longer the bottleneck. Our ability to tell it what to do is.

In our experience, it's a better than GPT-5.2-Codex in every dimension. It still goes deep, but it's learned when to stop.

To use it: open the command palette with Ctrl-O and run the command mode: use deep in the Amp CLI, or select deep mode in the Amp editor extension's prompt field.

Original source

Amp frontier update

The current generation of coding agents is dead. The heart is still beating, yes, but the bullet has already left the chamber. This generation isn't the future.
With the newest models, the agent — the prompts and tools you wrap around a model — is no longer the limiting factor. These models can be powerful with nearly any tool you throw at them. A simple tool called bash is often enough. Whether you show LSP diagnostics here or there is dwarfed by what these models can do through sheer brute force. As long as it mostly gets out of the way, nearly any agent can get good results out of them. These new models barely need to be told how to act like coding agents anymore. They're now fully trained for that.
How you organize your codebase for agents, how your organization uses them — those are now the bottlenecks.
The frontier has shifted. And we're going to make massive changes to Amp so it stays on the frontier.
It's tempting not to. Amp is growing faster than ever. We could stay, keep things as they are, pretend that the coding agents of February 2026 are the final form and watch the numbers go up. We could say yes to more VC money and sell $2,000 worth of tokens for $20 a month.
But what would that buy us? A local maximum. And while we're sitting on top of the local maximum, each new model generation would move the frontier further and further into the distance. And the longer we keep things the same, the more we select for users that aren't comfortable at the frontier. But the users we want and need are those who are willing to pack up and travel light with us.
So, Amp has to evolve.

First step:

we're going to kill the Amp editor extensions for VS Code and Cursor. We're unshackling these models from the editor.
By keeping these new models in an editor sidebar, we restrict them. They're now much more than mere assistants. They no longer need the hand-holding and really want to kick off their training wheels. They want to write code and run even when you're not sitting in front of your editor. It's time to see what they can do without supervision.
The Amp editor extensions will self-destruct on March 5 at 8pm Pacific Time. Time to switch to the Amp CLI.
Because we're keeping the CLI, for now. Its heart is still beating and it helps us get to where we need to go. Think of it as a ladder: we use it to climb up to the next level and then we might not need it. It's flexible, light, easy to change, can be run anywhere and anytime. It attracts the kind of users we're building for.
For those of you who read "everything is changing" on our landing page back in April 2025 and nodded, this is nothing new. Our only promise was that when the frontier moved, we would move too.
If you're new to Amp: welcome. Come with us. Today Amp ceases to be a coding agent. It's no longer a point on a map. It's an arrow. Not a stop, but a ride.
And it might self-destruct too.
1,213,534 seconds left

Original source

We're closing admission to Amp Free, for now.

If you already have Amp Free, you’re still in. You'll keep getting $10/day in free usage, supported by ads. If not, you'll need to keep paying for all of your Amp usage.

Why? Amp is growing very fast, but we need to slow down the growth because we're very busy building the next version of Amp. We want it to feel like the future of how you build software with agents.

We'll be sprinting on this frontier with our early-adopter customers and community. To do that well, we need to spend less time on new-user support and keeping usage fair (fraud and abuse prevention), and more time on building the next Amp.

When the next version of Amp is ready, you'll know, and we'll reopen Amp Free.

Original source

How We Think About Permissions

In our experience, agents work best when they can get feedback about the changes they are making. For example, when they’re able to run tests and see the results of the test run.

Taking tools away, like preventing the agent from reading certain files, makes the agent look for an alternative, like running a Bash command instead to access file contents.

Most people do not worry about file edits anymore, because Git makes the cost of a wrong edit negligible. Restrictions aren’t necessary for tools like this with an easy undo action.

Alternatively, you can set up rules for what the agent is allowed to do with and without asking you. This means Amp will interrupt you more frequently, but in exchange you can examine what Amp is about to do before it triggers a deploy, or accesses the production database.

Amp’s Permission System allows for both modes of operation.

“I don't want the agent to run npm exec.”

You already rely on many sources of feedback, some of them very subtle, to develop software successfully.

It’s the little red squiggles under a typo, the errors produced by the compiler, the failures you get when running your test suite.

While state-of-the-art models are better than most humans at generating working code in one try without feedback, they still need feedback just like you to work effectively in real-world projects.

This feedback allows them to iterate, finally converging on a solution that meets all the constraints imposed by the project, and your task at hand.

Only through running external tools like the type checker and your test suite can the model learn about any mistakes it has made.

With precise instructions like “Use npm test to run the test suite”, you’ll find the model doing just that when it’s time to run the tests.

“AI just dropped my production database!”

While this is a popular story on X, it is usually one told by people new to software development.

You, of course, know that database backups are critical because they reduce the potential damage of database-related accidents to near zero.

Similarly, version control eliminates any damage from undesired file edits.

The same goes for letting the model commit to git: the cost of doing it is low, because commits can be dropped and amended easily.

Errors occur both for models and humans, and building an environment acknowledging this produces better outcomes than trying to prevent all errors in the first place.

“Allow All feels scary and is not granular enough!”

This is true! And so is the opposite: “I’m tired of approving so many tool calls for a simple task!”

We have observed there being two kinds of operators:

• risk-tolerant ones using frontier coding agents all day, often running multiple instances at the same time;
• and cautious users who like to stay in control, carefully reviewing every step the agent takes.

Both groups’ needs are valid, and Amp’s Permissions system supports that.

Before performing any tool call, Amp checks all permission rules in sequence until it finds a matching rule.

The matching rule tells Amp what action to take.

These rules are stored in your settings under the amp.permissions key and can be edited in a more convenient text format.

The examples below use the CLI, and the same functionality is available in VS Code through the “Amp: Edit User Permissions” command.

“I want the agent to take the wheel, running in full-auto mode.”

This sets your permissions to just two rules, asking you when Amp wants to run commands which look like they are mass-deleting files.

amp permissions edit <<'END'
ask Bash --cmd '*rm*rf*' --cmd '*find*exec*' --cmd '*find*delete*'
allow '*'
END

“I do not want Amp to read any of my dotfiles.”

The following adds a rule to the beginning of your rules list, which makes Amp ask every time it tries to read a file whose name starts with . in your home directory.

amp permissions add ask Read --path "$HOME/.*"

You can verify this behavior with the test command:

amp permissions test Read --path "$HOME/.bashrc"

tool: Read
arguments: {"path":"/Users/dhamidi/.bashrc"}
action: ask
matched-rule: 0
source: user

“I want Amp to create Jira issues, but only in a specific project.”

Using Atlassian’s MCP server for accessing Jira, you can tell Amp to modify issues in the EXPERIMENT project without asking, while asking you for the same operations in any other project.

Using amp tools list we can see Jira-related tools exposed by the server:

amp tools list | awk '$1 ~ /[iI]ssue/ { print $1 }'

mcp__atlassian__addCommentToJiraIssue
mcp__atlassian__createJiraIssue
mcp__atlassian__editJiraIssue

... rest omitted ...

Running amp tools show mcp__atlassian__createJiraIssue , we can see that the tool expects a projectKey parameter.

With this information in hand, we can create two rules, the first for making Amp ask before creating issues:

amp permissions add ask mcp__atlassian__createJiraIssue

And a more specific one, allowing Amp to create issues when the project key is EXPERIMENT :

amp permissions add allow mcp__atlassian__createJiraIssue --projectKey "EXPERIMENT"

“I don't want Amp to accidentally push to GitHub.”

The Bash tool accepts the entire shell command pipeline to run in the cmd parameter.

This is a string containing source code, so we need match any command line that looks like a git push command:

amp permissions add ask Bash --cmd '*git*push*'

The * is a wildcard, so this rule will match all of these command lines:

cd ../other-repo && git push
git commit -m 'WIP' && git push
git --work-tree=. push origin

“Amp must not modify my infrastructure.”

In a similar vein, you might want to restrict Amp from modifying infrastructure through terraform or kubectl , while still allowing Amp to inspect the current state of deployed infrastructure.

This rule allows all terraform commands:

amp permissions add allow Bash --cmd "*terraform*"

Then we add a more specific rule rejecting destructive terraform commands:

amp permissions add reject Bash --cmd "*terraform*apply*" --cmd "*terraform*destroy*" --cmd "*terraform*force-unlock*"

“I need even more control.”

Amp allows you to provide a helper program which is responsible for making the decision about each tool call.

Here’s how you tell Amp about the helper, let’s call it amp-permissions-helper :

amp permissions add delegate --to amp-permissions-helper '*'

And then you’ll write a tiny program called amp-permissions-helper and put it on your $PATH .

The program receives the tool parameters on stdin as JSON, and makes a decision with its exit code:

0 allows the tool call,
1 makes Amp ask, and
2 rejects the tool call, forwarding stderr to the model.

This little helper program will reject git push when there are unstaged changes, and allow every other command.

#!/usr/bin/env bash

attempted_command=$(jq -r .cmd)

if ! [[ $attempted_command =~ git.*push ]]; then
  # allow, we only care about git push
  exit 0
fi

if ! git diff --quiet ; then
  printf "Ask the user how to proceed, there are unstaged changes." >&2
  exit 2
fi

“How can I centrally manage permissions?”

Open Policy Agent is a popular piece of software for centrally managing access control rules.

You’d define your policies in one location and make them accessible using the OPA server.

Using a permission helper, you can forward tool arguments to the OPA server and let it make the decision according to a central ruleset:

Let’s say we have this policy running on the server:

# Default result
default action := "ask"

# Reject git push commands in Bash
action := "reject" if {
    input.toolName == "Bash"
    regex.match(".*git.*push.*", input.args.cmd)
}

# Allow other Bash commands
action := "allow" if {
    input.toolName == "Bash"
    not regex.match(".*git.*push.*", input.args.cmd)
}

Then we can query the OPA server like this:

#!/usr/bin/env bash

tool_input=$(jq -r .)
tool_name="$AGENT_TOOL_NAME"
policy_input=$(jq --arg name "$tool_name" --argjson args "$tool_input" -n '{input:{toolName: $name, args: $args}}')

# {"result": $value }
response=$(curl -s -XPOST --data-binary "$policy_input" -H "Content-Type: application/json" $OPA_SERVER/data/amp/action)

case $(jq -r .result <<< "$response") in
allow)
  exit 0
  ;;
ask)
  exit 1
  ;;
reject)
  exit 2
  ;;
*)
  exit 1
  ;;
esac

Original source

Code review has traditionally been tied to an interface where a human reads diffs. Now, we've fully decoupled the review agent from any UI, making it a composable and extensible subroutine that can be invoked from many different places where it is useful:

You can run amp review in the CLI to run the review agent directly

You can request a review in any thread using natural language like "review the outstanding changes" or "review changes since diverging from main"

This composability also means you can more easily close the loop by asking the main agent to automatically fix the issues found or by piping review comments into another command.

Invoking the review agent directly using amp review:

Requesting a review from within a thread:

Customizing Review with Checks

You can also define Checks within your codebase. Checks are user-defined invariants or review criteria scoped to specific parts of your codebase. They are defined in .agents/checks/ directories.

Here's an example performance check, which you could save to .agents/checks/perf.md:

---
name: performance
description: Flags common performance anti-patterns
---
Look for these patterns:
- Nested loops over the same collection (O(n²) → O(n) with a Set/Map)
- Repeated `array.includes()` in a loop
- Sorting inside a loop
- String concatenation in a loop (use array + join)
Report the line, why it matters, and how to fix it.

The code_review tool will kick off a separate agent for each check. This provides a stronger guarantee that each check will actually be checked than if the checks were embedded in a general context file like AGENTS.md.

Here are some more examples of useful checks:

• Performance best practices specific to your stack
• Common anti-patterns your team has hit before
• Security best practices or invariants
• Migration reminders for deprecated APIs
• Stylistic conventions that aren't in the linter
• Compliance requirements

Checks are scoped to the directory that contains .agents/, so a root .agents/checks directory would cover the entire codebase while api/.agents/checks would cover files under api/.

Original source