Ampcode Release Notes

Update: The look_at tool has been replaced with a similar view_media tool that can return the raw or cropped/transformed image data to the model in addition to a textual description.

Amp can now look at PDFs, images, and other media files with a goal in mind.

Using the new look_at tool, Amp sends the file to a separate model — one with its own context window — and gets back only the information it requested.

That means the main agent never has to process the full file, saving valuable tokens in the main context window.

To try it, just tell Amp to look at a media file with a purpose, like extracting the structure of a binary file format from the 477-page PDF spec defining it, and watch it distill the relevant bits out of the file.

You can now add labels to threads to organize your work and find conversations later.

After a few weeks with Amp, you'll have dozens of threads. Some are one-offs, but others represent ongoing work: a feature you're iterating on, a bug you keep revisiting, or research you want to reference later. Labels help you find those threads again.

Thread labels in action

Click the tag icon on any thread to add a label. As you type, you'll see suggestions from labels you've already used—no need to remember exact names.

Click any label to jump to all threads with that label, or use the filter dropdown on the threads page to narrow down by multiple labels at once.

Two days ago, Lewis wrote about working with short threads — a lot of them, connected via handoff and thread mentions and forks. In his post, he showed a diagram, a map of one feature spread across 13 threads.

That map? It exists now, we built it:

Old whisperer of the orb reading a thread map

Run threads: map in the Amp CLI command palette to try it out.

You'll see a top-down view of all threads connected to your current thread via mentions, handoffs, or forks. If you hit Enter, you'll open the selected thread and can continue your work there.

(Yes, it's only available in the Amp CLI right now, but coming to other clients soon.)

If you only use handoff and forks occasionally, you might not need this yet. But if you do work with many short, connected threads — like Lewis or Igor — this map might make it even easier, because you can see the shape of your work.

Here are some patterns we've noticed so far:

1. Hub-and-Spokes

Bicycle spokes pattern …

Amp supports agent skills. Skills let the agent lazily-load specific instructions on how to use local tools. We like skills because they improve agent tool use performance in a very context efficient way.

Skills are installed to .agents/skills/ in your workspace by default. Amp also reads from ~/.config/agents/skills/ for user-level skills, and .claude/skills/ and ~/.claude/skills/ for compatibility with existing skills.

Our team has been doing a ton of experimenting with skills over the past few weeks. Here are a few that we have found particularly useful:

• Agent Sandbox: Isolated execution environment for running untrusted code safely.
• Agent Skill Creator: Meta-skill for creating Claude agents autonomously with comprehensive skill architecture patterns.
• BigQuery: Expert use of the bq cli tool for querying BigQuery datasets.
• Tmux: Run servers and long-running tasks in the background.
• Web Browser: Interact with web pages via Chrome DevTools Protocol for clicking, filling forms, and navigation. …

For all of you who swear by tabs and clean syntax, the Amp Python SDK is now live.

You can run Amp programmatically from your Python code, just like you already do in TypeScript.

Here, for example, is how you instruct Amp to migrate React components with custom toolbox tools to validate changes:

import asyncio
import os
from amp_sdk import execute, AmpOptions

prompt = """
	  Goal: Migrate all React components from React 17 to React 18.

    1. Find all React component files (.tsx, .jsx)
    2. For each component:
       - Update deprecated lifecycle methods
       - Replace ReactDOM.render with createRoot
    3. Track any components that fail migration with the reason
    4. Run the typecheck_test_tool after each change
    5. Output a summary: migrated count, failed list with reasons
"""

async def main():

    # Use the toolbox directory to share tools with Amp
    toolbox_dir = os.path.join(os.getcwd(), "toolbox")

    async for message in execute(
        prompt,
        AmpOptions(
            cwd=os.getcwd(),
            toolbox=toolbox_dir,
            visibility="workspace",
            dangerously_allow_all=True,
        ),
    ):

        if message.type == "result":
            if message.is_error:
                print(f"Error: {message.error}")
            else:
                print(f"Summary: {message.result}")

if __name__ == "__main__":
    asyncio.run(main())

To get started, install the pip package and the Amp CLI: …

Amp can now search your threads.

A few weeks ago we shipped the ability to read other threads. That was the first step: reference a thread by URL or ID, let Amp pull out the relevant context.

But what if you don't have the thread ID at hand? What if the only thing you know about a thread is that it changed or created a specific file? Or some keywords?

That's what the new find_thread tool is for. It lets Amp search your threads in two ways:

Keyword search: find threads that mention specific terms. "Find threads where we discussed the database migration." The agent in Amp will then use the same search functionality as on the thread feed and return matches.

File search: find threads that touched a specific file. Think of it like git blame, but for Amp. "Which thread last modified this file?" Amp looks at file changes across threads and tells you which conversations touched it.

Here's how we've been using it to find threads:

• "Which Amp thread created core/src/tools/tool-service.ts?"
• "Search my threads to find the one in which we added the explosion animation. I want to continue working on that."
• "Show me all threads that modified src/terminal/pty.rs"
• "Find and read the thread that created scripts/deploy.sh."
• "Find the thread in which we added @server/src/backfill-service.ts, read it, and extract the SQL snippet we used to test the migration." …

Claude Opus 4.5 is the new main model in Amp's smart mode, two days after we shipped it for you to try out.

Only a week ago, we changed Amp's main model to Gemini 3 — a historic change, we said. It was the first time since Amp's creation that we switched away from Claude. Now we're switching again and you may ask: why? Why follow a historic change with another one, in a historically short amount of time?

We love Gemini 3, but, once rolled out, its impressive highs came with lows. What we internally experienced as rough edges turned into some very frustrating behaviors for our users. Frustrating and costly.

Then, not even a week later, Opus 4.5 comes out. Opus 4.5, on the other hand, seems as capable as Gemini 3. Its highs might not be as brilliant as Gemini 3's, but it also seems to do away with the lows. It seems more polished. It's faster, even.

We're also pleasantly surprised by Opus's cost-efficiency. Yes, Opus tokens are more expensive, but it needs fewer tokens to do the job, makes fewer token-wasting mistakes, and needs less human intervention (which results in a higher cache hit rate, which means lower costs and latency).

Sonnet 4.5

Gemini 3 Pro

Opus 4.5

Internal Evals

37.1%

53.7%

57.3%

Avg. Thread Cost

$2.75

$2.04

$2.05

   0-200k Tokens Only[^1]

$1.48

$1.19

$2.05

Off-the-Rails Cost[^2]

8.4%

17.8%

2.4% …

Anthropic just released Claude Opus 4.5. We've been testing it, right on the heels of the Gemini 3 release, and have been very, very impressed. Exciting times!

We're eager to figure out where and how it can fit into Amp. As the main agent? As the oracle? As another subagent? There's a lot to explore.

But one learning from the Gemini 3 launch is that early-access performance might not be indicative of final production performance. So we want to be careful and evaluate it properly.

And, while cheaper than Opus 4.1, it is still more expensive than Gemini or Claude Sonnet 4.5. What we want to figure out now: can we make that worth it for you?

So, for a limited time, you can try Claude Opus 4.5 as the main agent in smart mode in Amp along with us:

• CLI: amp --try-opus or add "amp.tryOpus": true to ~/.config/amp/settings.json
• Editor extension: Click Try Opus 4.5 in the Amp settings

Let us know what you think.

Gemini 3 Pro is now the new main model in Amp, powering the smart agent mode.

This is a historic change.

Ever since we've started work on Amp, back in February, Anthropic's Claude has been the main model. Not for lack of trying. We've experimented with different models for the same role: GPT-5, Gemini 2.5, Grok, and others.

But Claude has stuck, because it has been the only model that managed to strike the balance between intelligence, speed, and the willingness and ability to use tools.

Then, Gemini 3 came along. (And, on the horizon, there are even more models lined up to take the crown.)

In just a few days, the number of ecstatic messages it got in our Slack was higher than for any other model:

• "crazy, this is incredible"
• "guys this is really good, I love it, it's a ton of fun"
• "I didn't expect a model drop to affect how much I'm enjoying using amp this much"
• "Wow. It's very persistent - in a great way."
• "Hot dog!! I haven’t tried it yet but you all are getting my hopes up"
• "I'm really loving this model. Feels like a great mix of eagerness mixed with experience. Doesn't feel like a bull in a china shop."
• "am I imaginging things? it is that good, right?"

Gemini 3 checked off all the boxes that so far only Claude had checked: smart, fast, follows instructions very well, works hand-in-hand with the user if needed, very eager to use tools and uses them with high dexterity. …

Amp has a new mode: rush, named so because a rushed job is faster and cheaper in the moment, and sometimes that's more important than quality.

Token-by-token, it's 67% cheaper and 50% faster than smart.

Prompt-to-result (what you actually care about)? It depends. It's less capable, which means that on complex tasks it often spends more tokens and time fixing its mistakes along the way.

You can rush small, well-defined tasks: simple bugs, small UI changes, minor features. For best results, mention the files that need to be changed.

Don't rush complex tasks: new end-to-end features, bugs with no clear diagnosis, an architecture refactor. It'll be slower and not much cheaper, if it even arrives at a solution at all. Use smart instead.

For example:

• A small rush-able task that took 37 seconds and cost $0.12 (44% faster and 77% cheaper than smart): "warn if there are more than 20 MCP tools..."
• A complex, non-rush-worthy refactor where rush took 2x longer than smart and was just 19% cheaper: "refactor all hardcoded colors from the CLI and web UI..." …

The Amp CLI now supports workspace-specific settings via .amp/settings.json files in your project directory.

This allows you to configure the Amp CLI differently for each project, with settings like permissions, MCP servers, and other preferences automatically picked up when you run amp in that workspace.

For example, here's how you can configure the Amp CLI to use a specific MCP server in a given project:

$ cd my-project
$ amp mcp add --workspace playwright -- npx -y @playwright/mcp@latest

Due to the --workspace flag, the setting was added in the .amp/settings.json file in my-project:

$ cat .amp/settings.json
{
  "amp.mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@latest"
      ]
    }
  }
}

When you then run amp in my-project, the settings in .amp/settings.json will be merged with your global Amp settings.

See the manual for details on how settings are resolved.

Update (2026-06-02): We've removed public thread sharing and related features; see The End of Public Threads for why.

We're all learning a new way to code: prompting, referencing, planning, handoffs, specs, and preparing a codebase to work well with agents.

Now, with public profiles and public thread sharing, you can see how other people are actually using agents to do real stuff. You'll probably learn something. We certainly have.

Public profiles and profile cards for Amp users

Take a look at some profiles to see how people are building terminal emulators, observability tooling, RL/simulation environments, web apps, and more:

• ampcode.com/@mitchellh — building Ghostty (more)
• ampcode.com/@mrnugget — building Amp
• ampcode.com/@tsenart — refactoring Vegeta
• ampcode.com/@hamel — evals and ML eng stuff
• ampcode.com/@cje — working on Axiom
• ampcode.com/@marcel — building Bold and Pidro …

You can now reference threads in your messages, and Amp will fetch and extract the relevant context from them. For example:

• "Implement the plan we devised in https://ampcode.com/threads/T-3f1beb2b-bded-4fda-96cc-1af7192f24b6"
• "Do what we did in https://ampcode.com/threads/T-f916b832-c070-4853-8ab8-5e7596953bec, but for the oracle tool"
• "Explain to me what my colleague Lily built in https://ampcode.com/threads/T-330bd49a-2402-453c-bbf4-0c2f2ce7f2b9"
• "Take the SQL queries from https://ampcode.com/threads/T-95e73a95-f4fe-4f22-8d5c-6297467c97a5 and turn it into a reusable script I can run"
• "Figure out whether and how Keegan ended up using the function created in https://ampcode.com/threads/T-e7ea6537-b3c6-4833-919c-45aa0af2d52f"

To reference your own threads in the CLI and editor extensions, type @ and the title of the thread you want to reference. For other threads to which you have access, such as workspace or public threads, simply paste the thread URL or the ID in your message.

Here's what that looks like in the Amp CLI: …

The bottleneck in coding agents is no longer writing code, but reviewing it. The Amp VS Code extension now has a new panel that enables humans to review agent-generated code more effectively.

Why build this?

Existing methods for reviewing agent-generated code fall into a few buckets:

1. Approve each change before it's applied
2. Read each edit the agent makes
3. View changes in a dedicated code review tool like GitHub PRs

If you're using coding agents heavily, all these options start to feel slow and tedious. Options 1 and 2 are too finegrained, wasting time on micromanaging intermediate changes the agent may decide to overwrite later. Option 3 pushes review too far down the line and requires reviewing substantial changes in an interface that doesn't let you edit or navigate the code.

The review panel is designed to streamline the type of review that takes up more and more time with agentic coding.

The general flow goes like this:

1. Select the commit range you want to review. Selecting the commit range

2. Quickly read the AI summary of the changes for a high-level overview. AI summary of the changes …

We heard you! Amp Free no longer requires you to opt into training. Now more programmers can use Amp Free as a free coding agent for both sensitive work code and on personal side projects.

How is this possible?

It turns out that the Internet's best business model (advertising) works, and we're able to make Amp Free without the training requirement.

Try it: install or update Amp, then use /mode free in the Amp CLI, or toggle smart/free mode in the editor extension.

Thank you to our fantastic launch advertisers who are making free agentic coding possible:

Amp Free Launch Partners

The free mode now meets all of the stringent security standards of Amp's paid smart mode.

If you're already using Amp Free, we've switched training mode off for you because it's no longer required.

Workspace admins can enable or disable Amp Free for all workspace members in workspace settings. If enabled (the default), workspace members will see the smart/free mode toggle. Amp Free is not currently available in Enterprise workspaces.

We have removed compaction from Amp and replaced it with something that we think works a lot better: Handoff.

Compaction — which you know as /compact from the Amp CLI, or the Compact or New Thread With Summary buttons in the editor extensions — always had downsides. It's lossy, for one. Every time you compact a thread, what's in the context window gets replaced with a summary. Whether that summary contains exactly what you think it should is up to the agent. Claude Code, for example, fixes that by allowing users to tell the model what to focus on when summarizing.

But even then: compaction, we found, encourages long, meandering threads, in which you just compact once you run out of context window, stacking summary on top of summary.

What we want to encourage are focused threads, because we think that's how agents yield the best results.

So we replaced it with Handoff.

Handoff is a new way to take existing context and move it into a new thread. Instead of summarizing a thread, you're extracting from it what matters for your next task.

Handoff lets you specify your goal for the new thread. Amp then analyzes the current thread and generates a prompt to start the new thread, along with a list of relevant files. Here are some examples for how you would use it in the Amp CLI:

• /handoff now implement this for teams as well, not just individual users
• /handoff execute phase one of the created plan …

We shipped several changes to toolboxes that make them easier to use:

• You can now have multiple toolboxes in the AMP_TOOLBOX environment variable
• amp tools make is a new command to create a functional example tool in the right location
• amp tools show lets you inspect a tool
• amp tools use allows you to execute it

And Amp itself can fill in all the details to make the tool work as you intended.

If you don't yet know what toolboxes are: a toolbox is a directory full of UNIX-style programs that provide custom tools to the agent locally. Conceptually, they sit between MCP servers and common CLI tools, but are less complex than MCP servers and easier for the agent to use than plain CLI tools.

Let's use an example to see how we can use amp tools make and amp tools use to create and run a new tool in a new toolbox.

Let's build a run_tests tool. Chances are that if you have used any coding agent before, you've probably seen it trying to run the your tests, but then stumble and having to guess a few times what the correct command invocation is. We can make (artificial) life for the agent easier by giving it a run_tests tool that will always use the correct command.

First we create a .amp/tools directory in our repository and add it to the AMP_TOOLBOX variable, so Amp knows to look there for tools:

# Create the directory
mkdir -p .amp/tools …