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

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

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

Migrating Custom Commands to Skills

We're removing custom commands in favor of skills. They were two ways of doing the same thing, except that only you could invoke custom commands, and only the agent could invoke skills. Now that you can invoke skills directly, there's no reason to keep custom commands around anymore.

It's easy and takes just a few minutes.

Let Amp Do It For You

If you have custom commands in .agents/commands/ or ~/.config/amp/commands/, ask Amp to migrate them for you with the following prompt:
Migrate my custom commands from .agents/commands/ to skills in .agents/skills.
For each command:

• For each command:
  • 1. Create a new skill directory in .agents/skills/ named after the command
  • 1. If it's a markdown file, rename it to SKILL.md and add frontmatter with name and description
  • 1. If it's an executable, create a SKILL.md that describes when and how to run the script, and move the executable to a scripts/ subdirectory
  • 1. Delete the original command file
• Also do this for global custom commands in ~/.config/amp/commands (which should be migrated to skills ~/.config/agents/skills).

Or Do It Manually

Markdown commands: Move your .md file to a skill directory:

Before

.agents/commands/code-review.md

After

.agents/skills/code-review/SKILL.md

Add frontmatter:

name: code-review
description: Review code for quality and best practices

[Your existing content]

Executable commands: Move the executable into a scripts/ subdirectory:

Before

.agents/commands/deploy

After

.agents/skills/deploy/
├── SKILL.md
└── scripts/
└── deploy

In SKILL.md, tell the agent how to use it:

name: deploy
description: Deploy the application

Run {baseDir}/scripts/deploy to deploy.

Original source

Shareable Walkthroughs

Shareable Walkthroughs are a new interface we're trying—a way to create and share annotated diagrams with your team.
Ask Amp to use the walkthrough skill to explain a feature, function, database schema, or any part of your codebase. It generates an interactive diagram where each node contains detailed context. The Walkthrough diagram lets you start at a high level and drill down into the details you care about.

Examples

• Understand how something in your codebase works
• Ask the walkthrough skill to explain any part of your code with a clickable diagram that links directly to the source.
• Use the walkthrough skill and explain the process of what happens when an email invite is accepted by a user.
• View Walkthrough
• Combine with the librarian to understand libraries and packages
• Pair the walkthrough skill with the librarian to explore how external libraries work—great for understanding new features or comparing versions.
• Use the librarian, look at Svelte version 5 and explain how event handling has been improved. Can you compare this to Svelte version 4? Use the walkthrough skill to explain the differences.
• View Walkthrough
• Generate different diagram types for your use case
• The walkthrough skill can produce various diagram types. Just specify what you need—for example, ask for an ER diagram when exploring database relationships.
• Use the walkthrough skill and explain how the invites entity is stored in the database, what depends on it. Use an ER diagram.
• View Walkthrough
• Advanced: Combine with custom tools and data sources
• You can pair the walkthrough skill with additional data sources and tools you've built to visualize answers to complex questions.
• Query the lineage SQLite database to find all dependencies for the [calculated_field_name] field in [CTE_name] job, then use the walkthrough skill to show how it's calculated and trace the impact of changing its logic—upstream sources, downstream consumers, and breaking changes.

Original source

Shareable Walkthroughs are a new interface we're trying—a way to create and share annotated diagrams with your team.
Ask Amp to use the walkthrough skill to explain a feature, function, database schema, or any part of your codebase. It generates an interactive diagram where each node contains detailed context. The Walkthrough diagram lets you start at a high level and drill down into the details you care about.

Examples

• Understand how something in your codebase works

• Ask the walkthrough skill to explain any part of your code with a clickable diagram that links directly to the source.

• Use the walkthrough skill and explain the process of what happens when an email invite is accepted by a user.

• View Walkthrough

• Combine with the librarian to understand libraries and packages

• Pair the walkthrough skill with the librarian to explore how external libraries work—great for understanding new features or comparing versions.

• Use the librarian, look at Svelte version 5 and explain how event handling has been improved. Can you compare this to Svelte version 4? Use the walkthrough skill to explain the differences.

• View Walkthrough

• Generate different diagram types for your use case

• The walkthrough skill can produce various diagram types. Just specify what you need—for example, ask for an ER diagram when exploring database relationships.

• Use the walkthrough skill and explain how the invites entity is stored in the database, what depends on it. Use an ER diagram.

• View Walkthrough

Advanced: Combine with custom tools and data sources

• You can pair the walkthrough skill with additional data sources and tools you've built to visualize answers to complex questions.
• Query the lineage SQLite database to find all dependencies for the [calculated_field_name] field in [CTE_name] job, then use the walkthrough skill to show how it's calculated and trace the impact of changing its logic—upstream sources, downstream consumers, and breaking changes.

Original source

Update

(Update on February 19, 2026: deep now uses GPT-5.3-Codex.)

Deep mode overview

Amp has a new agent mode: deep. It uses GPT-5.2-Codex and a selection of tools that are tuned to what this model is good at.
Where smart is eager, collaborative, and happy to edit right away, deep will silently read files and move through the codebase for five, ten, sometimes fifteen minutes before making changes - happy to be left alone.
GPT-5.2-Codex in deep is not an assistant that's constantly checking in with you. It wants to go off and solve problems on its own, not pair program. But that requires a clear definition of the problem up front, which you'll either need to provide in your first prompt, or ask deep to work out with you before you tell it to go and implement it.

Prompts that worked well in deep mode

Nicolay, changing how Skills register MCP tools: "A user has multiple skills, each skill has a mcp.json with the same server name and url, but with different includeTools list. So each skill uses a different subset of tools. Each mcp can only be registered once and last registration wins. But for each mcp within a skill we are only registering its subset of tools. So when the user has multiple skills, it is probably only having one set of tools being registered instead of all. How can we fix this? we could: [...]"

Thorsten, fixing a theme bug, and providing a screenshot: "Ever since we added @doc/cli-themes.md there's a bug: the selected message has a different color than normal messages. It should match."

Notes on behavior and usage

The autonomy of deep has limits: it's very good at fixing issues in one go, but it's also very lazy when it comes to running commands or checking its work. It also doesn't pay as much attention to AGENTS.md files as Opus does. That's an area we're actively improving.
We're very excited by how deep complements smart: use smart when you want to interactively work on something together, or get chores done; use deep when you want it to research thoroughly or fix hairy problems on its own. You can now also ask the agent to handoff to deep or smart mode.
To use it: run command mode: use deep in the Amp CLI, or select deep mode in the Amp editor extension's prompt field.

Original source