Documentation

One command sets up the whole service host, the machine that runs the service: vibemon (the microVM runtime), its network and units, the auth broker and gateway, the omp-cloud service, the omp plugin…

Let a coding agent set omp-cloud up for you.

Other machines use the cloud without the owner token: each one pairs once and holds its own device token, which you can revoke.

Every /cloud command the plugin adds to omp, where finished turns and questions go, and the cards they land as.

The local model can delegate to the cloud and manage the threads it started, through one tool with an op field (named cloud, or cloud_agent when another tool already has that name).

A thread your session launched, messaged or watches is an agent of your omp, and while a turn runs on it, that turn is a background job, both named after the thread (PaneZoomShortcut).

A thread that has been idle for lifecycle.archiveAfterDays days (a setting, default 7; 0 never archives, fractions work; set it through /api/v1/settings or the dashboard) is archived by a sweep that…

omp-cloud has two kinds of configuration: omp-cloud's own files on each machine you run omp on, and service.json on the server.

The service updates the way Tern does: it checks the release feed in the background, downloads and verifies a newer release, and installs it when you click once.

How to back up and restore the service's data, and the units that keep it running across a reboot.

What the service, the VMs and your devices can reach, what runs as root, and what crosses between your omp and a cloud agent.

Scope: one owner, one vibemon node.

The HTTP API local omp uses to hand work to the cloud: upload a repository and conversation, follow the thread, send follow-up messages and fetch the result branch.

How the repository is laid out, and the commands that build, test and check it.

Release notes of omp-cloud, newest first.