Ampcode Release Notes

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.

Puck working on a request to set up a pre-clone script that installs Git LFS

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:

An Amp thread starting setup without committing files to the repository

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

Sharing an orb portal in Slack with a rich preview and an Open Portal button

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.

The Portal Hostname dialog with a friendly onamp.dev hostname

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.

The MCP settings screen showing preconfigured MCP servers

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 →

Thorsten Ball passes a request for an orb sticker from Tim

Tim Lucas mentions Lewis Metcalf to ask for feedback on a code diff

A teammate mentions Tim to ask for a documentation review

A message copies Camden Cheek into a thread

A teammate mentions Rocko Reager to ask for help with a sidebar bug

Tim Lucas mentions Rocko Reager to ask if he saw a message

Teammates coordinate synchronized orb animations in a thread

Tim Culverhouse mentions Lewis Metcalf before asking Amp to start work

Thorsten Ball mentions Brett to ask about shipping an orb navigation change

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

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 plugins settings showing plugins with their source

Workspace skills settings showing shared skills

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

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.

The mode picker with the dial on medium, showing GPT-5.6 Sol as agent and oracle and a green ChatGPT subscription LED

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

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.

The new thread dialog with the five a1 orb sizes

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

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

Prompt asking Amp to monitor GitHub issues and pull requests with a webhook

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.

Amp describing the GitHub webhook plugin it will build …

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 menu on the web.

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

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:

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

← 1 / 4 →

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.

Using Amp in Slack to investigate and fix a user bug report

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.

Using Amp in Slack to root-cause and resolve a production incident

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.

Puck notifying a teammate in Slack that an issue has been resolved …

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. See current tiers and pricing.

Tier FAQs

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 …

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.

An Amp agent creating a new thread in an orb and uploading the changed news post

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.

Or 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 by pulling in the important files:

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": "user@example.com",
		"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", …