← All posts

Preloop 1.0.0: a compatibility promise, your laptop as a runner, and reviews that must land

Dimitris Moraitis · ·6 min read
  • release
  • compatibility
  • personal runners
  • security
  • single sign-on
  • flows
  • cost

A 1.0 is a promise more than a feature list. Until now, anything in Preloop could change between minor releases, and if you scripted against the API or ran the Helm chart you carried that risk. From 1.0.0 on, you don't.

What 1.0.0 means

The compatibility policy names the public surfaces: the REST API under /api/v1, the MCP endpoint, the model gateway and OAuth paths, CLI commands and flags, webhook payloads, the runtime plugin protocol, Helm values, flow result formats and database migrations. Within a minor line, changes to them are additive only. A removal is announced as a deprecation at least one minor release ahead and ships no earlier than two minor releases after that. Migrations stay forward-only, so a downgrade means restoring a backup.

We tracked the release against a readiness checklist. These items are closed:

  • The compatibility policy and the API versioning decision are published.
  • The MCP server speaks protocol 2026-07-28 on the same /mcp URL, on MCP SDK 2.3 and FastMCP 4, and keeps clients from 2024-11-05 onward working.
  • Responses carry a server-version diagnostic header, and clients build their REST paths from one prefix.
  • CLI logins can be revoked.
  • API key scopes are enforced across REST and MCP: discovery and reads need mcp:read, tool calls need mcp:write.
  • Credentials stored in the database are encrypted at rest, and a test fails if a new column that looks like a secret has no entry in the published audit.
  • Upgrades from the last 0.17 release are covered by a reproducible acceptance harness for Docker Compose and the Helm chart, which checks data, logins, existing tokens and agents after the upgrade. It passed from v0.17.1 to main on both.

One item stays open until the release: the SBOM and audit job passing on the 1.0.0 tag itself. It passes on main, and it can only pass on the tag once the tag exists.

Users and teams are open source

Preloop OSS now includes users, invitations and teams. Every active member can manage the account, and accounts stay isolated from each other. Roles, owner protection and seat policies remain in Preloop Cloud and Preloop Enterprise. Removing a member now revokes everything they held in that account in one transaction: sessions, tokens, CLI and MCP grants, team memberships, personal keys and the runners they registered.

Cloud and Enterprise add single sign-on: OIDC and SAML connections, verified domains, group to team mapping, enforcement that can only be switched on after a fresh test sign-in, and SCIM provisioning with tokens bound to one connection.

Your machine as a runner

In 0.17.0 personal runners arrived. In 1.0.0 they are something we are comfortable recommending. There is a guide for using your own laptop as a runner, linked from the preloop login prompt, that covers what gets installed, what is reported and what is not, and how to undo all of it. Flows can run there on your own agent CLI and seat, with your approval for each run by default.

The runner now reports sleep and wake. On Linux the console shows a sleeping laptop as asleep and routing skips it; on every system the runner reconnects as soon as it wakes. You can share a runner with a colleague with an explicit grant, and choose to approve each session they start. Codex and Claude Code runs on a private runner are metered through the gateway per execution, and a run that produced model output without going through the gateway fails instead of passing quietly.

Flows you can trust to finish honestly

Two changes here came straight from running our own software factory on Preloop.

First, a pull request review can be required to land. With the review delivery check on, a reviewer run succeeds only when the code host accepted its review on the right pull request and commit. The agent saying it posted a review is not enough.

Second, a run whose model calls keep failing the same way is stopped by the gateway, before it spends money on another identical attempt.

Approval rules also reach unattended runs now. When a command on a runner matches a rule that needs approval, the run parks on an approval request and resumes with exactly that command allowed once. Hosted Codex runs carry the same policy hook, as a user that cannot remove it.

Seeing the work

The Delivery Report is a new flow preset and console page: it reads the week's pull requests, CI and tracker activity, checks issues against their own acceptance criteria, and proposes follow-ups, including reopening an issue whose measured criterion was missed.

The session page reads like the terminal now, one row per tool call with diffs for edits, with search and copy as text. Talk streams the reply as it is written and sends each line to the session you typed it in. On the cost side, the Spend page now has Work items and Issues tabs. Cost per work item groups each issue with the pull requests that close it and splits a run's spend across everything it touched, so nothing is counted twice. Cost per issue adds cycle time for each tracker issue. The Spend page paints each card as its data arrives.

The Spend page in the Preloop console, dark theme, with the Work items tab open: $2.03 estimated across four work items in a payments repository, each grouping one issue with the pull request that closes it, with session counts, tokens and estimated cost per item, next to the Budget health card with its spend and projection chart.

Upgrading

Back up the database first; migrations are forward-only. Then check these changes against your setup:

  • Invitation responses no longer include the acceptance token. Deliver links by email and use the resend endpoint.
  • Flows have no default token, turn or cost ceiling. If you relied on the old 2,000,000-token default, set agent_config.limits on the flow or the PRELOOP_DEFAULT_MAX_* variables on the instance.
  • With roles enabled, a flow's runner_pool no longer reaches another member's personal runner without a grant.
  • The review delivery check is a per-flow opt-in. Turn it on for an existing reviewer flow once the API build that writes receipts is serving.
  • Stored gateway calls keep only what each call added. An hourly task compacts older rows; flow log compaction is opt-in.
  • Self-hosted Enterprise installs enable single sign-on with the sso.* Helm values.

The full list is in the changelog.

If you run Preloop and something in this promise does not hold for you, open an issue. That is what the promise is for.