Show HN: Octomind Cloud – Persistent cloud compute for AI agents Octomind Cloud launched in beta as a persistent cloud compute platform for AI agents, solving three core problems: agent sessions lost when laptops close, API key sprawl across multiple providers, and unpredictable AI billing. The platform combines a hub with curated models and machines under one subscription, wallet, and key, with published per-token prices and fair-use limits per account. Today Octomind Cloud goes live in beta. Before I tell you what it is, let me tell you the three problems that made us build it — because odds are you have at least two of them right now. Your agent lives and dies with your laptop. You kick off a long refactor, the agent is forty minutes into it, and then you need to close the lid, catch a train, or your Wi-Fi hiccups. The session is gone, the context is gone, and the tokens you paid for produced work you'll never see. Agents are long-running processes; laptops are not long-running machines. Your API keys live in five dashboards. OpenRouter for the cheap models, Anthropic for the good ones, OpenAI because some tool demands it, Voyage for embeddings, and a .env file that's one git add -A away from being public. Every provider has its own billing page, its own rate limits, its own "add $5 minimum" — and no single view of what your agent actually spends. Your AI bill is a mood, not a number. Seat-priced tools give you rate-limit roulette /blog/claude-rate-limits — an opaque allowance that resets on someone else's schedule. Usage-priced tools give you the opposite fear: nothing stops a runaway agent from burning $80 overnight. Neither shows you a per-token price or lets you watch the meter. Octomind Cloud is our answer to all three. It's two things that share one subscription, one wallet, and one key: the hub models and machines compute . This post is the map of everything that's live today — each section deserves its own deep dive, and those are coming. But this one piece should tell you exactly what you're getting, economics included, because pricing you can't reason about is a bug, not a business model. The hub: log in once, every model works The hub /hub is an OpenAI-compatible gateway in front of a curated model roster — one key, every model works, in the panel, in the CLI, in any tool that speaks the OpenAI API: curl https://hub.octomind.run/v1/chat/completions \ -H "Authorization: Bearer $OCTOMIND KEY" \ -d '{"model": "deepseek-v4-flash", "messages": {"role": "user", "content": "hi"} }' If you're using the CLI you don't have to handle that key at all. As of 0.38.0 /blog/octomind-0-38-0-release , octomind login shows you a short code, opens the panel where you're already signed in, and writes the key to disk itself: bash $ octomind login ╭ login · octomind account │ code TX8T-UC7U │ url https://octomind.run/app/login/cli │ │ Confirm the code in your browser to finish signing in. │ waiting… It's the standard device flow — the same one gh auth login uses — so no password is ever typed into a terminal, each machine gets its own revocable key, and the /usage command tells you what you've spent against your caps without opening the panel. No provider accounts. No key sprawl. And the part I care most about: published prices, and metering that matches the table exactly. The roster is deliberately curated, not a 400-model dropdown — twenty-one models that earn their place. The open shelf DeepSeek V4 Flash and Pro, Qwen3.7 Plus and Max, Kimi 2.6 and 2.7 Code, MiniMax M3, GLM-5.2, Gemma 4 is included in every paid plan and draws from your plan caps. The premium shelf bills per token from prepaid credits, and it's the real thing: Claude Fable 5, Opus 4.8 and Sonnet 5; the whole GPT-5.6 family Sol, Terra, Luna with GPT-5.5, 5.5 Pro and the fast little 5.4 mini and nano; Gemini 3.5 Flash and 3.1 Pro. You see every price before you pick. And there's a free model with a daily allowance that keeps working even when everything else is exhausted, because an agent that goes completely dark the moment you hit a cap is worse than a slow one. Fair use is per account , not per key: Free runs one model call at a time, Pro two in parallel, Max five, Team fifteen pooled. Mint a thousand keys and the budget doesn't move — and past it, requests queue briefly instead of failing. It's the anti-abuse rule that doubles as a noisy-neighbor guarantee: nobody's runaway script makes your completion wait. Under the hood this is octohub https://github.com/Muvon/octohub — open source, Rust, one static binary. The hosted hub is the same code with the keys problem solved. Want to run it yourself with your own provider keys? That's not a loophole — it's the point of publishing it. Machines: a dev box that exists whether or not your laptop does A machine is a persistent Linux container in our cloud with the whole agent toolchain baked in — your files, your repos, your indexes, persisted on its own disk. It's got: octomind https://github.com/Muvon/octomind the agent , octocode code indexing + semantic search , octobrain memory , a web terminal, git, Docker more on that in a minute , and — on the default image — Node, bun, a headless browser, ffmpeg and image tools. You create one in the panel, it's ready in under a minute, and it's yours. The billing model is the part I want to defend in detail, because it's where most clouds get either opaque or hostile. A machine is always in one of three states, and the state decides what you pay: | State | When | Small 1 vCPU / 2 GB | |---|---|---| Active | Executing — tools, code, indexing, embeddings | $0.05/hr | Idle-warm | Session alive but waiting including LLM-wait | $0.01/hr | Suspended | Nothing running — auto-suspends when idle | ~$0 disk only | Archived | Suspended 3+ days — parked in cold storage | ~$0 extra disk $0.04/GB-mo | Per-second metering, automatic transitions, you configure nothing. The consequence that matters: while your agent waits on the model — which is most of an agent's wall-clock life — you pay a fifth of the active rate. A five-minute session costs about half a cent, plus $0.001 per session start. 10 GB of working disk comes free with every machine, and sizes scale linearly — Medium 2 vCPU/4 GB is $0.10/hr, Large 4 vCPU/8 GB is $0.20/hr. Twice the machine, exactly twice the price; upgrading is never punished. Disk scales with the box the same way — reserve up to 50 GB on a Small, 80 on a Medium, 160 on a Large at $0.10/GB-month, and if you genuinely need more, stretch to double the bundle with the overflow at 2× instead of being told no. Park a machine long enough — three days suspended — and it quietly moves to cold archive storage : the machine keeps its identity, its files and its place in your account, host resources are freed, and the next start restores it onto any available host in a few minutes instead of seconds. While archived, extra disk above the free 10 GB bills a flat $0.04/GB-month — under every mainstream snapshot price, with no restore fee and no minimum retention — and a default-disk machine parks at exactly $0 for as long as you're subscribed. Every machine runs under the sysbox runtime in its own user namespace — root inside the machine is nobody on the host. The agent runs as a non-root user on a disk that physically cannot grow past its quota. Secrets go in as write-only encrypted variables: the panel can never show a value back, only a masked hint. Yes, Docker runs inside — every machine, every plan Every machine comes up with a real Docker Engine inside, free plan included — nothing to tick, nothing to configure: docker build , compose stacks, testcontainers, all of it, with no --privileged anywhere. The sysbox runtime gives each machine a properly isolated environment where an ordinary dockerd can live without ever seeing the host. The part we sweated hardest is the accounting, because nested Docker is where clouds usually leak: every byte the inner engine writes — images, layers, volumes — lands on the machine's own capped working disk. df inside the machine, the disk bar in the panel, and the bill all report the same number. Fill the disk and a pull fails with an honest disk-full error, not a surprise invoice; free some space and carry on. Your images and volumes persist across suspend like everything else on the machine. Sessions that survive you This is my favorite thing we built, and it's invisible when it works. Start a turn, then close the tab. Navigate away. Lose your connection in a tunnel. The turn keeps running on the machine , and the relay keeps recording every step — tool calls, output, cost — until it finishes. Open the session from your phone twenty minutes later and the full transcript is there, including everything that happened while nobody was watching. We tested this by killing browsers mid-turn until we couldn't lose a byte. Nothing was lost. That screenshot is a real session from while I wrote this post: the agent scaffolded a Bun server, started it, curled /health , and cleaned up after itself. Total cost in the corner: $0.008 — and I navigated away twice in the middle to take the other screenshots in this article. Nothing was lost. The same session is reachable from the panel, from a plain web terminal, through the developer API https://octomind.run/app/docs api.octomind.run/api/v1 — create sessions, send messages, tail output over SSE, all scriptable from CI , and through Telegram: one tap connects our bot or bring your own, if you'd rather own the token , and your machine answers you in chat — real formatting, tables included, not a wall of raw markdown. The agent stops being a browser tab and becomes a thing you own that happens to have several doors. The developer API and the Telegram workflow each deserve a full post of their own — they're coming; this is the overview. Sessions also remember how they think. Every session starts on your default model and role, and both are switchable per session: pick from the model dropdown in the session header, or type /model gpt-5.6-luna in the chat — the same command works from Telegram and through the API, and the choice persists with the session. Take a premium model for the gnarly refactor, drop back to a cheap one for the cleanup; /role , /effort , /info , /done , /plan , /schedule and /agents ride the same rails from every surface. One detail we're proud of: switching to a model your plan can't call is rejected at switch time with a clear message — not discovered as a cryptic 403 three messages later. And the agent on the machine is the same octomind you'd run locally — same config format, same sub-agent delegation, same tools. The panel's Config page holds your octomind / octocode / octobrain TOML and bakes it into every machine at creation; model routing and API keys are injected by the cloud, so a config that just says octohub:auto works everywhere without a single key in a dotfile — the hub picks the real model per call purpose your sessions, the supervisor's checks, compression each get their own , and you retune any of them from the Models page without touching config. The machine tells the agent where it is There's a small file with an outsized effect on every machine: AGENTS.md , following the AGENTS.md standard https://agents.md , loaded into every session as opening context. It's how the agent knows the things no model can guess: that /home/octo survives restarts and /tmp doesn't, that the machine auto-suspends and a schedule beats a process left sleeping in the foreground, that you might be reading its answer on a phone with no terminal in sight — so deliverables belong in files it names, not in scrollback you'll never see. New machines come seeded with our baseline, and it's yours to change at two levels. Edit your account's baseline under Configs → instructions and every machine you create afterwards starts from your version. Or open a machine's Instructions tab and edit the live file — the machine owns its copy from first boot, and your edits survive every restart a shell works too; it's a real file in the home directory . And because it's the standard rather than something we invented, a repo that carries its own AGENTS.md just works: the agent follows the repo's instructions while working inside it, and the machine's everywhere else. Embeddings, priced honestly Embeddings are the highest-volume model call in the whole system — octocode embeds every chunk of every repo it indexes, and re-embeds on change. Which makes them exactly the place where a cloud can quietly do something user-hostile: route everything through a paid API and margin the flood, or double-bill you for compute and tokens on the same operation. We shipped two lanes instead, and the picker states the deal in plain text: Local the default : small open embedding models fastembed run on your machine's own CPU. You pay compute — the same $0.05/hr the machine already costs while active — and not a token cent. Indexing a mid-size repo is minutes of CPU, so it's pennies, and the index lands in your account's shared storage where every machine you own reuses it . Index once, search everywhere. Hub optional, paid plans : the current embedding generations — the Voyage 4 series, Jina's v5 line, OpenAI's text-embedding-3 — through the same hub key, from $0.02 per million tokens at published list prices, the same table the meter bills from. You'd pick this for quality voyage-code-3 is genuinely better at code retrieval than anything that fits in 2 GB of RAM or to keep a Small machine's CPU free while indexing something huge. Free plan gets the local lane only — hub embeddings proxy paid provider APIs, so they're a paid-plan entitlement, enforced at the key level, not hidden in fine print. Both lanes bill into the same wallet under the same caps as everything else. No new billing concept, no separate embeddings invoice. One wallet, caps you can actually watch Everything above — tokens, embeddings, vCPU-seconds, RAM, disk, storage, network — converts to dollars at list price and lands in one wallet with one set of rolling caps you can watch move: The plans, plainly: - Free — $0. $0.15/day of usage on a capable model, the hub + CLI immediately, and 1 Tiny machine 0.5 vCPU / 1 GB, a fixed 5 GB disk once you have an invite, 2 GB shared storage. The cap is hard — that's what keeps the free tier free. Free machines auto-suspend when idle and get reclaimed after about a week of inactivity — always after a heads-up email, and never while anything is running; touch it and the clock resets, or upgrade for a machine that stays put. - Pro — $20/mo $10 your first month . Caps of $20/4h · $60/week · $120/month across everything , 3 machine slots 1 slot = 1 vCPU — mix Tiny ½, Small 1, Medium 2 any way that fits , 10 GB shared storage. - Max — $100/mo. Caps ×5, 12 machine slots with Large 4 vCPU / 8 GB unlocked — up to 3 Large at once — 30 GB shared storage. - Team — $500/mo. Pooled caps, unlimited members, 60 machine slots, per-member limits so one intern can't drain the pool. Three design decisions worth calling out. First, caps are total-spend caps, not token caps — compute counts too, so the number in the sidebar is your actual exposure, not one meter of several. Second, credits are the overflow : if you hit a Pro cap mid-task with prepaid credits in the wallet, the session keeps flowing on credits instead of dying at the worst possible moment. The cap protects your budget; it doesn't punish your momentum. A hard stop happens only at zero balance and on the free tier, by design . Third, machines reserve their runway : a running machine pre-claims what it will burn until each cap window resets — the usage bars draw it as a hatched "reserved" segment next to real spend — so a burst of token calls can never starve a machine mid-task, and a machine your remaining budget can't carry is refused up front instead of dying halfway through. Every price in this post is on the pricing page /pricing and in the panel's Models table, and the meter bills from the same numbers. If you ever catch the meter and the table disagreeing, that's a bug and I want the report. The whole stack is open source This launch is a hosted product built from pieces you can already run: - octomind https://github.com/Muvon/octomind — the agent itself, the same binary in every machine - octocode https://github.com/Muvon/octocode — code indexing + semantic search /blog/understand-large-codebase-octocode - octobrain https://github.com/Muvon/octobrain — persistent memory - octohub https://github.com/Muvon/octohub — the model gateway behind the hub The cloud is the convenience layer: the machines, the wallet, the one key, the sessions that outlive your laptop. If you'd rather self-host every piece with your own provider keys, the doors are all open and the docs assume you might. We think enough people will prefer the version where somebody else does the plumbing. What beta means, and what's next Beta means cloud machines are invite-only while we scale the fleet. We're bootstrapped — no investors — so we buy hardware as people subscribe. We'd rather hand out machines at the rate we can actually serve them than watch a signup rush turn into "at max capacity" for everyone. Three ways in: subscribe and you're in immediately , redeem an invite from someone already here, or use the free tier for a week and earn invites of your own. The hub and the CLI are open to everyone right now, no invite needed. That's the part that costs us almost nothing to scale, and it's the whole product minus the machine: log in, take a key, and run the open-source agent on your own laptop against every model in the roster. The hub, your keys, billing and caps are fully live and not going anywhere. Nothing you build on a paid machine is throwaway: disks, shared storage and sessions persist through the beta. On the free tier, a machine and its shared storage are reclaimed after about a week of inactivity — always after a warning email, never while something's running — so a paid plan is the one that keeps everything until you delete it yourself. This post is the wide-angle shot. Over the coming weeks we'll go deep on each piece separately: - The developer API — driving machines and sessions from CI and scripts, with SSE streaming - Docker inside machines — how sysbox and a capped disk let you run compose with no --privileged and no ghost storage - Custom images — bring your own Dockerfile on top of our base, verified and billed transparently - Teams in practice — pooled caps, per-member limits, shared machines without shared footguns - The embeddings economics — why two lanes, and what indexing a monorepo actually costs - Telegram as an agent surface — a machine in your pocket, honestly useful or gimmick? - Self-hosting octohub — the same gateway with your own provider keys If one of those is the thing blocking you today, tell us and we'll bump it up the queue. Try it Go to octomind.run/app https://octomind.run/app — login is an email code, no card, no signup step. Or start from the terminal and never touch the panel: install the open-source CLI https://github.com/Muvon/octomind , run octomind login , confirm the code in your browser, and you're running the same agent locally against the same models, today. For a cloud machine , you need an invite while we scale — subscribe and it unlocks immediately Pro is $10 for the first month , or redeem a code if someone passed you one. Use the free tier properly for a week and you'll earn invites to hand out yourself. From "New machine" to a working agent with a browser and a terminal is about a minute. We've been running our own development on it for weeks — this article's screenshots are my actual account, spending real cents. That's the bar we wanted before calling it a launch: not a demo, a place where your agent works while you don't.