Ampcode Updates & Release Notes

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.

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.

Today we're launching Amp Subscriptions in Beta. You can now subscribe monthly to Amp and explore the frontier with us, with cheaper and more predictable pricing:

Subscription FAQs

If you subscribe on or before Sunday, July 19[^1], you'll get bonus 2x usage for orbs and agents in the first month.

Amp Is Not (Necessarily) Expensive Anymore

Amp just got a lot cheaper for many of you, especially if you link your ChatGPT subscription.

We know you've been asking for this for a long time. Until now, Amp's pricing model has been pay-as-you-go for tokens at API prices, no subscription. Compared to other agents on monthly subscriptions, this made Amp more expensive—"the Apple or Porsche of agentic coding tools", to put it nicely.

But everything is changing. Great tokens are reasonably priced. Good-enough tokens are downright cheap (like GLM-5.2 in our new low mode). Being on the frontier no longer requires using the most expensive models.

You can still pay-as-you-go in Amp; monthly subscriptions aren't required.

And, to be clear, to use Amp beyond your subscription's included monthly limits, you need to link your ChatGPT subscription or add paid credits.

The Frontier Runs in Orbs, Not Your Laptop

The frontier is now about agents working for you in parallel, without your supervision, on remote machines. We call these "orbs", and Amp's monthly subscriptions include so much orbs usage you don't need to worry about counting the minutes.

We want you to finally be able to (and want to) kill your singleton local dev environment.

We want you to make your agents go further to prove to you their work is correct, with videos and screenshots and local dev portals, and much less manual code review.

Remember last year, when other agents asked you to approve the agent's work step-by-step, edit-by-edit? Amp users realized before anyone else that was dumb and slow, and Amp never did that.

This shift feels similar to us. It's inevitable, and we want it to go as fast as possible. We hope this subscription makes it easy for you to explore this new frontier with us.

You can now ask your agents in Amp to spawn other agents.

In orbs, your local machine [^1], or on any other machine.

They can send messages and files to each other, too.

Side quests

You can have agents in orbs work on side quests while you continue your work:

Spin up an orb thread with what you know about this unrelated bug, ask it to fix it, then keep working here.

Fan out work

Run four low-mode threads in parallel to test this flow in Chrome at four screen sizes and report back with screenshots.

Find and continue old work

Pull the files from my abandoned prototype thread into this workspace and integrate the useful parts into our current approach.

Offload work to another machine

Start a new thread on cloud-dev-box and upload this test matrix we created. Ask it to run through each row at least 10 times.

Coordinate cross-project work

Spawn an agent in the docs project, send it what it needs to document this API change, and ask it to report back.

Agents running locally, or in orbs, or anywhere else, and sending messages and files to each other? It's a whole new world.

Orbs can now prove their identity using OIDC,
so you can use Amp for ops and infrastructure tasks more safely.

Service providers that support OIDC authentication can be configured to trust
the identity provided by Amp and grant permissions to your orb based on that
identity, without having to inject any secrets into orbs.

For example, we've configured GCP to grant orbs in our workspace read access to
our production logs. This requires zero config from any of our devs, any operations
are fully auditable because they include claims like user ID and thread ID, and
the tokens are all short-lived and tightly scoped to the operations that project needs.

To mint a token, run amp orb id-token --audience <aud> in your orb:

~/workspace/repo$ jwt decode -j $(amp orb id-token --audience test)
{
"header": {
"typ": "JWT",
"alg": "RS256",
"kid": "5A4Ie1hntIuzu4KtaDPXr2HhnButOliWxM9ncVsct1s"
},
"payload": {
"aud": "test",
"email": "[email protected]",
"email_verified": true,
"exp": 1784078965,
"iat": 1784078365,
"iss": "https://ampcode.com/api/workload-identity",
"jti": "78bceb61-4102-4973-8bec-d05d65be4b67",
"project_id": "12038eda-75e9-46fa-b185-f67404f40b2f",
"sub": "workspace:0284a29c-b50a-41f8-b83f-94e5c9b32f5f:project:12038eda-75e9-46fa-b185-f67404f40b2f:user:user_3V306PAAABM94KT1N05NSDQRBD:thread:T-6600f272-b20f-4652-bb6a-3a3c73099d31",
"thread_id": "T-6600f272-b20f-4652-bb6a-3a3c73099d31",
"token_use": "exchanged",
"user_id": "user_3V306PAAABM94KT1N05NSDQRBD",
"workspace_id": "0284a29c-b50a-41f8-b83f-94e5c9b32f5f"
}
}

Alongside standard claims like iss, aud, sub, and exp, Amp adds custom
claims such as workspace_id, project_id, user_id, thread_id, and
email.

Okay, but what can I actually do with that token?

Even after building OIDC into orbs, it wasn't immediately obvious to me how far we
could push an OIDC-based dev env. So here are a few ideas to get the juices
flowing, drawn from both internal usage and feedback from our early partners.

• Configure workload identity federation in GCP and grant access to your production logs and metrics from all orbs in your workspace.
• Add OIDC trust credentials to your Tailscale workspace and grant users on your tailnet the ability to hit services running in orbs so you can share demo apps with your colleagues.
• Commit your SOPS-encrypted dev secrets to your repo, then grant your users' orbs access to decrypt those secrets with AWS KMS so you don't need to maintain 50 secret environment variables in your project settings to run your dev environment.
• Create a PAM entitlement that grants escalated privileges to this specific orb, and add a script to your repo that allows your Amp thread to request an escalation.
• Spin up an oauth2-proxy instance to inject credentials into requests to services that don't support OIDC auth.

Want more help getting started? Head over to the manual for detailed recipes.

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.