Connect your AI in about thirty seconds.

Quickstart

There is nothing to install. Your AI app signs into Idle9 the same way it would sign into any other service you connect to it.

1. Get a computer. From your dashboard, give it a name and hit Create. Real Ubuntu with root and 20GB of disk, ready in a few seconds.
2. Give your AI app the URL. Copy the MCP URL from Connect and add it as a connector. The app opens a browser, you approve one screen, done.
3. Ask it to do something. “What computers do I have?” is a good first one. After that, treat it like a machine you own: ask it to install things, clone repos, run servers.

Connecting each app

Two ways in. Signing in with the app is the one to reach for; a token is the fallback for anything that cannot open a browser. Both reach the same endpoint with the same access.

Apps that can sign themselves in

Clients that support MCP authorization — Claude, Cursor, VS Code — need nothing but the URL on your Connect page. Paste it in, the client opens a browser, you approve one screen, and it is connected. No secret is copied, and nothing sensitive ends up in a config file on disk.

Everything the client needs it discovers for itself: it reads the metadata at that address, registers itself, and asks for an authorization code with PKCE. Approved apps are listed on the MCP access page, and disconnecting one there cuts it off immediately — along with every token it holds.

Claude Desktop, via the bridge

If your Claude Desktop build predates remote connectors, it reaches Idle9 through the mcp-remote bridge. Add this to claude_desktop_config.json:

{
          "mcpServers": {
            "idle9": {
              "command": "npx",
              "args": [
                "mcp-remote",
                "https://mcp.idle9.com",
                "--header",
                "Authorization: Bearer YOUR_TOKEN"
              ]
            }
          }
        }

Claude Code, Cursor and other native clients

Anything that speaks Streamable HTTP natively can use the URL directly:

{
          "mcpServers": {
            "idle9": {
              "url": "https://mcp.idle9.com",
              "headers": { "Authorization": "Bearer YOUR_TOKEN" }
            }
          }
        }

Headless clients, scripts and CI

Anywhere a browser cannot be opened, make a token on Connect and send it as a bearer header against the same URL. The plaintext is shown exactly once, at creation, so copy it then — and revoke it from that page the moment it is no longer needed.

What your AI can do

Once connected, these tools appear. The machine tools always act on whichever computer is currently awake.

Tool	What it does
list_environments	Every computer on your account, with quota usage
create_environment	Set up a new computer
wake_environment	Wake one, sleeping whatever is currently awake
sleep_environment	Archive and park a computer
get_active_environment	Which computer the tools below act on
run_command	Run a shell command
write_file / read_file	Create, edit and read files
list_directory	Look around the disk
install_package	Install software — it stays installed
expose_port	Publish a port and get a URL
create_checkpoint	Save the computer under a name, without stopping it
list_checkpoints	What it can be put back to, where it is now, and how much room is left
restore_checkpoint	Put the computer back to a saved checkpoint
delete_checkpoint	Remove a saved checkpoint
get_environment_info	Resources and state

The tool names still say environment, which is what a computer is called in the API and on your dashboard. It is the same thing.

Resources

A computer is burstable. It reserves only what an idle session actually uses and stretches when you put it to work, so installing dependencies, running a build or starting a dev server all happen at full speed without you sizing anything in advance.

Disk is not burstable — a computer has 20GB of fast local disk, and add-ons extend it in 50GB blocks from the billing page.

If the platform is momentarily full, a computer you start joins a queue instead of failing. It keeps its place, starts by itself as soon as room frees up, and the dashboard shows where it is in line. Nothing is needed from you while it waits.

Sleep and wake

A computer sleeps automatically after 20 minutes without activity. Sleeping archives the whole filesystem to storage and destroys the running container; waking restores that archive before your AI reconnects. Files, packages, databases and environment variables all survive — this is what makes the machine feel like it remembers rather than resets.

Only one computer runs at a time. Asking your AI to wake a different one will archive and sleep the current one first — it is never discarded.

Checkpoints

Sleeping saves where you were when the computer stopped. A checkpoint saves where you were before something went wrong — the state of the machine, files and installed software alike, taken while it keeps running and kept under a name you choose. Restoring one puts the computer back exactly as it was.

Only the first one copies the whole machine. Each one after it saves what changed since the last, so they are quick to take and cost a fraction of the disk — which is the point: a save point you have to ration is a save point you do not take when it matters.

Your AI can take and restore them itself, and it is told to save one before anything hard to undo: a database migration, a dependency upgrade, a big refactor. Persistence cuts both ways — a bad change here is permanent, and starting from a clean sandbox is not something this machine can do. A checkpoint is what it has instead.

The copy is taken from the machine while it is running, so anything half-way through being written — a database mid-transaction, a build mid-compile — is captured half-written. Finish or stop that first. For the case checkpoints are actually for, which is "before I do the risky thing", nothing is in flight anyway.

You can do all of it yourself from the environment's page, without asking your AI. That page is also where you delete one, and where you see which of them your assistant took rather than you.

Restoring replaces everything: work done since the checkpoint is gone unless it was pushed to a repository or kept as its own checkpoint first. Both the dashboard and the tool offer to save the current state before rolling back, and taking that offer is almost always right.

It does not delete the checkpoints you saved after the one you go back to. They stay in the list and stay restorable, and anything you save from that point on branches off it — so going back to try something a different way costs only the work you chose not to keep. The environment page marks which checkpoint the computer is currently running from, and draws the branches where you made them.

Because each checkpoint holds the changes since the one before it, deleting an early one is refused while later ones are built on it — you are told exactly which, and can delete them together if that is what you meant. The most recent ones are always free to remove.

There is a limit, because your checkpoints live on our disks — a number of them per computer, and a storage allowance that grows with the workspace you pay for. A heavy project therefore keeps fewer of them. When the allowance is full, nothing of yours is deleted to make room: you are asked to remove a checkpoint you no longer need, or to add storage.

Preview URLs

Ask your AI to expose a port and it returns a public URL for whatever is listening there. Useful for looking at the app it just built without deploying anything.

SSH

It is your computer too. You can open a real terminal on it with the SSH client you already have, and scp, rsync and any editor's remote-host feature work through the same configuration.

One command does the whole setup: curl -fsSL https://idle9.com/ssh-setup.sh | sh -s -- <computer-name>. It makes a key if you have none, installs the helper that carries the session, writes the ~/.ssh/config block, and then tries the connection so it can tell you what is left — usually just pasting the public key it prints onto the Connect page. Run it again whenever you add a computer; it reports what it changed and changes nothing twice. On Windows, run it in WSL or Git Bash.

Only the public half of your key is ever sent to us — your private key never leaves your machine, which is the whole reason SSH authenticates this way. The same page shows the config block if you would rather write it yourself, and connecting is ssh <computer-name> either way.

It does not use port 22. The session travels over the same HTTPS front door as everything else, which is why the setup includes a small helper script: it means no customer is ever told which piece of hardware their computer is running on. Sessions are dropped after 30 minutes with nothing happening; your files and processes are untouched, so you can simply reconnect.

SSH connects to a computer that is already awake — it will not wake one for you, because a wake restores the whole filesystem and your client would sit there looking like it had hung. Ask your AI to wake it, or start it from the dashboard, then connect.

Tokens and security

• Only a hash of your token is stored, so a database dump yields nothing usable. The plaintext is shown once, at creation.
• Revocation is immediate — the machine re-checks the token on every request and never caches it.
• An MCP token cannot reach the operator API, and cannot create or revoke other tokens. A leaked token cannot renew itself or escalate.
• Billing actions need an interactive sign-in. A token pasted into an AI client can never start a charge or change your plan.

Getting help

Email [email protected] and include your account email and the name of the computer involved.

For everything else there is Discord — the fastest way to reach us and other people using Idle9 — and @idle9dotcom on X for release notes. Longer write-ups go on the blog.