omp/cloud
GitHub
Reference

Changelog

Release notes of omp-cloud, newest first. mise run release -- <version> moves ## Unreleased into a dated section, and the release workflow publishes that section as the GitHub release's notes. Write each entry for someone who runs the service.

Unreleased#

0.5.3 (2026-10-22)#

  • A login that never took effect. Running a second omp-cloud serve on the service host (for example omp-cloud with no command, which serves by default) replaced the running service's own gateway client before it failed on the taken port. From then on the service could not read which models the gateway serves, so after a successful omp-cloud login the cloud still said it could not run the provider until the service was restarted. A second serve now claims the API address first and stops at once with … is already in use: the omp-cloud service is probably already running, changing nothing. While it starts, the API answers 503 the service is starting.
  • The service recovers its gateway client by itself. When the gateway stops accepting the service's client, the service issues a new one and reads the model list again within seconds, keeping the last list meanwhile. Before, it kept the rejected client until a restart.
  • Logging in from a paired device. A paired device can't log the cloud in to a provider (that takes the owner token, which stays on the server), but the plugin still told it to run /cloud login, which then failed with only the owner token can do this. On a paired device, the handoff refusal, /cloud login, the hub, /cloud status and the cloud tool now name the server and the command that works there: omp-cloud login <provider> on the server, for example over ssh -t. /cloud login on a paired device stops before contacting the service.

0.5.2 (2026-10-22)#

  • Website. The documentation is published at https://omp-cloud.techdufus.com with a landing page, in the dashboard's look with a light and a dark theme and search over every page. The pages are docs/*.md, CHANGELOG.md and sections of README.md themselves, rebuilt on every push to main; mise run site:build builds it into site/dist/ and fails on a link to a page or heading that does not exist, and mise run site:dev previews it locally.
  • Shorter install line. curl -fsSL https://omp-cloud.techdufus.com/install.sh | sh installs the server; the website serves the same install.sh from main as raw.githubusercontent.com, which keeps working.
  • Login link stays on screen. /cloud login posts the provider's sign-in link (and a device code) as a card in the transcript, with a link to click and the full URL to copy; in Tern it was a notification that vanished after two seconds. In omp's interactive UI it asks you to wait while the agent is working.

0.5.1 (2026-10-21)#

  • Cloud agents. /cloud <task> hands your repository (uncommitted changes included) and the conversation to an omp agent in its own KVM microVM on your hardware, running the same omp you run. It works on its own branch and asks you questions when it needs to. After 10 minutes idle (runner.idleTimeoutSeconds) its VM pauses with its processes intact, and the next message resumes it. A lost VM is replaced from the last result and conversation. /cloud pull <id> fetches omp-cloud/<id> and saves the cloud conversation as a local omp session, and /cloud resume <id> continues it locally.
  • The /cloud plugin. The command set is /cloud (the hub), [new] <task>, list, show, watch, unwatch, send, answer, stop, pull, resume, delete, login, update, dashboard, pair, connect, devices, disconnect, status and help. A thread is named by its id, a unique suffix or prefix, a word of its name, or the job id omp shows for it. A message that starts with / runs in the cloud agent's own omp (/usage, /compact, extension commands, and so on); see docs/commands.md.
  • The cloud tool. omp's model drives cloud agents through one tool with 14 ops (delegate, list, status, read, events, diff, files, send, answer, stop, wait, pull, delete, info). delegate starts one thread or up to 8 from one snapshot, and a repeated ref replays the first thread instead of creating another. Work that needs no repository runs as a scratch thread in an empty repository. Errors carry a code and say whether the outcome is known; see docs/cloud-tool.md.
  • Cloud agents are omp jobs and agents. A running cloud turn shows in omp's Subagents strip, the jobs pill, /jobs, Tern's Background jobs panel and wait, and as proc://<id>, with step dots, per-turn bars, a context meter, cost, tokens and a live output tail. agent://<id> reads the latest reply and history://<id> the conversation. For a thread the model started, the finished turn arrives as omp's own async-result, and cancelling the job in omp stops the cloud turn. omp stats counts the cloud's spend with yours; see docs/jobs.md.
  • Messaging and drill-in. write agent://<id> messages a cloud agent with omp's own semantics and answers with a receipt: injected into the running turn at its next step, woken for an idle agent, revived for an archived one. A message carries an id, so a retry is safe. A cloud agent writes back to agent://Parent, and the message reaches your omp as an ordinary incoming message.
  • Live events and child jobs. A running turn writes usage, tool_start and tool_end events before it ends, and the background jobs and subagents a cloud agent starts in its VM write child_start, child_progress and child_end events. They appear under the agent's job in omp's jobs panel and /jobs. A child still open when the VM is paused, lost or released ends cancelled with the reason.
  • Questions and approvals. An agent's ask questions come back as cards that list their options (a click on one answers it in Tern) and open omp's own ask dialog for a thread you started. Finished turns and questions go to a cloud inbox (the footer count and the /cloud hub) and to the terminal's attention tray, so they cost the model nothing; deliver: transcript in ~/.config/omp-cloud/config.yml posts cards instead. Tool approvals, prompt rules and the push question always go to you, and the cloud tool refuses to answer them.
  • Native in Tern. Cards, the /cloud hub and the cloud tool's results draw as Tern's own nodes; in a terminal without Tern's protocol they are framed with omp's own output block and status line.
  • Git and push policy. The service fetches bases, composes bundles and pushes results from its own git cache; git credentials and the push never go into a VM, which holds only its gateway client token. git.push is never (default), ask or auto, and it never forces and never writes a protected branch (git.protected, default main, master, develop, release/*) or the remote's default branch. For a remote whose host the service holds a credential for, the handoff ships only what the remote lacks.
  • Agent policy and spend caps. Bash rules (policy.bash.patterns), per-tool approvals, policy.fetch, policy.webSearch, policy.browser, an egress allow-list (policy.egress), allowed models and spend caps per turn, thread and day (policy.spend.*, in USD). A thread can tighten the service's policy and never loosen it.
  • Archive. A thread nobody touches for lifecycle.archiveAfterDays (default 7, 0 never) has its VM released; its conversation and work are kept, and the next message restores it. Orphaned sandboxes and gateway clients are swept.
  • The dashboard. /cloud dashboard prints a one-time sign-in link to a loopback web page styled after omp's /stats, in a light and a dark theme: Overview, Threads by repository (with an Archived filter), a thread page with context use, cost and tokens per turn, Spend, VMs, Devices, Logins and Settings. Run-time settings are typed, apply without a restart, are audited and can be exported as YAML.
  • Pairing. Other machines pair once, from a code (/cloud pair, then /cloud connect) or over ssh (/cloud connect user@host), and get their own revocable device token over a TLS connection pinned to the service host's certificate. The owner token is refused on the remote listener, which accepts private source addresses by default. /cloud devices revoke ends a device immediately.
  • One-command install. curl -fsSL https://raw.githubusercontent.com/TechDufus/omp-cloud/main/install.sh | sh downloads the release binary, checks its sha256 and runs omp-cloud setup. Setup prints a plan and asks first, uses sudo once for the root work, and then sets up vibemon (pinned per release), the persistent system and user units (they survive a reboot), the omp-cloud vibemon team (32 concurrent sandboxes by default), the service config and TLS identity, the plugin and the model login. It is idempotent and never changes firewall rules. It needs a Linux x86_64 host with /dev/kvm, systemd and omp 18.12.3 or newer.
  • omp-cloud commands. One binary with setup, doctor, login, uninstall, serve (the default), ssh-pair, update, install, backup and version. doctor checks the machine and the whole stack, including that your omp loads the plugin, prints the fix beside each failure and exits 1 on a failure. login [<provider>] logs the service in to a model provider and prints the URL in full. uninstall [--purge] removes what setup installed and keeps your backups. A daily timer runs backup: one archive of the database, blobs and git cache.
  • Updates. The service checks the release feed hourly (update.mode: off, notify by default, auto), downloads and verifies a newer release, and installs it on one click in the dashboard, with /cloud update or with omp-cloud update apply. The update waits up to 60 s for the new version to answer /api/v1/health, rolls back if it does not, and restores the pre-update backup when the release changed the database schema. auto installs by itself only when no thread has been starting, working or waiting for 10 minutes and the release needs the same vibemon and database schema. omp shows update ready in the cloud footer and the hub, and the plugin is refreshed with the update; see docs/updating.md.
  • Service API 3. GET /api/v1/whoami reports the service version, api: 3, the capabilities (including threads.irc, events.live and events.children), limits, spend and models, so a client checks for a feature before it uses it; a plugin that needs one the service lacks says so (version_skew). The contract is in docs/api.md.
  • Releases and license. Each tagged version is published on GitHub Releases as one omp-cloud executable per architecture (linux x86_64 and arm64; install.sh and setup accept only x86_64) with a release.json manifest, sha256 sidecars and a THIRD-PARTY-NOTICES.txt that lists every bundled package with its license; omp-cloud version prints the version and build id. omp-cloud is MIT-licensed (LICENSE; the plugin carries its own copy in plugin/LICENSE).
  • Known limitations. See docs/architecture.md, "Known limitations".