Ampcode Release Notes

You can now pick the size of the orbs used to run Amp agents remotely:

• a0.tiny: 1 CPU, 2GB memory, 40GB disk ($0.10/hour)
• a0.small: 2 CPUs, 4GB memory, 40GB disk ($0.21/hour)
• a0.medium: 8 CPUs, 16GB memory, 40GB disk ($0.83/hour)
• a0.large: 16 CPUs, 32GB memory, 40GB disk ($1.66/hour) — default

Go to project settings to change the size of a project's orbs.

We also doubled orb storage from 20GB to 40GB, at no additional cost to you.

See Orbs in the Amp Owner's Manual for more information.

Original source

Threads outgrew read_thread, so we rewrote it.

read_thread is the tool that lets Amp pull context out of other Amp threads when you mention them. Before the rewrite, it would fetch the whole thread and extract the relevant parts in a single call to another LLM.

That used to work when threads were shorter and contained a single context window. Then we added compaction and now a single thread can run for weeks. Our longest thread has been compacted over 68 times — without compaction, it would be over 21 million tokens long.

A 21-million-token thread doesn't fit into a single context window, so asking another LLM to extract relevant parts doesn't work anymore. And even threads with 1 million tokens that fit gave bad answers: one giant prompt over-weights whatever the thread ended with or started with and ignores the information in the middle.

read_thread is now a subagent tuned to extract information from long threads. The subagent takes a thread and a question, searches the thread, reads the messages, and checks whether later work revised or reverted what it found.

Our first version of the read_thread subagent answered from the first plausible hit. In a long thread, the first hit is often an attempt that was later revised or reverted. We switched the model to GLM 5.2 from Gemini 3.5 Flash and tuned its prompt to optimize for correctness over speed:

"Do not stop at the first relevant hit; check for newer messages that revise, supersede, revert, or contradict it."

"Tool calls record attempted actions, not outcomes." It checks whether an edit actually succeeded before believing it.

"Use compactions for orientation, but inspect original messages when exact requirements, wording, code, commands, chronology, edits, or verification matter."

It also works on the thread you're in. When the agent needs something from three weeks ago — a decision, an error, the original plan — it goes back and looks instead of trusting the compaction.

Nothing changes on your end. Either tell Amp what you're looking for and let it find the thread, or give it a thread explicitly: paste a URL, or @-mention it. And when you open a new thread, hit Enter twice to reference the thread you just left.

Mention a thread and ask a question, just like before, except it now works with big threads too:

"Implement the plan from https://ampcode.com/threads/T-…"

"What did we implement for the visibility submenu in https://ampcode.com/threads/T-…? Which files changed, and how does it work now?"

"Summarize the requirements, implementation decisions, and known caveats from https://ampcode.com/threads/T-… before you review this."

"Find the thread where we debugged the executor connection timeout and summarize the fix."

"Hey, I know it's a lot, I know I should've stopped way earlier, but can you look at this thread in which we went for 271 rounds and extract that bootstrap script? https://ampcode.com/threads/T-…"

Original source

You can now launch Amp agents remotely in orbs:

Orbs are machines where agents can run without supervision. When you create a new thread you get a fresh orb that contains your code, plugins, and tools the agent might need.

Each orb has 32GB memory, 16 cores, $1.66/hour, billed by the minute. They start up quick and go to sleep when you and the agent no longer need them.

Remote and Yet So Near

Agents in orbs aren't running on your machine, but you can control them just like they were.

You can review changes and browse through the files on the orb:

You can use the terminal:

If you want to iterate alongside the agent, you can sync the changes to your local machine by running:

amp sync <thread-id>

Like this:

And just like you can spawn new Amp thread with amp -x, you can use amp -ox to spawn a thread in an orb:

amp -ox "Investigate why the latest CI run on 'main' failed"

You don't even have to leave the Amp TUI to spawn an agent that lives in orb:

See the manual for more information on orbs and how to use them.

Things Change

The ability to spin up new agents from everywhere and then let them run for as

long as they need changed how we work with agents.

Of course, having multiple agents work at the same time was already possible

before this: one could use different checkouts for different agents, or

worktrees, or run agents manually via SSH on remote hosts.

But when it's this easy to launch an agent on a machine that isn't your own, in the

very same interface that you already use to manage your local agents, right next to

those local agents, with the very same controls?

Things change.

For one, you tend to do it a lot more.

Why not launch a group of agents to investigate eight different bugs

independently when there are no local resource clashes to worry about? Why not

turn a bug report into an agent and an investigation instead of a ticket? Why

not manage the agent and its results instead of the ticket?

You also start to use them for things you hadn't considered before.

Why not launch an agent to run for a very long time and try out all possible

performance optimizations if it doesn't eat up your CPU? Why not have agents run

through testing workflows if that doesn't conflict with your local agents and

steal memory away from them?

Why not build that prototype? Why not go for that moonshot? Why not try?

Why not?

Time to Find Out

Back in February we said that we hold the

models back if we treat them as mere assistants and lock them into a sidebar.

The models, we proclaimed, "want to write code and run even when you're not sitting in

front of your editor".

And now we're here. Never mind the editor, now we can let our agents run even when

we're not sitting at our computer.

We believe that is how a lot of code will be written in the future. We believe

that this is not just another step, but a step over an important threshold.

How exactly this will play out we don't know. Some code will likely always be

created locally, under close supervision, with a lot of back and forth. But

these models are getting so good that the amount of code they can write on their

own (and run, and test, and ship) will only grow. At this point, we hold them

back if we require them to do it all on a single machine.

And once you let them loose in orbs, you realize how constrained they’ve been.

Time to find out how far they can go.

Original source

You can now create custom agents in Amp with plugins.

You can use these custom agents as your main Amp agent, or as subagents. You can use them as a small part of a tool pipeline that you invoke with amp -x. Or you can spawn 25 custom worker agents, then switch between them.

Each custom agent comes with a custom orb color.

Here is how you define a custom agent in an Amp plugin:

// .amp/plugins/focused-reviewer-agent.ts
import type { PluginAPI } from '@ampcode/plugin'

export default function (amp: PluginAPI) {
  // Create the agent
  const reviewer = amp.createAgent({
    name: 'focused-reviewer',
    model: 'openai/gpt-5.5',
    instructions: [
      'You are a focused code-review subagent.',
      'Inspect only the files and concerns named by the caller.',
      'Return concise findings with severity, evidence, and suggested fixes.',
    ].join(' '),
    tools: 'all',
    display: { label: 'reviewer', color: '#d97706' },
  })

  // Register a tool. This agent acts as a subagent
  amp.registerTool({
    name: 'focused_review',
    description: 'Run a focused code-review subagent.',
    inputSchema: {
      type: 'object',
      properties: {
        request: { type: 'string' },
      },
      required: ['request'],
    },
    async execute(input, ctx) {
      // Run a one-shot agent turn
      const result = await reviewer.run(input, {
        parentThreadID: ctx.thread.id,
      })
      return result.text
    },
  })

  // Or register the agent as a selectable main thread mode
  amp.registerAgentMode({
    key: 'focused-reviewer',
    description: 'Code Review Expert',
    agent: reviewer.definition,
  })
}

Threads

Once you have defined an agent, you can create threads:

// Spawn a new thread
const thread = await reviewer.createThread({
  // Tell the UI switch to this thread
  show: true,
})

// Get an existing thread
const thread = amp.threads.get(input.threadID)

The Thread object lets you interact with a thread in many different ways, and is where the real power comes in.

Send a message to a Thread

Add a new user message to a thread by calling thread.appendUserMessage(). The call returns as soon as Amp has accepted the message; it does not wait for inference to complete before returning.

await thread.appendUserMessage({
  type: 'user-message',
  content: 'Review the auth changes in this branch.',
})

Wait for the Agent's response

When you do want to wait, call waitForResponse() on the thread. It resolves with the next assistant message after the agent finishes its turn.

const reply = await thread.waitForResponse()

Example: Spawn an async thread that responds to the main thread

These are just a few primitives provided by the Plugin API. Together, they compose into unique workflows. An example used on the Amp team: spawn an agent in an asynchronous thread, and give it the tools it needs to respond to the parent when it needs to.

amp.registerTool({
  name: 'start_async_review',
  description: 'Start a review in a background thread.',
  inputSchema: { type: 'object', properties: {} },
  async execute(_input, ctx) {
    const thread = await reviewer.createThread({
      parentThreadID: ctx.thread.id,
    })
    await thread.appendUserMessage({
      type: 'user-message',
      content: [
        'Review the auth changes in this branch.',
        `When you are done, call send_to_thread with threadID ${ctx.thread.id}`,
        'and include your review in the message.',
      ].join(' '),
    })
    return `Started background review in ${thread.id}.`
  },
})

Full documentation is in the manual. Happy Hacking.

Original source

The Librarian is now ~3x faster and 43% cheaper, with the same quality.

It now runs on GPT-5.5 (no reasoning) with websocket mode and an updated system prompt that encourages more parallel exploration. The Librarian fires ~8 tool calls in parallel per turn, up from ~3 with Sonnet, and wraps up a search in ~5 turns instead of ~15.

In our internal eval, about a quarter of that speedup comes from OpenAI's websocket mode and the rest from switching to GPT-5.5 with no reasoning:

Sonnet-4.6 (medium) / GPT-5.5 (none)

Metric Sonnet-4.6 (medium) GPT-5.5 (none) Latency (mean) 237s 81s (2.9x faster) ↳ gain from websocket — ~1.3x ↳ gain from model — ~2.2x Quality (F1, mean) 0.47 0.48 Average cost $1.21 $0.69

Here's a comparison:

How does Kubernetes' HorizontalPodAutoscaler handle missing pod metrics when scaling down — does it assume missing pods are at 100% of their resource requests, or 100% of the target utilization? Cite the function and logic in the source.

Sonnet 4.6 (left) took 2 minutes and cost $1.08, while GPT-5.5 (right) took 40 seconds and cost just $0.47.

Original source

Outsource your coding, but not your understanding of the code.

As agents generate larger quantities of code, it is more important than ever for humans to comprehend the code to ensure its quality.

You can now review any thread's code changes directly in Amp, on desktop or mobile.

While a thread has an active environment, you can scroll through the diff, request changes on specific sections, and stage changes interactively:

Some care and attention has gone into the diffing algorithm, which performs duplicate block detection to make it easier to see what has actually changed. This can significantly reduce cognitive load when reviewing large agent-generated changesets.

Here is an example where Amp (left) makes it easier to see that the only thing that has changed is the removal of the if-branch of the conditional:

Ours
Theirs

If you drive your threads primarily from the terminal, use the command palette (Ctrl-O) to open the diff for your current thread in your browser:

Original source

Tighter Changes, Better Checks

Opus 4.8 now powers Amp's smart mode, replacing Opus 4.7.

It is a better coding agent than Opus 4.7: more faithful to the prompt, tighter in the changes it makes, and better at checking its own work. In our internal evals it solved 62% of tasks, up from 4.7's 52%.

Opus 4.7 was already strong on hard, multi-file work, and Opus 4.8 keeps that. What changes is how it gets there: with fewer wasted steps and more self-checking.

The clearest difference is restraint and verification.

Opus 4.7 can sometimes over-engineer, reaching for a more elaborate solution than the task needs. It also verifies its own work less, occasionally moving on even when a command's output is already warning that something is off.

Opus 4.8 makes a more focused change that solves the specific intended task, then checks itself. It leans on a tighter write→test loop, often spinning up a quick script, test, or skill to confirm the change works before proceeding. In our evals it ran tests and code 15% more per task than 4.7.

That restraint is easiest to see on hard tasks. On everyday work the two make a similar number of tool calls. The harder a task gets, the tighter 4.8 stays, just where 4.7 tends to run long and fail more often.

It Reaches for the Right Tool

Opus 4.8 is noticeably better at using its tools and sub-agents without being told to.

When a task needs outside context, it actually calls librarian instead of inferring a library's behavior from the local code. Across our eval it reached for it 14 times, versus once for Opus 4.7. It also reaches for a repo's skills more often to verify its work, for example by driving the browser or the CLI, rather than just assuming the change worked.

When it edits, it leans on edit_file for surgical, in-place changes rather than rewriting whole files with create_file. In our evals 79% of its file edits go through edit_file, up from 63% on Opus 4.7.

Fewer Built-in Tools

We dropped the Read tool from smart.

Opus 4.8 is good enough at reading files straight from the shell with cat, rg, sed, and nl. It parallelizes those reads when it needs several files at once.

Fast Mode Is Worth It Now

Opus 4.8 has a fast mode at roughly 2.5× the speed. It now costs 2× base tokens, down from 6× on 4.7—3× cheaper.

Toggle fast mode for a thread from the CLI command palette (Ctrl+O) → speed: use fast.

How to Use It

Opus 4.8 stays close to what you ask, changes less to get there, and checks its own work. A few habits make it shine:

• Say how far to go. It keeps changes narrow, touching fewer files than 4.7 unless told otherwise. Name the scope when you want it wide: "Fix this for every input format, not just this one." Left unsaid, it changes exactly what you described, which is usually what you want.
• Give it something to verify against. It runs tests and code more readily than 4.7, so a test, repro command, or repo skill turns that instinct loose. A browser or CLI skill lets it actually exercise the change rather than infer correctness from the code.

Original source

Amp has a new UI and sidebar, built for watching and driving all of your Amp agents, on web, mobile, and CLI.

We rebuilt Amp's foundation last month, so that your agents can run for longer, with less handholding needed. Amp is now a distributed system with durable execution for the agent loop and a plugin API.

Now, with this new foundation in place, we're pulling ourselves back above ground to shape how you use Amp to get the most out of these models.

We want you to be happy and productive running many Amp agents simultaneously on long-running tasks. You should be able to use the agent interface for most of your work. You shouldn't need to juggle terminal tabs.

Remote-controlling a single thread was the first step toward this, and now you can remote control all of your active threads in one place:

It's rolled out to everyone. To use it:

• Desktop web: sign into ampcode.com, or run amp app.
• Mobile web: sign into ampcode.com.
• Amp CLI: press Opt+S/Alt+S to show the sidebar with threads in your current directory.

The thread list for your team has also been redesigned and moved to Activity.

Original source

We’ve removed public, internet-wide, discoverable thread sharing from Amp. You can still share threads within a workspace, or as Unlisted to share them with anyone by unguessable URL.

Why? It’s getting too hard to review a thread to ensure it doesn’t contain any snippets of sensitive files. Each model release means the agents get better, and as they get better they read more files into context. Public discoverable thread sharing is just too risky now. This decision is proactive and isn’t prompted by any incident.

Public discoverable threads have served their purpose well. Last year, Mitchell’s Ghostty threads and other publicly shared Amp threads helped spread the word that coding agents were actually good—and taught people how to use them.

Public user profiles (like ampcode.com/@sqs) still show your activity but no longer show any threads. Any existing Public (Discoverable) threads are now Unlisted, so your blog posts with thread links won’t break.

Original source

Amp Neo is now available to everyone. Time to drop the suffix and just call it Amp again.

Thank you to everyone who sent bug reports, gave feedback, and was patient while we scaled up the infrastructure to meet the demand.

Over the last few weeks, we've made a lot of improvements based on that feedback. The infrastructure is more stable. The clients are more resilient. There is still more to do, but Neo now performs well for the vast majority of users.

The latest version of Amp no longer includes the --take-me-back flag that let you use pre-Neo Amp. If you need to finish work in the old Amp, you can run a previous version:

npx -y @ampcode/[email protected] --take-me-back

Original source

Amp can now require active passkey authentication for certain operations, such as remote controlling a thread. This extra authentication factor protects you if an attacker gains access to your account and will serve as proof-of-human for future Amp features.

Update (2026-06-25): We've removed the "sudo" term and now just call it "passkey authentication".

To turn it on: enable Use Passkey Authentication and set up your passkey.

Workspace admins can enforce this requirement for members. Also, some privileged workspace admin operations now always require active passkey authentication.

Original source

We're releasing a new version of our agent mode rush.

Prior to this change, rush’s usefulness was limited. It was faster and cheaper, but also made more mistakes and required more attempts to get to the same results than a slower and ultimately not that much more expensive frontier model.

Now, rush is tuned to lean into its advantages — speed, low cost — instead of trying to make up for its shortcomings.

It uses GPT-5.5 with no reasoning instead of Haiku 4.5. It is tuned for small coding tasks that don’t require contemplating the whole repo, but to find the relevant files, make the smallest correct change, run a focused check, and stop.

This is what rush is good at:

“Fix the failing renders empty state test.”

“Update @src/components/ui/Select.tsx to match the focus-ring styling in @src/components/ui/Button.tsx”

“Rename enableLegacySearch to enableSearchV2 in all files that use it”

Do not use rush for transient bugs, architecture changes, migrations, complex features, and tasks where you do not yet know what “done” means. In those cases, reading more, thinking longer, and building a larger model of the codebase is what gets you good results. Use smart or deep for those.

What Changed

The previous system prompt in rush mode was “speed first.” It told the model to move fast, keep explanations short, edit, verify, and stop. With GPT-5.5, we can be more precise: gather only the context needed to act safely, make the smallest correct change, verify narrowly, and stop. This makes it less prone to save time by skipping the parts that make the result usable and to over-contextualize - to keep reading and thinking.

rush now uses shell_command for searching, reading, and verification, and apply_patch for edits. That means we can remove quite a few tools that all do almost the same thing - grep, glob, and create_file.

The task subagents have the same configuration as the main agent: no reasoning, GPT 5.5.

Evals

On our internal evals, rush solved 44% of tasks, up from 39% for the previous version.

The cost moved up slightly: $0.58 per task on average, compared to $0.44 for the previous version (an 18% increase).

The speed changed much more. Rush 2.0 finished in 1 minute and 32 seconds on average, down from 2 minutes and 59 seconds.

That is the tradeoff we wanted: a little more expensive, meaningfully more capable, and almost twice as fast.

It is not deep. On the same evals, deep solved 58% of tasks, 14 points higher than rush.

Pair It with the Oracle

The best pattern we have found is rush plus the oracle.

Let rush build. Ask the oracle to plan, criticize, or review. The oracle is slower and more expensive, but it is read-only and good at adversarial thinking.

This works especially well for tasks that are still bounded, but not trivial. You know the area of the codebase. You know roughly what needs to change. But there is enough surface area that a second, more deliberate pass can prevent rush from making the locally obvious but globally wrong edit.

Try prompts like:

“Ask the oracle to inspect @src/billing/applySeatLimit.ts, @src/billing/planLimits.ts, and the failing seat limit is enforced after downgrade test. Have it propose the concrete fix first: which behavior should change, which file should own the rule, and what should stay untouched. Then implement the smallest patch and run the billing tests.”

“Update the workspace invite flow so expired invites show the same error state in @src/routes/invites/AcceptInvitePage.tsx and @src/components/invites/InviteBanner.tsx. After the patch, ask the oracle to review the diff and suggest the focused tests or manual checks that would actually prove this works. Run the relevant ones before calling it done.”

“Before changing the caching behavior in @src/search/useSearchResults.ts, ask the oracle for two or three implementation options beyond the obvious one. Have it judge them in context of the codebase: consistency with the existing query hooks, risk of stale data, complexity, and testability. Then implement the best minimal option.”

To use it: run mode: use rush in the Amp CLI.

Original source