Amp changelog

You can now see and control your macOS or Linux runner's desktop. This is nice for trying native apps that Amp builds for you, such as iOS apps:

Turn on Share This Mac's Display under Settings › Runner in the macOS app, or start your runner with amp --no-tui --desktop.

Your Amp client connects directly to the runner, so it's nearly instant when the runner is on your local network or nearby.

Read See and Control the Runner's Desktop for more details.

You can now talk to Puck from ChatGPT, Claude, and other agents via MCP.

After developing an idea with ChatGPT's voice mode on a walk, send it directly to Puck for implementation. Puck knows your projects in Amp and routes it to the right orb. In the same conversation, you can check in on your work in Amp directly from ChatGPT.

Puck MCP offers two tools: puck for interacting with your Puck in Amp, and orbs for showing an interactive view of your running orbs with links to their portals.

You're talking to the same Puck you use in Amp. It can look through your threads, find earlier work, and coordinate your agents.

To connect, open Settings > Puck. Click Add to Claude, or copy https://ampcode.com/mcp into ChatGPT or another MCP client, then sign in with your Amp account.

See Use Puck in Other Apps for details.

The Changes pane now automatically puts files in an intelligent order. Amp reads the diff, identifies the files that are essential to the change, and puts them first.

If the diff changes, Amp computes an updated order without rearranging the files while you’re reviewing them. Instead, a blue dot will appear over the intelligent ordering button, which you can click to apply the updated order.

The new automatic intelligent ordering is computed much more rapidly. Here is a comparison of the same diff ordered by both the old and new method:

You can optionally go back to alphabetical file ordering by clicking the ordering button.

Amp now follows up on GitHub pull requests it opens. Comments, reviews, and CI results show up in the same thread.

When Amp opens a PR, the agent can now subscribe to the PR's comments, reviews, and CI for its latest commit. A failing check or a reviewer's question shows up in the same thread, and Amp already has the context to deal with it.

This is enabled by our new first-class support for GitHub Webhooks. In contrast to our existing, more generic webhook support, the new GitHub Webhook integration centrally handles all requests on the Amp side and then lets you (and your agent) decide whether to forward them to a single orb or to a new one each time. An agent can subscribe to certain events or can set up a subscription that spawns new orbs.

A New Orb for Every New GitHub Issue or PR

Ask Amp to start a new orb for every new issue or PR in a repository. You can also limit it to ones opened with a certain label. You don't need to keep the thread where you set it up.

Each new issue or PR gets its own orb, which reads it and has a summary waiting when you open the thread. Later comments on that issue or PR go to the same thread, so the conversation stays in one place.

You manage these in Settings → Integrations & MCP → GitHub, where you can edit or pause them and see the orbs each one started.

Read the docs to find out how to watch CI when you push to main, follow an existing issue or PR, and ask Puck what Amp is following.

Install the Amp GitHub App on your repository to get started.

You can now use your Claude Pro/Max subscription in Amp. It's free and available for everyone now.

When creating a new thread, just pick Mode > Claude Code. It'll ask to link your Claude sub if you haven't already done that.

Under the hood, this mode uses the Claude Agent SDK instead of Amp's own agent. But we made it all work: orbs and runners, thread sharing, portals, multiplayer, thread-to-thread messaging and orchestration, etc.

See the Claude sub docs for more information.

You can now have multiple separate conversations with Puck.

We know you love Puck. We also know you've been asking Puck about your recent orbs, a bug fix, and dinner plans, all in the same conversation. Now each of those can be its own conversation, and each one gets its own Puck.

Press + to start a new conversation. Click the conversation's name at the top to switch between them. Conversations you haven't touched in three days move into Inactive so the list stays short.

Read more about Puck conversations in the docs.

Amp now supports Plaid speed for modes that use GPT-6 Astra. Plaid uses OpenAI's ultrafast speed tier, which enables inference requests to run up to 6× faster, with 6× cost per token.

Open the mode picker in the new thread dialog, choose a mode that uses GPT-6 Astra (e.g., the default High mode), and move the speed switch past Fast to Plaid.

Plaid currently works with Amp-provided inference only, as OpenAI does not yet support ultrafast for linked ChatGPT subscriptions. When Plaid is activated, subagents and non-Plaid-enabled model inference will fall back to fast or standard speed. Like fast mode, Plaid can be toggled on or off for an existing thread.

Claude Opus 5.5 now powers Amp's medium mode by default, replacing GPT-5.6 Sol. If you use a ChatGPT subscription with the ChatGPT Only preset, medium stays pinned to GPT-5.6 Sol, billed to your subscription. To switch to Opus 5.5, change medium in Tune Modes.

In our internal evals, Opus 5.5 solved 65% of tasks, up from GPT-5.6 Sol's 61% and Opus 5's 56%. And it did that for 10% less than GPT-5.6 Sol and 25% less than Opus 5.

It's still behind Fable 5.1, which solved 71%, but it costs 40% less.

More Steerable

Opus 5.5 responds much better to messages you send while it works. Add a constraint you forgot, point out a wrong turn, or correct its approach, and it folds that into the work instead of arguing or carrying on with its old plan. It doesn't drop what it was doing, either.

So don't stop it to edit your prompt and start over. Send the correction. Enter steers by default, so your message reaches it right away.

High Effort, Not Max

Opus 5.5 runs at high reasoning effort. Past high, it starts to overthink. At xhigh and max it burns through tokens, scores lower than at high, and costs several times as much. So we stop at high.

Why Not GPT-6 Sol?

OpenAI shipped GPT-6 Sol an hour after Opus 5.5. We ran both.

In our evals, GPT-6 Sol scores about the same as GPT-5.6 Sol, at half the cost. In real work, though, it's much more jagged: strong on one task, off on the next. medium carries most threads, so it needs a model you can count on across all of them.

When To Turn the Dial Up

medium is the right place for most work now. Two kinds of task still belong higher:

• Lots of unknowns. Use ultra with Fable 5.1 when nobody knows the path yet. Alex had to move more than 5,000 users of an enterprise customer's SSO to new email addresses. He started the thread with:

  We've never migrated… from one set of email addresses to the next before… and we don't really have a way to test it.

  It mapped how sign-in works today, planned the switch, and watched production afterward. The first 41 sign-ins after the switch all worked.

• Taste and judgment. Use high with GPT-6 Astra or ultra with Fable 5.1 when the hard part is deciding what good looks like. Ask for options, not one answer. Hamish wanted a better transition out of the iOS image viewer:

  Right now it's a hard cut, so can you please give me some options for animations and record them and show me them in line in the transcript here.

  It recorded four options on the simulator. He replied "Ship B to main."

Turn the dial up when a miss costs more than the wait, not because the task is long.

How To Use It

Opus 5.5 is persistent. It keeps going until the job is done, which means it needs to know what done is, and it needs a way to see for itself. These are the habits we use, with prompts from our own threads:

• Give it the whole app to run. Models are very good at writing tests their own code passes. Running the app end to end is the best way to know it works. Make that one command with .agents/setup, services, and a skill. Tim hit a sidebar bug in our Mac app and asked:

  Repro it in preflight then we can look at fixing it.

  It launched our Mac app, dragged the sidebar closed, and measured the bug before touching any code.

• Tell it what done looks like, including the evidence it should deliver. Our bug fix prompts include:

  Implement the simplest correct fix, verify it, then explain the bug, the fix, and the evidence that the fix resolves it.

  That evidence is usually a failing test plus before and after videos.

• Raise the bar when the check is too easy. If it verified against an emulator or a mock, send it to the real thing. When it checked an iPad fix in an emulator, Quinn replied:

  test all of this in the Buildkite iOS preflight and use an iPad simulator

  The simulator caught two bugs the emulator had missed.

• Hand it the bigger task and go hands off. It holds up well over long threads. Tell it what evidence to deliver, then go do something else. You shouldn't babysit a capable model: if you have the patience to watch it work step by step, you're giving it too short a leash.

Amp now collapses your agent's step-by-step work even more, since you care about what the agent did, not how it got there. (You can still expand the steps when needed.)

A year ago, watching your agent's every step sometimes helped, and you probably were only running one agent.

Now? You have lots of agents. You should be giving them harder, deeper work and verification demands. They should run for longer on their own, without you watching them from up close. If you have the patience to watch your agents work, you're giving them too short a leash.

You can now share a runner with your workspace. Start it with --share and everyone in your workspace can start threads on that machine from ampcode.com.

If you have a machine with GPUs, a Mac that's used to build and sign the iOS app, or a dev box in a specific network, you can now set it up and the whole team can spawn agents on it:

$ amp --no-tui --runner-id macos-builder --share

Everyone in your workspace now sees it in the picker under Shared Runners.

With --amp-env, a shared runner gets the workspace and project Secrets & Env Vars, but never your personal ones. That applies to your own threads on it too.

We need to offer a word of warning, though: everyone you share with runs code on your machine as you, with your files, your credentials, and your logins. Their threads can also work in the same directories at the same time. So only share a runner with people you'd trust with a shell on that machine. Even better, give the runner a machine of its own. (Better still: use orbs, so that every thread gets its own machine.)

Workspace admins can turn off runner sharing in Member Settings.

Read more about sharing a runner in the runner docs.

The Amp app for macOS now starts a runner for you. You no longer need amp --no-tui open in a terminal to run threads on your Mac.

Open App Settings… (⌘⇧,), go to Runner, and click + to add a folder or one of your projects. Start a thread and your Mac is right there in the picker, marked This Mac. You can also pick it when you start a thread from ampcode.com, your phone, or Puck.

No More Sleeping on the Job

Keep This Mac Awake stops your Mac from going to sleep while the runner is on and the Mac is plugged in, so you can still start threads on it after you walk away. The screen still turns off and locks. On battery, or when you close the lid, your Mac sleeps as usual.

Read more in the runner docs.

A runner can now create Git worktrees. Pick a repository the runner serves, hit Tab, name the branch, and the thread starts in a fresh checkout. Your main checkout stays untouched.

In the directory picker, every Git checkout on the runner gets a New Worktree option next to it. Choose it and you get a small form:

The name you chose becomes the branch name and the folder name. The runner then creates the worktree as a sibling of the repository: ~/code/amp gets ~/code/amp-fix-flaky-login-test, checked out on a new branch fix-flaky-login-test off the current HEAD. Uncommitted changes stay where they are, in the original checkout. The new directory shows up in the picker right away, marked with a branch icon, and the thread starts in it.

Puck can do this too: ask it to start a thread on your runner in a new worktree and it passes a worktree name to create_thread.

Clean Up When You're Done

A thread that runs in a worktree the runner created gets a new action: Archive and Remove Worktree. It archives the thread, runs git worktree remove, and deletes the branch.

New Folders and Projects Too

The picker can also create things. Type the name of a directory that doesn't exist yet and you get New Directory or New Project. Read more.

Oh, They Understand Secrets Now Too

Runners can also use the Secrets & Env Vars you configure on ampcode.com. Same variables that orbs get. It's off by default; opt in with --amp-env:

$ amp --no-tui --runner-id mac-mini --discover-dirs --amp-env

Every time a thread starts, the runner fetches the variables that apply to it (personal, then project, then workspace) and adds them to the environment of the thread's shell commands, MCP servers, and plugins. Change a variable on ampcode.com and the next thread gets the new value. No restart, no SSH.

Both need a runner on the current Amp version. If yours has been running for a while, it has updated itself already.

Read more about worktrees and Secrets & Env Vars in the runner docs.

A runner can now serve many directories, not just the one it was started in. You can point it at specific projects and directories or let it find your Git repositories.

Start a runner and tell it which directories to serve with --dir. Repeat the flag for each one:

$ amp --no-tui --runner-id mac-mini --dir ~/code/amp --dir ~/code/sandcastle

Or start it in the directory that holds your checkouts and let it find them:

$ cd ~/code
$ amp --no-tui --runner-id mac-mini --discover-dirs

--discover-dirs serves every Git checkout up to two levels beneath the current directory and picks up new ones as you clone them.

Checkouts somewhere else, or deeper than two levels? Give --discover-dirs a path, repeat it for more, and set --discover-depth to look further down:

$ amp --no-tui --discover-dirs=~/work --discover-dirs=~/code --discover-depth 4

Add or remove directories while the runner is running, without restarting it:

$ amp runner dirs add ~/code/new-repo
$ amp runner dirs list
$ amp runner dirs remove ~/code/dotfiles

The runner remembers the directories you add this way and serves them again the next time you start it from the same directory.

Oh, They Can Update Themselves Too

Runners now update themselves too. If you leave an amp --no-tui runner running, it keeps checking for new releases about once an hour and installs them. Once no thread is running on it, it restarts into the new version, at most once every 12 hours. It keeps its runner ID, its directories, and the rest of its flags.

Turn it off with amp.runner.autoUpdate.enabled: false in your settings.

Read more about serving multiple directories and runner updates in the runner docs.

Amp is now free to use when you bring your own compute and model subscriptions/keys.

• No monthly plan is required anymore to use your ChatGPT subscription with Amp.
• No BYOK token fees or limits for anyone (except our Enterprise tier).

You pay us for orbs, our remote computers where your agents run independently and in parallel. Or you can use runners on your own computers to run your Amp agents for free.

You can still pay for model inference through Amp if you want, with no markup.

Here's our new free Hobby tier and no-extra-charge Teams tier, which make it easier to get started with Amp and to get your whole team on it:

See Pricing for full details, but let's walk through what changes and what doesn't.

For Amp Megawatt & Gigawatt Members

On average, Megawatt members get a 60% discount and Gigawatt members get a 65% discount on their Amp usage. It's a great deal.

You'll keep getting the same heavily discounted orb usage and model usage each month, plus you can now feed your orbs with tokens from more places.

With this change, you're no longer effectively bound by the limits of your ChatGPT sub. You can tap other model providers or your company's preferred AI gateway/provider (more on that below), all without any Amp token fees or limits.

For Teams

We've eliminated the biggest sources of friction you might hit when spreading Amp, cost-wise and security-wise.

Now, you can invite everyone to your Amp workspace for free and feel the magic of Amp's shared threads, shared portals, and multiplayer.

Everyone can use Amp with ChatGPT subs or your company's preferred AI gateway via BYOK, with no monthly fees.

Power users can upgrade to paid tiers for big orb discounts, while everyone else in the workspace can remain on the free Hobby tier and consume your pooled workspace credits for orbs pay-as-you-go.

Also, you get free SAML/OIDC SSO for the whole workspace if at least one member is on a paid tier.

Finally, we're now formally extending our zero and minimal data retention policy to all Amp users and workspaces, not just to our Enterprise tier. (Everyone was always covered by it for all Amp usage since we started, but until now we could only contractually guarantee that to our Enterprise customers.)

One More Thing: More BYOK Options

Update (September 30, 2026): These are now available to all Amp users on every tier. Set them up in Model Routing. Thank you so much to our Megawatt and Gigawatt members who got early access and gave us valuable feedback!

Today, Amp Megawatt and Gigawatt members are also getting early access to more BYOK providers:

• OpenRouter
• Amazon Bedrock
• Google Cloud Agent Platform (f/k/a Vertex AI)
• Azure Foundry
• Vercel AI Gateway
• Cloudflare AI Gateway
• Ollama Cloud
• OpenCode Go
• Custom endpoint URLs

To try these, configure them in Model Routing in personal settings or workspace settings.

We've added a Restack button that organizes all of your thread's changes into a cleaner set of commits. Use it to split a large diff into logical pieces for review, clean up an agent's intermediate commits before merging, or combine small related commits. The final file contents stay the same.

Read how to restack and review your changes in the docs.

You can now choose the models behind Amp's builtin modes and put your own agents on the Dial. There are two tabs in Settings → Mode Dial.

Tune Your Modes

In Tune Modes, choose the model and reasoning effort for a builtin mode's main agent, Oracle, or subagents. Use it to run those models through your own API key or ChatGPT subscription. The mode keeps its prompt and tools.

Connect your key or subscription in Model Routing, then choose models it supports. You can change just the Oracle, or all three roles. Anything left on Auto follows Amp's choices as models improve.

Billing follows your provider connections.

Build Your Own Dial

If you often find yourself using custom agents you built with plugins, like a dedicated code reviewer or a security agent, you can place them on the dial too. Build Dial lets you combine the builtin modes with your agents:

Keep medium and high for building, and add a reviewer with your team's review instructions. A plugin agent can extend a builtin mode, so you only need to describe what it should do differently.

Drag two to four modes onto the dial, put them in order, and hold to save. Use the mode picker in the app or press Ctrl+S in the CLI to switch between them. Workspace admins can set a shared dial too. Your personal choices take precedence.

Make the dial yours. The docs cover both tabs.

When you send a message while the agent is working, it's now delivered at the next possible opportunity, instead of being queued until the agent finishes its turn.

This means the agent acts on your feedback sooner and doesn't waste time on unnecessary verification steps.

Most people won't need to change how they use Amp.

If you do find Amp steering too abruptly, we've found that it works well to phrase your prompts like "When done, then ..." instead of "Now, ...".

Ship, Review, and other builtin actions still queue, because usually you want to wait until the agent is done before shipping or getting a review.

If needed, you can still queue from Amp or queue in the Amp CLI.

Your orb now has a desktop you can see and control.

Use the Desktop tab in any orb thread to get a high-resolution interactive Linux desktop.

It's useful for verifying the agent's work when developing for Linux, Android, or the Chrome extension API, or when working with file formats that need to be opened in desktop applications. It's also useful for computer use, CAD, and anytime you just want a desktop in the cloud.

Modibo Sissoko, an Amp user, sent in a video of how he tests .docx files exported by his application in LibreOffice to make sure they look right:

And if you're curious what Puck does for fun when not helping you, turn on Fun Games in Desktop:

Claude Fable 5.1 now powers Amp's ultra mode, replacing Fable 5.

It's very good at writing, very good at taking direction mid-task, and very good at working on its own. And it costs less to run.

Long Tasks and Proof of Work

What won us over is how much better it got at long horizon work, at giving proof of its work, and at iterating on that proof. It runs for hours on its own, and when the proof doesn't hold up, it goes back and fixes the work, then proves it again.

Some examples:

• Hamish told it key presses felt laggy in our iOS app and asked it to find out why. Two hours later it had a side-by-side video of the old and new builds typing the same sentence on an iPhone simulator. Along the way it caught a two-pixel height difference in its own comparison, corrected it, and re-recorded. Typing latency in Safari went from 85 ms to 8 ms.
• Thorsten recorded his screen creating a new thread on ampcode.com and asked it to make that twice as fast, however long that may take. Fable 5.1 pulled every frame out of the recording to time each step, then found the biggest delay was waiting for the server to finish creating the thread. Creating a thread got 45% faster.

Writing

Writing is where it impressed us the most. So far we haven't been big fans of using AI for prose. Fable 5.1 changed that. The text it produces reads more like it was written by a person. It explains the idea behind a change instead of every technical detail, and draws a diagram when that's clearer than a paragraph. We ended up using it for our new docs pages, where it not only surprised us by writing concise prose but also by running the features on a dev server, executing them end to end, and documenting them with screenshots and demo videos.

Steering

We steer it a lot more now. Fable 5 would sometimes ignore an instruction sent mid-task and carry on with the work it already had. Fable 5.1 does both: it finishes the original task, does what you just asked, and reports on each separately. It addresses every instruction you give it, even several at once. It works great now that Enter steers by default.

Cheaper

And it costs less: ultra threads are about 35% cheaper than before. Cache reads are 75% cheaper than on Fable 5, and in a typical Amp thread, over 90% of tokens are cache reads.

How To Use It

ultra is for the work where the outcome is clear and the path is not. Fable 5.1 is at its best there. A few habits help:

• Tell it what done looks like, and how to prove it. Example: "The sidebar stutters when scrolling through a few hundred threads. Find out why and fix it. Show me a video of scrolling before and after on the same thread list, and frame times measured in Safari, not Chrome."
• Steer it while it works. If it's heading somewhere you don't want, say so in the moment. You can also hand it new tasks while it's busy; it addresses all of them without dropping the one it's on.

What the Team Says

Very impressed by Fable 5.1. It's very good at writing, it's very good at... everything really? I'm in a thread where I constantly reply to 2-3 different things and it perfectly keeps them apart. It's like having two conversations at once.

— Thorsten Ball

I've also been impressed with Fable 5.1. Feels less hand-wringy than Fable did.

— Camden Cheek

In my code reviews I agree with its changes more than I agree with the previous Fable's. And I steer it a lot more, because it handles multiple requests at once.

— Hitesh Sagtani

The first challenge in code review is figuring out which files to read first. Amp now orders diffs intelligently and highlights which files contain the essential changes.

Click the file order button to toggle between alphabetical and intelligent order. Amp reads the diff, finds the files that best explain the change, and moves them to the top.

Less relevant files, such as tests, fixtures, and generated code, will be shown in muted colors below the important ones.

If the diff changes while you're reviewing it, a blue dot over the button will indicate that there is an updated ordering. Clicking it will update the diff with the new order.

Every thread in Amp now comes with its own space to talk.

Hit Enter and you're in. Turn on your camera, share your screen, and talk it over with your team while the agent works.

No links to paste, no calendar invite, no other app. The call lives where the work lives.

In the future, we see the space becoming a place to talk freely, alone or with others: brainstorm, whiteboard, talk with Puck or other agents, discuss the thread or spawn new ones... who knows?

We're leaving it open. For now, it's just a space. What you do with it is up to you.

Control your orbs from anywhere.

Install the iOS app through TestFlight[^1], and the macOS app through direct download.

Download at ampcode.com/app.

It's orbin' time no matter where you are.

Amp can now use a Git identity that is separate from the email on your Amp account. Pick the name and verified email that should appear on commits made in orbs.

You can ask Puck to set it for you:

If you have not added the identity yet, Puck sends a verification link to the email address. Once you click it, Puck gets notified and can make the identity your personal default if you asked it to.

You can also manage identities under Signing Keys. Your personal default applies to personal projects unless you choose another identity in a project's settings. Workspace admins choose one rule for the whole workspace:

• Amp uses the Amp identity.
• Amp Account uses each member's Amp account.
• User Choice lets each member choose.

When Amp starts an orb, it sets GIT_AUTHOR_* and GIT_COMMITTER_* from the selected identity. If commit signing is on, Amp only signs for an email you have verified.

Your Amp login can stay tfc@ampcode.com while your commits use tim@culver.house.

Projects in Amp can now include more than one repository.

Additional repositories are checked out to an adjacent directory in the orb and the agent is made aware of them. The changes panel will show the diff across all repositories in the project.

To add additional repositories, specify them when creating the project or later in project settings. You can add up to 20 additional repositories per project.

Only the primary repository's .agents/setup script runs automatically on orb setup. If an additional repository requires initialization, you should update the primary's setup script to include this, or ask an Amp agent to make this update for you.

We are removing the sidebar from the Amp TUI.

Why? Because orbs, runners, and cross-agent messages means that there are more threads than ever. We believe the best place to keep track of all those threads is in the Amp native and web apps, with their more powerful sidebars.

The TUI is still great at what it does best: local, interactive threads in a single environment. It already comes with its own very powerful multiplexing functionality, complete with tabs, panes, and more; the humble terminal. Adding our own layer of multi-environment multiplexing on top proved to be a less-than-optimal user experience.

But when you need scale, running multiple orbs in parallel, across your team, the best way to manage this complexity is in the web and native app.

---

Perhaps some of you are asking "Why do you keep ripping out the stuff I love?".

Because we believe that this is the best way to use Amp, and the best way to develop software with agents, and we think it's our responsibility to push you in that direction.

Using orbs in the web and native app is how to get the most leverage from the most powerful models.

You can now store scripts to set up orbs outside of your repository. Amp can store pre-clone and pre-setup scripts in your project settings and access them when spawning an orb.

The pre-clone setup script gives Amp anything it needs before it clones the repository:

• Install Git extensions that fetch files during checkout.
• Configure certificates for an internal Git server.
• Configure a network proxy needed to reach the Git server.
• Connect the orb to a private network with Tailscale (known issue: use TAILSCALE_API_KEY, OIDC is not yet working with pre-clone scripts).
• Install a credential helper required by the Git server.

The pre-setup script lets you work with orbs when you aren't ready to commit setup files to the repository. Amp agents and Puck can access the scripts and set them for you. Give Puck this prompt, or start a thread for the project with this prompt:

Amp will then inspect the repository and decide which work belongs before or after the clone. It will write and test the scripts, then save them in the project settings.

The scripts are also available on the project settings page, where you can review or edit them by hand.

We use orb portals all the time to share what we're builing and get feedback.

But the URLs were ugly and auto-generated. So, we made them nice and friendly. Now, instead of sharing t-01a0095e-9568-whatever-p1234.onamp.dev, you can share foo--yourname.onamp.dev or even use your own domain like park.mixfox.org (which is on an orb, basically).

This is especially nice when a portal is a long-lived application, not just a preview of changes to your local dev server. And that's increasingly how teams are using portals.

Click the in the Portal tab to set the hostname, or ask Amp to do it for you in an orb. You can set up a personal custom domain or a workspace custom domain, or just customize the hostname prefix before --yourname.onamp.dev.

You can now ask Puck about your token, credit, and orb usage.

Try questions like:

• Which threads used the most tokens today? Orb time?
• Which models did I use the most in my 5 most expensive threads today?
• In my monorepo, based on my latest threads, can I use a smaller orb size or would that make stuff too slow?
• Is it orbin' time? To the millisecond, how much orbin' time have I had in my threads from the last 3 hours?

Puck reads your personal usage and per-thread usage to answer these questions for you. Just ask Puck, or click Explain Usage on those pages.

You can also run amp usage --details and amp threads usage <thread-id> --details to get the data yourself, or to make a cool visualization of your Amp usage in an orb portal.

You can now connect remote MCP servers on ampcode.com and use them in orbs, the TUI, and with Puck.

To add an MCP server:

1. Visit ampcode.com/settings/mcp-servers,
2. Select a pre-configured server or click "Add MCP Server"
3. Log into the server using OAuth,
4. Start a thread in an orb, the TUI, a runner, or talk to Puck:

Amp supports connecting hosted MCP servers using Streamable HTTP with OAuth or Bearer tokens, personal and workspace configuration of MCP servers, and the use of MCP-provided tools.

MCP Apps, Resources, and Prompts are not supported.

You can now bring your team into your orb.

Use @ to tag members of your team, and they'll be able to view, drive, and send chat messages to the thread.

We've been having a lot of fun with this feature recently. Here are a few examples:

← 1 / 9 →

Students and teachers can now subscribe to Amp for $10/month, half the usual price.

What do you get for $10? Quite a lot!

You get to use the best frontier agent. You get orbs, our remote machines that let you run agents from anywhere without supervision.

You get code hosting for unlimited public/private repositories.

And you get to use great models, through linking your ChatGPT sub for GPT-6/GPT-5.6 or 𝕏 Premium+/SuperGrok subscription for Grok 4.6. Plus $10 in credits each month for use on any other model.

Get it at ampcode.com/edu.

You can now call Puck and talk with it out loud:

Calling Puck is powered by gpt-realtime-2.1. It delegates work to the Puck agent you already know, powered by GPT-5.6 Sol. Once the agent responds, gpt-realtime-2.1 summarizes the answer out loud while the full response appears in the thread.

You can now have a proper back-and-forth conversation with Puck without waiting for text responses to stream in. Just talk. That makes it easier to coordinate parallel work, get progress updates, send follow-up instructions, or talk through big ideas without typing, whether you are sitting in front of your computer or on the go.

Here are some conversation starters we have used:

• "Check my active threads and tell me which ones need input."
• "Review the messages in the #issues Slack channel where I am tagged. Read them to me one by one so we can talk through how to fix each one."
• "Start an agent to fix the CI failure, tell me what caused it, and keep me updated on the fix."
• "The executor lease reconciliation pipeline broke. Tell me about the changes made to it yesterday."

With so much work happening in orbs there needed to be a new place to store Amp plugins and skills. So we added global plugins and skills. They're Amp-hosted, built for agents, and work everywhere Amp runs.

You can now tell Amp to:

• "Create a personal plugin that runs our formatter on every file the agent edits."
• "Import the browser-testing skill from this repo into my personal skills so I can use it on all my projects."
• "Does anyone on my team share a skill for writing release notes?"
• "Check if any of my imported plugins are out of date."
• If you're a workspace admin: "Copy Thorsten's plain-writing plugin into our workspace plugins."

You can find them in your User Settings and Workspace Settings:

Personal vs. Workspace

Personal plugins and skills are good place to experiment and try things out. You can have your agent build something and reload the plugins live within the same thread.

Workspace plugins and skills are pushable by workspace admins, and are loaded by default for everyone, so we recommend only publishing there once you've tested out something yourself. And if you want to make big changes to an existing workspace plugin, import it into your personal one, give it a test, and then publish it back up.

Remix and Share

Personal plugin and skills are much more than a replacement for ~/.config—they can be shared with your workspace too, letting people discover, import and remix them.

If there's upstream updates you'd like to pull into your version, or just update your version, you can run amp skill update <name>, amp plugins update <name>, or just ask Amp:

• "Update the browser-testing skill to the latest version."
• "Check if any of my imported skills are out of date."

We changed the Dial. Link a ChatGPT subscription and low, medium, and high only use OpenAI models: as the main agent, as the oracle, as the thread reader, as code review. Every model behind those modes is an OpenAI model, billed to your subscription.

Before this change, you'd still pay for tokens with a subscription linked, because parts of the work ran on other models: low and the thread reader on GLM-5.2, the high oracle on Claude Fable, code review on Haiku — all billed to Amp credits. That confused people, and we get why.

With a subscription connected:

• low runs GPT-5.6 Terra instead of GLM-5.2.
• medium runs GPT-5.6 Sol, as before.
• high runs GPT-5.6 Sol as both agent and oracle. The oracle used to be Fable.
• The thread reader and code review move to GPT-5.6 Terra.

Doesn't this make the modes worse? Barely, and less every month. The frontier models have converged: any of them gets you to a good result with a good harness. We swapped the default model for most users overnight and nobody complained. So the modes stay at the frontier, and the tokens come out of a subscription you already pay for.

high also drops its credit minimum when your subscription is active. There's no Fable call left to pay for.

ultra doesn't change. It runs Claude Fable on credits, because ultra is for the tasks where you want the strongest model, whatever it costs.

If you don't have a subscription, nothing changes. The modes run as before, on Amp credits.

Link your subscription and turn the dial.

People are using a lot of orbs. We love to see that. We've shipped a lot of things so that Amp subscriptions keep covering the whole month of orb usage for almost everyone, even as orb usage grows quickly.

Way back on July 27, we cut orb prices by 20% for everyone.

This week, we shipped a lot more improvements.

We added a new a1.medium size with 4 CPUs and 8 GB of memory. It is 50% cheaper and a better fit for most projects than the previous a0.medium.

Orbs now auto-pause after 5 minutes of inactivity, down from 15 minutes.

We've sped up orb startup time considerably, especially when another team member has recently created an orb in the same Amp project.

You can now choose which orb size to use per-thread, so you can pick a smaller default to save money but go big for especially resource-intensive work.

When starting new orb threads from the Amp CLI with amp -ox '...', the new flag --orb-size <size> lets you specify which orb size to use (instead of the project's default).

When asking the agent to create other threads, you can now tell it to use smaller (or larger) orbs, which lets you use smaller orbs for simpler fan-out tasks on projects.

Prices for orbs have gone down or stayed the same at every level and for every compute/memory combination. The new set of orb sizes is:

• a1.tiny: 1 CPU · 2 GB memory · $0.08/hour
• a1.small: 2 CPUs · 4 GB memory · $0.17/hour
• a1.medium: 4 CPUs · 8 GB memory · $0.33/hour
• a1.large: 8 CPUs · 16 GB memory · $0.66/hour
• a1.xxlarge: 16 CPUs · 32 GB memory · $1.32/hour

We've automatically upgraded projects to the equivalent new orb sizes. If you want to use a different orb size, you can update your projects' settings on the web, or ask Amp to do so using the amp projects subcommands.

For remote development in orbs to be better than local dev, you need to be able to easily try out the agent's changes in your app, with live reloading. No VPN, no port juggling, and no waiting for preview deployments.

Today, we're shipping portals, which let you access anything running in an orb that listens on a port and speaks HTTP.

All you need to do is ask Amp: show me in a portal. Or words to that effect.

Obviously, you can use portals to try out the features or fixes made by the agent:

You can also annotate and comment on anything:

But you can also have the agent build ad-hoc web apps for you to debug or understand the system:

Portals are accessible to anyone with access to the thread. They go to sleep and wake along with your orb. Use the gear icon in the Portal address bar to change the hostname or check who has access.

Make a thread multiplayer with on the web, and your team members can also make changes and see them live in the portal.

Services

When you say show me in a portal, the agent knows to create or look for a .amp/services.yaml file and then run amp orb services <ensure|start> to run your app and expose it via HTTPS. Your app needs to respect the PORT and PUBLIC_URL env vars it's given.

Amp will handle all of this for you; agents are really good at that kind of stuff. Commit the .amp/services.yaml file and Amp's changes to your dev server config so it's faster next time.

What about my app's sign-in flow? What about ...?

You don't want to waste time signing into your dev server each time. We recommend adding a way for humans and agents to bypass sign-in flows (such as username/password or OAuth) in your dev server, by visiting a URL like:

https://localhost:2000/__dev/log-me-in/{email}?returnTo={path}

We've documented this pattern and more in the portals documentation. Also see Putting an Agent in an Orb for more about how we're using portals. Tell us how else you and your agents are using portals!

You can now upload any file to your orbs for Amp to see and use: videos, logs, PDFs, spreadsheets, datasets, and more.

What new stuff can you do? Here's what we've found useful so far:

• Screen-record your app and ask Amp to fix or improve what it sees.
• Debug issues from log files.
• Turn presentations and spreadsheets into interactive websites.
• Generate videos and CAD files from media inputs.
• Transcribe video and audio.

Amp Labs has partnered with Westpac, one of Australia's oldest and most respected companies, a fixture of Australian business for more than two centuries, to transform how the bank builds and delivers technology.

Amp Labs operates on the thesis that the biggest impact comes from working with carefully selected customers with deep mutual trust and a shared ambition to explore the frontier together.

The frontier isn't just the models and the agent, it's putting them to work on real enterprise problems, like migrating and modernizing data systems that millions of people rely on every day. Being on the front lines and doing the work inside these companies is how we keep Amp on the frontier for everyone.

We are building a team to work side-by-side with Westpac engineers, on site in Sydney.

The Founding Team

Gareth Townsend Previously Block Matty Evans Previously Ethereum Foundation Andrew Gerrand Previously Google Chris Nicol Previously Canva Ryan Christensen Previously Canva

Join Us

We're hiring. If you are Sydney-based and want to work on the frontier inside Australia's first company: join@amplabs.com.

Two weeks ago we shipped the Dial and quietly did something that's supposed to be traumatic: we changed the default model.

Before the Dial, Amp's default mode was smart, running Claude Opus 4.8 and carrying more than half of all new threads. The Dial made medium the default, and medium runs GPT-5.6 Sol.

Most Amp users switched from Anthropic to OpenAI overnight.

We braced for the outcry. Every model swap in every coding tool comes with one. We prepared migration docs, packaged the old modes as installable plugins, and waited.

Nothing happened. Not a single complaint.

Here's what the switch looked like in production:

The day before the Dial shipped, smart carried 55% of new threads. A week later: zero. Last week, the four Dial modes carried 93% of all new threads, and medium alone carried two-thirds. Of the users on the Dial, 69% never set it to anything but medium.

And the Amp plugins we shipped to bring the old modes back — exact prompts, exact models, one command to get smart again? Almost nobody installed them.

What This Tells Us

The differences between frontier models are now small. Small enough that for one engineer on one task, switching models won't visibly change the result.

But they still matter to us, here at Amp: across every thread on every tier, small differences compound, so we keep benchmarking and swapping models. That's the trade. The default is good because someone is paid to care about it, and it doesn't have to be you.

What does change your output are three things, none of which is a model: how hard the task is, what context you put in, and how closely you review what comes out. All three have more impact on the outcome than whether you use this or that latest frontier model.

The Dial covers the first one: how hard the task is. You tell it how hard the task is and the corresponding setting on the Dial uses whichever model wins it right now, re-tested constantly. You know your tasks, we know the models.

And for the other two — the context and the review — the rest of Amp lets you do the best job with that.

Amp's orbs can now receive requests and react to events outside Amp.

That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.

More Ways to Wake an Orb

GitHub issues are just one example. You can use the same pattern to:

• Investigate every CI failure on main and post the findings to Slack.
• Watch for new releases of your dependencies, then review the changes and open an upgrade PR.
• Start a fresh thread when someone opens a Linear issue, then comment with a fix or report.
• Turn a bug report from Discord into a reproduction and pull request.
• Resume a rollout when a deployment or security scan reports back.

The event decides when the orb wakes up. You decide what it does next.

From a GitHub Event to an Orb

Here is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:

Amp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.

Then Amp loads the plugin and registers its durable endpoint:

If the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:

A Wild Issue Appears

Once the webhook is active, someone opens issue #57:

GitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:

The new thread inspects the current issue and relevant code, then reports what it found:

The typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.

How It Works

Webhooks work through the Amp Plugin API. When you ask Amp to listen for an event, it creates a plugin in the orb and calls amp.createWebhook to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.

When a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.

React to Events However You Want

amp.createWebhook gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:

• Continue the owning thread with its context intact by appending the event to ctx.thread.
• Start a fresh thread in an orb with amp.getBuiltinAgent(...).createThread({ executor: 'orb' }).
• Keep durable state so it can react every time, or handle one matching event and then stop listening.

That is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.

The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.