Ampcode Release Notes

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?

Original source Report a problem

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.

Original source Report a problem

New: Labels for threads

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.

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.

Original source Report a problem

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:

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:

• Hub-and-Spokes

  One thread will form a core from which many other threads can be created. This might be an initial implementation thread, or a context-gathering research thread. The spokes might be refactoring threads, or subfeatures. They don't need the context of the other spokes—by linking only to the hub thread, the context window of each spoke remains lean and relevant.

• Chain

  Many short threads chained together. This is a common pattern when one change depends on another. This pattern often emerges when using the handoff feature to extract only the relevant context from a previous thread, allowing you to keep threads short but still continue serially dependent work. This is common in research or exploratory tasks, where the desired state is unknown.

  It's not uncommon for the end of a chain to lead to the central node of a hub-and-spokes pattern; a desired state is found and work can be more easily parallelised.

What's Next?

Our bet is that there are many more patterns out there, waiting to be recognised. Let us know what you find.

Original source Report a problem

Amp now supports Claude Skills natively

Amp now supports Claude Skills natively. 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.

If you have existing skills in your
.claude/skills
directory, Amp picks them up automatically. Zero config.

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.

Read more about how to use skills in our manual
https://ampcode.com/manual#agent-skills

Original source Report a problem

Amp Python SDK

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())

Getting started

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

• Install the Amp SDK with pip
• Install the Amp CLI globally

$ pip install amp-sdk
$ npm install -g @sourcegraph/amp

Now you can build anything with Amp in any Python runtime environment. To get more ideas and familiar with the SDK, take a look at the examples in the manual.

Original source Report a problem

Opus 4.5 came out a few weeks ago and quickly became not only Amp’s main model, but also universally respected as the best model for coding — while having a context window of roughly 200k tokens. In the winter of 2025, that’s not a lot. A lot of people view this as a downside.

But here’s the thing — 200k is enough for me, it’s plenty. I love short threads. I do all my work with short threads. So does the rest of the team.

In fact, I took a look at a feature I just shipped for Amp, adding a thread: send to support command to the Amp CLI command palette. Here’s what it looks like as a cluster of interconnected threads:

Feature: Add Thread Support Command

Look at all those tiny threads! Look at the token counts, and the number of user messages sent. The biggest thread is 151k output tokens and four user messages. The average thread is around 80k tokens. Now think of the time when we had a 1 million token context window. I wouldn’t run a thread that long…

But hey, there are 13 threads in that feature. Probably more, as these are only the threads connected by thread mentions. Add up all those and you’re close to one jam-packed 1 million token context window.

So why not pile those all into one mega-thread and be done with it? Why bother with the tedium and drudgery of spinning up thread after thread with those puny, embarrassingly small contexts?

Short Threads Are Best

On the Amp team, we’ve known this for a while. The best threads are short, they do one thing, and they have just the right amount of context to do it. We’ve written about this in our guide on context management:

Agents get drunk if you feed them too many tokens.

I don’t know how to explain it better than this — they act drunk. They mess up, they fall over, they pick fights with you, and (if you feed them enough tokens) they’ll vomit all over you. It’s a mess.

Agents are models combined with a system prompt, tools, as well as the history of the conversation so far. The longer the conversation, the more the agent’s context window gets filled up with stuff not quite related to what it should be doing right now.

In order to get the agent to perform at its best, you need to give it the context it needs to get the job done, and no more.

Long threads are not just worse, they also cost more.

Way more. Not only does every token get sent to the provider with every request, exponentially increasing the cost of new messages, but some providers like Anthropic also charge more for long-context requests for some models. Long threads are also more likely to have longer idle periods between user messages, and so are more likely to miss the cache window — a major contributor to expensive runaway threads.

So they give worse results, and you pay through the nose for them.

But there’s something else.

Breaking into short threads == breaking into small tasks.

Big tasks are best broken down into small tasks. This was true before the agents came, and it’s true now that they’re here. Short threads make it easy (or even fun?) for you and me — lowly humans — to do that.

Just like small tasks are easier to work with, so are small threads. You can keep track of them easily, each has a well-defined goal, and life doesn’t feel too different from the old agentless world of yesteryear — but faster, and with less typing.

If you think of threads as units of tasks, then it’s intuitive to think of a feature or bugfix as a cluster of threads.

Life in Threads

Here’s another look at the feature I worked on last week, but with some added scribbles:

Feature: Add Thread Support Command

This is how I work, from bottom to top:

I start with a thread to build a basic implementation. If I think it’s going to be complicated, I might start with a thread to investigate some area of the codebase and gather the required context.

From that base, I’ll start new threads to tweak or refactor. Each change is a new thread — one change per thread. I use the read_thread tool to gather needed context from either the initial thread or from the previous refactor/tweak thread.

When I’m happy, it’s time to review the code. Sometimes I use new threads to help read the new code, investigate if it matches existing patterns, and make sure nothing nefarious snuck in. Those are all new threads.

Or I might want to validate with one-off scripts, throw-away tests, running in a profiler, spamming logs, forcing error states… These are all new threads.

My preferred way to share context between threads is to reference threads by mentioning their ID or URL, but there are other ways. In Amp you can use a handoff or fork command to create new threads. You can leverage the git state by telling Amp to run git diff or to inspect previous commits. Some people use multiple .md files with specs and histories to store and transfer context between threads — I’m not one of those people.

I use the Amp CLI, so the actual key-typing process of creating new threads and referencing previous ones is something like:

• Choose thread: new in the command palette, hit enter to accept the hint to reference the previous thread.
• Or: create a new thread and use @@ to mention and reference a thread.
• Then type the new task prompt and set it off.

Repeat for any new tasks, or if I prefer the context from the main thread, just thread: switch to previous and repeat.

That’s it! Each thread is a discrete task, and together they form a feature.

I love working through a big problem this way — breaking it down into baby steps, letting this superpowered alien orb made of sand rocket through each one. It’s still me at the wheel, but it’s fast, cheaper, and easier to reason about.

200k tokens? Plenty, if you make use of threads.

Original source Report a problem

Amp can now search your threads.

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 ID or URL, 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."

The find_thread tool is the sibling to read_thread. First you find, then you read. Together they turn your Amp threads into reusable context.

Original source Report a problem

Claude Opus 4.5 is the new main model in Amp's smart mode

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).

Internal Evals Sonnet 4.5 Gemini 3 Pro Opus 4.5 37.1% 53.7% 57.3% Avg. Thread Cost $2.75 $2.04 $2.05 0-200k Tokens Only1 $1.48 $1.19 $2.05 Off-the-Rails Cost2 8.4% 17.8% 2.4% Speed (p50, preliminary) 2.4 min 4.3 min 3.5 min

In words:

• If you use long threads (200k+ tokens): Opus will be a lot cheaper. It’s currently limited to 200k tokens of context, which forces you to use small threads —our strong recommendation anyway, for both quality and cost. If you need to temporarily keep using Sonnet's long context, use the "amp.model.sonnet": true setting or --use-sonnet CLI flag.
• If Sonnet or Gemini frequently struggles for you or has hit a capability ceiling: Opus will be far more capable and accurate, and often cheaper too (by avoiding wasted tokens).
• If you loved Gemini 3 Pro: Opus will be ~40% more expensive but faster and more tolerant of ambiguous prompts. (This describes most of the Amp team, and we still find Opus worth it.)
• If you were perfectly satisfied with Sonnet 4.5: Opus will be ~35% more expensive for the same task. The real win comes from getting outside your comfort zone and giving it harder tasks where Sonnet would struggle.)

Staying on the frontier means sometimes shipping despite issues — and sometimes shipping something better a week later.

Original source Report a problem