Ampcode Release Notes

We're removing Amp Tab

We're removing Amp Tab. It is not part of the future that we see.

A year ago, most of our code was written by hand. In June, when we released Amp Tab, Amp was already writing the majority of our code. But now, Amp writes 90% of what we ship.

Amp Tab and other completion engines come from a world in which everyone believed humans will write most of the code and AI is sprinkled on top.

But that world is dying! Look around! Some of our users are saying they haven't opened their editor in days and yet still shipped code. The bottleneck is now how fast you can get the code out, not how fast you can write it, they say.

The era of tab completion is coming to an end. We're entering the post-agentic age, in which it's a given that agents write most of the code.

There's so much to figure out, so much to build, so much to explore! We have to choose what to focus on.

We're focusing on what's coming next, not what brought us here.

Amp Tab will continue to work until the end of January 2026. After that, we can recommend Cursor, Copilot, or Zed if you need inline completions.

Here's Quinn and Thorsten on the end of Amp Tab and how they feel about it (Quinn will miss it):

Fork deprecation

We're ripping out the Fork command.
We added thread forking back in July 2025 (now ancient, primordial history) as a way to conveniently share context for branching experiments or side quests in Amp.
Today we have better ways of sharing context between threads: handoff and thread mentions, which treat threads as first-class stores of context.
Perhaps there is a great potential UX out there for fork, but we want Amp to be simple as well as powerful. We'd rather spend our time perfecting handoff and thread mentions than support fork.

Handoff

Handoff is great for extracting useful context from your thread for the next goal at hand. This means you can start a new thread with only the necessary context.

• Use thread: handoff from the command palette.
• Prompt your task and a new thread will be started with the necessary context already in the prompt.

Thread Mentions

Thread mentions let you pull information from other threads into your current thread. You can reference multiple threads, merging context from many sources.

• Use thread:new and then use the enter shortcut to start a new thread with a reference to the main thread.
• Or, use @@ to search for the thread you want to pull context from.
• Once you run your prompt, Amp will read the threads and extract context pertinent to your task.

Managing Threads

Using new threads as branches leads to many threads, often running in parallel. To manage them:

• use thread: switch to previous or thread: switch to parent to return to the main thread.
• use the thread: map to get a birds eye view and easily navigate back to the main thread (CLI only for now).

Release notes

Doom? Removed: TODOs feature

We removed the TODOs feature from Amp.
It was very useful when we added it in the middle of last year. It kept the agent on track and gave visual indication of how the work is progressing.
Now, with Opus 4.5, we found it's no longer needed. The agent tracks its own work in a single thread just fine without TODOs. It's faster too, because writing down a list of what it was going to do cost time and tokens. Took up space in the UI, too.
So we removed TODOs - they're done. There's something better coming up.

The Amp editor extension

The Amp editor extension now has a new panel to view and manage all active agent threads.

You can use the keyboard to navigate between threads:

• j / k or arrow keys to move between threads
• Space to expand a thread panel to show the last message or tool result
• Enter to open a thread
• e to archive or unarchive a thread
• Esc to toggle focus between the thread list and the input, which starts new threads

We recommend archiving old threads so the displayed threads represent your working set. You can use Archive Old Threads from the Amp command palette (Cmd-K from the Amp panel) to archive threads older than 72 hours.

As coding agents improve and require less direct human oversight, more time will be spent by humans in managing and orchestrating work across multiple agent threads. We'll have more to share soon.

To get started, click the button on the left end of the navbar or use Cmd-Opt-I (macOS) or Ctrl-Alt-I (Windows/Linux).

Every Amp user can now receive daily free credits to use the full Amp experience, including our frontier smart agent powered by Opus 4.5. No payment required, powered by ads—turn them off if you don't want free credits.
If you're a new user, just sign up for Amp, and download the CLI or editor extension.
If you're an existing user, go to user settings to enable ad-supported free credits.

What You Get

The free credit grant replenishes hourly, giving you a total of $10 worth of credits per day or roughly $300 of credits per month. When you've used up free credits, you can either wait for the hourly reset or purchase paid credits.

Amp's smart mode is currently driven by Opus 4.5 (with GPT-5 and Gemini-3-powered subagents like the oracle + librarian). You can also use rush mode, which provides faster inference at a lower cost per token, currently driven by Haiku 4.5.

Really?

Really! Like everything we do, ad-supported inference is an experiment. We can't promise we can do this forever, but we've already rolled it out to a sizable beta group thanks to our ad partners and it has been well-received. You can apply to become an ad partner.

Ads are text-only and never influence Amp's responses. If you don't like ads, you can opt out and just pay the cost of inference.

We invite new users to check out our manual, which contains good tips for using Amp efficiently.

MCP servers often provide a lot of tools, many of which aren't used. That costs a lot of tokens, because these tool definitions have to be inserted into the context window whether they're used by the agent or not.

As an example: the chrome-devtools MCP currently provides 26 tools that together take up 17k tokens; that's 10% of Opus 4.5's context window and 26 tools isn't even a lot for many MCP servers.

To help with that, Amp now allows you to combine MCP server configurations with Agent Skills, allowing the agent to load an MCP server's tool definitions only when the skill is invoked.

How It Works

Create an mcp.json file in the skill definition, next to the SKILL.md file, containing the MCP servers and tools you want the agent to load along with the skill:
{
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"],
"includeTools": [
// Tool names or glob patterns
"navigate_page",
"take_screenshot",
"new_page",
"list_pages"
]
}
}

At the start of a thread, all the agent will see in the context window is the skill description. When (and if) it then invokes the skill, Amp will append the tool descriptions matching the includeTools list to the context window, making them available just in time.

With this specific configuration, instead of loading all 26 tools that chrome-devtools provides, we instead load only four tools, taking up 1.5k tokens instead of 17k.

Take a look at our ui-preview skill, that makes use of the chrome-devtools MCP, for a full example.

If you want to learn more about skills in Amp, take a look at the Agent Skills section in the manual.

To find out more about the implementation of this feature and how we arrived at it, read this blog post by Nicolay.

Since we added support for Agent Skills, we became heavy users of them. There are now fifteen skills in the Amp repository.

But one frustration we had was that skills were only invoked when the agent deemed that necessary. Sometimes, though, we knew exactly which skill the agent should use.

So we made skills user-invokable: you, as the user, can now invoke a skill, which will force the agent to use it when you send your next message.

Open the command palette (Cmd/Alt-Shift-A in the Amp editor extensions or Ctrl-O in the Amp CLI) and run skill: invoke.

Amp has a new agent and it specializes in code review.

In the VS Code extension, you can use this agent by going to the review panel. Start by dragging the selection of changes you want to review. Sometimes, you want to review a single commit; other times you want to review all outstanding changes on your branch:

Amp will pre-scan the diff and recommend an order in which to review the files. It will also provide a summary of the changes in each file and the changeset overall:

This addresses a key difficulty in reviewing large changesets, as it's often difficult to know where to start.

Clicking on a file will open the full file diff, which is editable and has code navigation if your diff includes the current working changes:

Review Agent

The review agent lives in a separate panel below. It analyzes the changes and posts a list of actionable improvements, which can then be fed back into the main Amp agent to close the feedback loop:

There's a big improvement in review quality over the first version of the review panel, which used a single-shot LLM request. The new review agent uses Gemini 3 Pro and a review-oriented toolset to perform a much deeper analysis that surfaces more bugs and actionable feedback while filtering out noise.

To get to the review panel, click the button in the navbar. We've also added a ⌘; keybinding to make it easy to toggle in and out of review mode.

An Opinionated Read-Write Loop

If you're wondering how best to incorporate this into your day-to-day workflow, here's our opinionated loop for agentic coding in the editor:

• Write code with the agent
• Open the review panel ⌘;
• Drag your target diff range
• Request agentic review and read summaries + diffs while waiting
• Feed comments back into the agent

Open Questions

We think the review agent and UI help substantially with the bottleneck of reviewing code written by agent. But we're still pondering some more open questions:

• How do reviews map to threads? It's not 1-1, since you can review the output of multiple threads at once.
• How do we incorporate review feedback into long-term memory? When you accept or reject review comments, should Amp learn from that? Should it incorporate feedback into AGENTS.md?
• What does the TUI version of this review interface look like? Should there exist an editable review interface in the TUI? Or should we integrate with existing terminal-based editors and diff viewers?