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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

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 Report a problem

Overview

Code review has traditionally been tied to an interface where a human reads diffs. With the original Amp review agent, we moved away from an external review UI into the editor, where comments could be acted on more immediately. Now, we've fully decoupled the review agent completely 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 in smart mode using natural language like "review the outstanding changes" or "review changes since diverging from main"

You can kick off multiple reviews in parallel from the editor extension review panel

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:

Requesting a review from the editor extension diff panel:

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 Report a problem