Orbs, Explained

By Thorsten Ball | August 25, 2026

Recently, our inbox has been flooded with a variety of reactions to a specific piece of terminology. Some of the messages look like this:

"Orb? What exactly is an orb?" "First it was Ralph, then loops, then graphs... now we're doing orbs?" "What the hell are orbs?" "You simply cannot call them orbs." "I can't stand it when people say 'it's orbin' time'—I hate it when people actually enjoy themselves!"

(Full disclosure: I fabricated that last one for a laugh. It's important to maintain a sense of humor when people get worked up over naming conventions.)

Interestingly, while some are annoyed, others are thrilled. The divide seems to stem from the name itself, so let's clear the air.

Defining the Ecosystem

To understand the "Orb," you first need to understand Amp. Amp is our overarching company and product—a comprehensive development environment paired with a coding agent.

Orbs are a specific component of that product. In technical terms, they are remote agents. Instead of running on your local hardware, they operate on a remote machine. You can command them via ampcode.com, a mobile device, or our CLI.

If you want to be pedantic, yes, they are virtual machines or sandboxes. They are remote environments that we provision, load with your code, and initialize with an Amp agent. However, the "Orb" abstraction allows you to ignore the plumbing of "remote machines."

How to Deploy an Agent in an Orb

To get started, follow these steps:

• Navigate to ampcode.com
• Select New thread
• Enter your prompt
• Hit Submit

Once submitted, an orb spawns, loads your codebase, and the agent begins its work.

The Lifecycle of an Orb

Orbs are designed for efficiency. They don't run indefinitely; they breathe.

When the agent finishes its task and becomes idle, the orb enters a sleep state. It can stay dormant for days or weeks. When you send a new prompt, it wakes up instantly.

The Economic Model: The cost is calculated based on active time: $\text{Total Cost} = \int_{t_{start}}^{t_{end}} \text{Rate}(\text{active}) \, dt$ In short: You only pay for the time the orb is actually running.

Beyond the VM: The "Magic"

When users say "it's orbin' time," they aren't just talking about a remote sandbox. They are talking about a suite of integrated features:

Advanced Orchestration

Orbs can be scheduled. You can tell an agent: "Run this check every 45 minutes for the next 8 hours."

The agent will program the schedule, and the orb will automatically wake up and sleep according to that timer. Furthermore, agents can act as architects: they can spawn additional orbs and exchange files or messages with one another.

# Conceptual example of agent-to-agent communication
amp orb spawn --task "analyze-logs" --target-orb "main-app-orb"

Conclusion

We chose the name Orbs because calling them "remote agents running in ephemeral cloud boxes that wake up based on state and possess unique URLs and collaborative portals" was a bit of a mouthful.

---

Technical Appendix: UI Optimization

Note on portal implementation: To prevent performance degradation in WebKit, we avoid toggling the :last-child state of the app root when appending layers (like toasts, menus, or drag previews).

The Problem: App Root $\rightarrow$ Dynamic Element $\rightarrow$ Trigger :last-child restyle $\rightarrow$ Full subtree repaint ($\approx 10\text{ms}+$ lag).

The Solution: By using a stable tail element, only the tail's state changes, making the operation computationally "free."