Ampcode Release Notes

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

Amp's mode dial in the CLI showing low, medium, high, and ultra

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

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:

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: …

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.

Orbs are billed by the minute. See the current orb sizes and pricing. 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>

<thread> can be a thread URL or 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. …

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', …

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)

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.

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:

Amp's diff highlighting for duplicated code

Ours

GitHub's diff highlighting for duplicated code

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:

Open thread in browser shortcut

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 Ctrl+\ to show the sidebar with threads in your current directory.

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

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

Tighter Changes, Better Checks

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

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.

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/cli@0.0.1779896748-g596c49 --take-me-back

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.

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 deep or smart for those.

What Changed …

We're now shipping the Amp CLI as a single-file executable (compiled by Bun) instead of as a JavaScript source package. This makes Amp faster and more compatible across platforms and runtimes, and it's necessary to support Amp plugins.

If you're using the recommended direct installation, nothing changes for you. You've been using this single-file executable for several months. You can stop reading here.

If you've installed Amp via npm, you should switch to direct installation:

npm uninstall -g @sourcegraph/amp
curl -fsSL https://ampcode.com/install.sh | bash

(See all installation methods.)

If you need to keep using npm to install Amp, usually because your company has an internal npm mirror/archive, be aware of some changes:

• The CLI's npm package will now contain the executable instead of sources.
• We're renaming 2 npm packages:
  • The Amp CLI is now @ampcode/cli (was @sourcegraph/amp)
  • The Amp TypeScript SDK is now @ampcode/sdk (was @sourcegraph/amp-sdk)

The old package names are aliases but will be removed on June 15, 2026.

Today we're starting to roll out the new Amp.

Not all of it, not yet. But the first piece: a rebuilt Amp CLI. Codename: Neo.

In The Coding Agent is Dead we wrote about where this is going: agents with longer leashes, less handholding, and many more places to run. Not just one agent in one terminal. Agents prompted from anywhere, running everywhere.

That's the new Amp we're building.

But the terminal still matters and will matter. There will be moments where you want the agent right next to you.

So we rebuilt the CLI first. It is still Amp in your terminal. But it's running on a completely new architecture: remote-controllable, compaction-first, plugin-powered, and much faster. Built for what's coming.

Let's walk through it.

Remote Control

When you start a thread in the new Amp CLI, you can now remote control it from ampcode.com.

You'll not only get live updates but you can also send messages, queue and dequeue them, or cancel what the agent is currently doing:

The architecture that enables this is the reason we rewrote Amp. And remote control is just the start.

Update (2026-2026-05-27): You can now require passkey authentication to use remote control.

No More Manual Context Management

A core principle behind the rebuild: build for what the frontier models can do now, in 2026, and what they will be able to do in the future. Do not build for what once was. …

GPT-5.5 now powers Amp's deep mode.

It is a better coding agent than GPT-5.4: more steerable, more interactive, and better at staying inside constraints.

More Agent-Shaped

GPT-5.5 is better at the actual agent loop: read enough code, make the change, verify it, explain what happened. Whereas with GPT-5.4, prompts often had to spell out the process.

With GPT-5.5 we found it's best to clearly describe the outcome and put the rules and repeatable steps into the guidance files and tools.

If the task is vague, it can still solve the wrong problem cleanly. Good prompts matter more, not less.

Reasoning Effort

With GPT-5.5 we lowered deep's default effort from high to medium (deep²).

Do not assume higher reasoning is always better: in our eval, GPT-5.5 high cost more than medium and performed worse.

xhigh (deep³) is for cases where maximum quality matters more than cost.

As before, you can toggle the thinking effort directly in the CLI with Opt+D (Alt+D), cycling through low (deep), medium, and xhigh.

How To Use It

The most important guideline to follow: tell GPT-5.5 what success looks like.

A few patterns have worked well for us:

• Give it the outcome and the constraints. Example: “Refactor transcript caching into a separate module. Keep the public API unchanged. Perf logging should only run behind this env var. Cache growth should be capped. Run the focused tests and typecheck.” …