BYOC and managed runners under one governance model#
Connected Compute is the workspace primitive for running governed agent
jobs on either BYOC sources you operate or LumenFlow-managed
sources. A source can be a laptop, CI runner, Docker host, Kubernetes
worker, or the first managed pool registered as lumenflow_managed.
Both paths use the same control-plane contract:
| Layer | What is shared |
|---|---|
| Claim | POST /api/v1/runtime/claim assigns eligible runtime work |
| Lease | dispatch_lease records bounded execution and retry state |
| Evidence | Receipts, approvals, and replay links stay workspace-scoped |
| Routing | Workspace policy chooses byoc_only, byoc_first, managed_first, or managed_only |
| Budget | Per-WU and per-tier limits refuse before silent fallback |
What is live#
- connected-runtime enrollment and health posture
- the runtime claim path and assignment lifecycle
- compute source read models for operator dashboards
- workspace routing policy UI and per-job "assigned to X, why" detail
- the first managed-worker registration path for
lumenflow_managed - a runner-side compute-class classification (the default is
cpu-small), recorded on each assignment run
What is still planned#
Managed compute billing is landing in slices. The next pieces are
compute_usage_events ingestion from managed assignment completion,
credit wallet debits, Stripe meter emission, and customer checkout for
managed compute credits.
Until those pieces are complete, do not describe managed compute as a fully billable marketplace. Describe it as the governed routing and execution substrate with metering and checkout in progress.
Private-network boundary#
Connected Compute is not a raw tunnel. Private-network access composes with the federation runtime and its admission gates. A BYOC source can execute approved work, but it does not silently become a private-network proxy.