Ampcode Release Notes

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:

• Visit ampcode.com/settings/mcp-servers,
• Select a pre-configured server or click "Add MCP Server"
• Log into the server using OAuth,
• 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 talk with Puck in realtime

Realtime chat with 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."

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

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

low runs GPT-5.6 Terra instead of GLM-5.2.

medium

medium runs GPT-5.6 Sol, as before.

high

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.

Orbs

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!

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.

Three weeks ago, we shipped agents in orbs.

Today, more and more of our work happens inside orbs. In fact, the orbs are quickly becoming the de facto "unit of work." They contain not just the code of the solution, but also the description of the problem, and often they are the running, executing solution itself.

The lines between description, solution, code, and computation are all blurring and merging into the orb.

As more of our work moves into orbs, we need better ways to share, control, and collaborate on those orbs and the artifacts they create.

Multiplayer now lets you do just that.

Turn any of your orbs into a multiplayer environment from the thread's Share menu.

Anyone in your workspace can then join the thread, send messages to the agent, and access the orb's portal, file changes, and shared terminal until Multiplayer ends.

Agents in Amp can now set their own schedules and wake themselves up. When a schedule fires, the agent wakes up with its saved prompt and continues right where it left off, with all of its context and history. Works great with Slack, Puck, and spawning other agents, too.

You can now say things like:

• "Every morning, dig up the five slowest database queries of the past 24 hours, investigate with an orb in ultra mode, and DM me the list on Slack."
• "Merge this, and remind me on Slack in two days to clean up the feature flag and roll it out to everyone."
• "My recent backfill job thread, check on it every ten minutes and ping me if it stalls or starts outputting errors. Let me know when it's done."
• "Every hour, use the inference-error-triage skill to inspect errors from the last hour and group related ones. For each newly discovered group, spin up a new thread to fix the errors and report back in the #bugs Slack channel."

Here's a real schedule at work: a thread watching a long-running job until it's done.

Say Hello to Puck, your new assistant in Amp:

Open it up from anywhere on ampcode.com:

Puck is always available and has access to many different tools to help you manage your agents in Amp.

Here are some examples of things you can ask Puck to do:

"Spawn a new agent in an orb to fix this bug the user reported in the screenshot."

"Start an agent in ampcode/amp to investigate why CI is failing."

"Find me that massive thread I had where I was investigating that 500 server issue."

"Once this thread is done, archive it."

"Create a new project and start setting up a 2026 Rust development toolchain in it."

"For each script in our ./scripts folder, spawn an agent in an orb to try and run it again dev server. Then compile their feedback about what worked/didn't work.

Think of Puck as a quick assistant and a home base for launching and coordinating other agents.

It's an experiment, too. Puck is flexible, and we've already found more ways to use it than we expected. We're excited to see what you come up with.

Time to open Puck and put it to work.

You can now summon Amp in Slack.

Connect your workspace from Amp's settings, then mention @Amp in any channel or thread. Amp sends your message to your personal Puck, which can initiate bug fixes, spike new features, answer questions about your codebase, and find and manipulate existing threads.

Here are a few examples of how we've been using it:

Fix a User Bug Report

A user reported a bug with a screenshot. Amp read the screenshot, reproduced the issue, and posted back a fix.

Resolve a Production Incident

A production alert posted to a Slack channel, Amp identified the likely culprit commit, pulled production logs to verify, and pushed a fix to the production Terraform config.

See full investigation thread.

Close the Loop with Your Team

Two teammates investigated the same issue. One resolved it and asked Amp to ping the other user from their investigation thread. The other user then archived their ongoing threads from Slack.

Search Slack for Context

Amp can also search through Slack to pull discussions relevant to its current task.

The Amp Slack integration compiled the examples used in this post.

Install the Slack Integration

Open Workspace Integrations as an Amp workspace admin, select Connect a Slack Workspace, and authorize the Amp app in Slack.

(If you don't yet have an Amp workspace, create one.)

Individual users should link their Amp user directly with their Slack user in Personal Settings.

Mention @Amp in any Slack channel or thread.

Read the Amp manual for more details.