Ampcode Release Notes

Amp's agent modes are now a dial: low, medium, high, ultra. They replace smart, deep, rush, and large.

The old modes were models in disguise: each name hid a model, a prompt, a reasoning effort — and to pick one, you had to know what that model was like this month. That world is gone. The models converged, open-weight models got seriously good, and the only question left is capability against cost.

The dial asks one question: how hard is this task?

Missing in either direction costs you. Undershoot and the model churns: wrong fix, re-prompt, wrong fix again. You pay three times for a result you could have had once. Overshoot and you're using Fable to fix a typo. Set it right and you pay for exactly the intelligence the task needs.

ultra

The outcome is clear, but the path is full of unknowns. Migrations, architecture, changes that span many files, systems, and decisions the model has to discover as it goes.

high

You know where the change goes, but getting it right is hard: cross-cutting changes, concurrency, bugs where a subtle miss is expensive. You get diffs closer to reviewer-ready than medium gets you — but plan on one round of feedback before merging, and about twice the wait.

medium

You know roughly what you want. This should be your default. It handles messy, multi-part tasks, fuzzy requirements, the steps you didn't spell out. Strong enough for most work, fast enough to steer.

low

You know exactly what you want. Bug fixes, tests, refactors, features you can describe precisely. There is less to figure out for the model, so low builds it.

Turn the dial with Ctrl+S in the CLI, or with the mode picker in the web app.

Under the Hood

We want you to know exactly what you're getting, so here's what backs each mode today. This wiring will change as models improve. The dial won't.

ultra: Claude Fable 5, with a system prompt written for it. GPT-5.5 as the oracle.

high: GPT-5.5 at xhigh reasoning effort. Claude Fable 5 as the oracle.

medium: GPT-5.5 at medium reasoning effort. GPT-5.5 at high effort as the oracle.

low: GLM-5.2, Z.ai's open-weight model, the strongest open model on agentic coding. GPT-5.5 as the oracle. (Workspace admins can choose to use GPT-5.5 low instead of GLM-5.2 here.)

Reasoning effort is part of the tier now. No more cycling Opt+D through effort levels on top of picking a mode.

Every mode has an oracle for second opinions. On the top tiers, it's the other frontier model: in high, GPT-5.5 writes and Fable reviews. In ultra, Fable writes and GPT-5.5 reviews.

Migrating

smart, deep → medium (same model and effort as deep). Turn up for hard problems.

rush → low.

deep**3 -> ultra or high

Want to Tune It Yourself?

The dial removes knobs from the default experience, not from Amp. Plugins can register their own agent modes with your model, your prompt, and your tools, and they show up right next to the built-in ones.

We used that same plugin API to package up the deprecated modes — exact system prompts, exact tool lists, same models and reasoning efforts. If you want smart, deep, rush, or large back, install them:

amp plugins add --auto-update @amp/smart-classic

amp plugins add --auto-update @amp/deep-classic

amp plugins add --auto-update @amp/rush-classic

amp plugins add --auto-update @amp/large-classic

Then run plugins: reload (or restart the CLI) and they appear in the mode picker as Smart (classic), Deep (classic), Rush (classic), and Large (classic) — the original names stay reserved for the built-ins. --auto-update keeps them current when we update the plugins; drop it if you'd rather pin. The full list of installable modes is on ampcode.com/models.

Start at medium. Turn it down when the task is clear. Turn it up when a miss costs more than the wait.

We'll follow up with posts on each mode and numbers on what each one can handle.

Original source

You can now start new agents remotely from ampcode.com anywhere you can run amp:

That means, in addition to running agents in orbs, you can now run agents on any machine you want: your laptop, your server, your cloud dev box, your Raspberry Pi. Your lawn mower even, if it has a shell.

Enable it by using the command amp: enable remote creation of threads or with the setting:

// ~/.config/amp/settings.json
{
  "amp.remoteThreadCreation.enabled": true
}

Once enabled, every Amp client you start will accept and run new threads in its working directory.

Runner Mode

You can also use the new runner mode with:

amp --no-tui

That starts Amp in a headless mode in which it only waits to start and run new threads:

You can start multiple runners on the same machine, as long as they're started in different directories. Each runner is uniquely identified by host and working directory. Directories don't have to be version controlled. They can be anything, even home directories.

You can start agents anywhere now.

Walkthrough

Here's Thorsten with a walkthrough:

Original source

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