Skip to main content

Run AI workloads on any cloud account to find the cheapest GPU.

anycloud scans every region of every account you connect to find the cheapest available GPU. Pool your credits, keep your data — no managed runtime in between.

Your accounts. Your credits. Your data.

$curl -fsSL https://get.anycloud.sh | sh
Get Started →Read the Docs
Pool credits across your cloud accounts
AWSAzureGCPLambda

Why anycloud

Pool credits. Stretch runway.

Same AI job, cheapest available GPU across all your cloud accounts. Spot by default — auto-recovers when preempted, so a long run finishes even when one provider pulls the rug.

Cheapest GPU across your accounts

Sold out of H100s in one region? anycloud picks the cheapest spot GPU that matches across every region of every account you connect — the same GPU is often 2× cheaper elsewhere, and spot pricing gets you up to 80% off on-demand.

Preemption-proof jobs

On spot preemption, anycloud resumes your job from the last checkpoint on a new VM, sometimes in a different cloud. Write to /mnt/checkpoint — most ML frameworks already do this (PyTorch torch.save, TF tf.train.Checkpoint).

Iteration speed compounds

AI research is gated by the run → analyze → plan loop. Teams on anycloud launch hundreds of experiments a day via the Python SDK — months of iteration in weeks.

Your accounts, your control

Nothing between you and the GPU.

Your code doesn't know about the cloud. Read inputs from /mnt/input, write outputs to /mnt/output. Your accounts, your credits, your data.

Your cloud, your credentials

VMs spin up in your own cloud accounts on your own credits. Credentials stay on your machine, encrypted at rest. Switch accounts by flipping one flag — no vendor lock-in, no managed multi-tenant compute.

Docker is the only ABI

Any image runs on bare spot VMs — your existing container, no managed-service runtime, no markup on top of your cloud's spot pricing.

Your data, where you already keep it

Inputs show up at /mnt/input. Outputs land at /mnt/output. Bucket sync to your existing object storage — block storage is 4–7× more expensive at TB scale.

Spend controls

Hard caps on what you burn.

Two account-wide caps gate every dispatch. Throttle compares the live $/hr burn rate across your fleet against its limit. Budget compares calendar-window spend (day, week, or month) against its limit. Blocked submits queue with a visible reason and auto-dispatch when the cap clears — running jobs are never killed.

# Cap live burn rate across every running VM.
anycloud throttle set 20

# Cap calendar-month spend.
anycloud budget set 2000 --per month

# Same flags + --agent-session apply the cap per agent run instead.

In production

Running AI workloads in production today.

AI teams pool credits across their cloud accounts and run CPU + GPU jobs on anycloud — almost exclusively on spot. Thousands of GPU hours and hundreds of thousands in managed spend, and counting.

“We have been using anycloud at @Angstrom_ai to make the gpus go brrrrrr!”
Laurence Midgley·@SilkyDogfish·Angstrom AI

Agents operate it too

Built so agents can drive it too.

Compact JSON, agent-session tagging, spend caps (per session or account-wide), and read-only DB query — so an unattended agent can submit, monitor, and stay inside a budget without scraping table output. See Agents for the surface and the runbook for an end-to-end recipe.

Auto-tagged agent sessions

Every deployment is stamped with the agent that submitted it (Claude Code, Codex, Cursor, Aider). Filter with anycloud list --agent claude or --session <id> to attribute cost and debug runaway loops.

Spend caps

anycloud throttle set 20 caps live burn at $20/hr. anycloud budget set 2000 --per month caps calendar-window spend. Add --agent-session to apply the cap per agent session instead — one runaway loop can't block other work. Blocked submits queue with a visible reason and auto-dispatch when the cap clears. See Spend controls above.

Read-only DB query

anycloud db query "SELECT id, state FROM deployments WHERE state='Failed' LIMIT 20" answers “which jobs failed” without leaving the CLI. Writes refused.

One job, two ways

Use it however you work.

Python decorator or single-shot CLI.

import anycloud
from anycloud.types import CloudConfig

@anycloud.function(
    image="ghcr.io/acme/train:latest",
    gpu="h100:all",
    cloud_config=CloudConfig( credentials="my-aws", spot=True),
)
def train(lr: float):
    # your training loop

train.submit(0.001).wait()
# Submit — anycloud finds the cheapest spot H100.
anycloud submit ghcr.io/acme/train:latest \
  --gpu-type h100 --gpus all --spot \
  --credentials my-aws \
  --input-bucket training-data \
  --output-bucket results \
  -- python train.py --lr 0.001
Every decorator call runs your latest commit via GitHub sync — no image rebuild.

How it works

Docker in. Results out.

Six steps. No Kubernetes, no YAML pyramid, no managed-service markup.

  1. 01

    Install

    CLI or Python SDK.

  2. 02

    Connect

    Credentials stay on your machine.

  3. 03

    Submit

    Pick a GPU, hand us a Docker image.

  4. 04

    Run

    Stream logs, SSH in, monitor live.

  5. 05

    Preempted?

    Checkpoints restore, job restarts on a new VM.

  6. 06

    Done

    Results synced, VMs cleaned up.

Ready to run AI workloads on your own accounts?

Five minutes from install to running hundreds of experiments.

Get Started →Read the Docs