Live Runner + Go SDK Release

Roadmap state: Now

Opportunity Status: Completed

Owned By: Josh Allman, Rick Staa (validation and merge) I

Funding Mechanism: Livepeer Inc + Network Engineering funding SPE

Primary artefact: doc/live-runner.md in go-livepeer

1. Purpose

Before this work, adding a compute capability to the network meant one of two things: writing Livepeer-specific code into go-livepeer and the AI runner, which only the core team could do, or standing up a full gateway in front of the SDK. Roughly 170 capabilities were live and all were sourced centrally, with each new one adding to a core-team queue.

Live Runner lets an orchestrator put an ordinary HTTP service behind the network. The service is registered, health-checked, discoverable, reverse-proxied and priced, and needs no Livepeer-specific code for basic passthrough. The paired SDK covers the client side: discover an orchestrator, reserve a session, call it, settle payment, no gateway required.

This is Milestone 1 of the Livepeer Agent Framework. The other four milestones (capability onboarding, real-traffic validation, quality-of-service routing, billing and metering) all build on the same plumbing, so shipping it as one tagged release stopped them being built on branches that would keep moving. It also sat on the critical path for the Agent's closed beta and the orchestrator onboarding cohort.

2. Outcome

Overview:

One referenceable release of Live Runner and the paired SDK, consolidated from six to seven months of prototype work across the BYOC, stream diffusion and Scope PR stack, with operator-facing reference documentation. An operator can attach an existing HTTP, SSE, WebSocket or trickle application as a container alongside a running orchestrator and have it discovered, priced onchain and serving paid sessions. Complexity moves out of go-livepeer and ai-runner, and downstream milestones build against a fixed surface.

Key Metrics To Measure The Outcome Against:

1. Tagged release of Live Runner and the Go SDK merged to go-livepeer master, with reference documentation published. Met (Live Runner 2026-07-24, paired SDK 2026-07-27)

2. Both registration models (static and dynamic) and both session modes (persistent and single-shot) available and documented. Met

3. An off-the-shelf HTTP container can go behind the network with no Livepeer-specific application code for basic passthrough. Met

4. Onchain discovery and payment working end to end, with USD-denominated pricing converted and settled through probabilistic micropayments and usage tracked per session. Met (LiveRunner 0.9.0 tracks billable seconds; fixed-billing collector support followed)

5. Downstream milestones build on the released surface rather than on branches. Met; zero-code capability onboarding was in progress against it within the same week

3. Requirements

Written as the opportunity would have been issued, with delivery status recorded against each item.

Must Have

• A single tagged release consolidating the prototype stack (BYOC, stream diffusion, Scope) into one referenceable surface. Delivered

• An orchestrator-side registry tracking each runner's application, metadata, mode, readiness, capacity, price and active sessions, advertising only runners it currently considers ready. Delivered

• A reverse proxy preserving request method, query string, headers, body, streaming responses and WebSocket upgrade, without exposing the runner's private address to clients. Delivered

• Both registration models: static, where the operator owns configuration and the orchestrator polls a health URL, and dynamic, where the runner registers itself and holds readiness open with heartbeats. Delivered

• Both session modes: persistent for realtime and stateful work, single-shot for stateless request/response, with capacity counted in sessions rather than connections. Delivered

• Onchain pricing and payment: USD-denominated registration price across per-hour, per-720p and fixed units, probabilistic micropayment settlement, and session release on payment failure. Delivered

• A paired SDK so a client can discover, reserve, call and pay without standing up a full gateway. Delivered (Go and Python)

• Reference documentation covering the static configuration schema, CLI flags, dynamic runner protocol and full HTTP API. Delivered (doc/live-runner.md)

Should Have

• Container-first deployment attachable to an existing orchestrator through ordinary tooling (Kubernetes, Docker, Ansible). Delivered

• Session-scoped trickle channels and opaque session-scoped proxy URLs, so a runner can expose a secondary service without leaking the session identifier that would let a client manipulate the session. Delivered

• Aggregated discovery through the remote signer, giving clients and gateways a single price-filtered endpoint across orchestrators. Delivered

• Session reconciliation after a runner restart or network partition, so a recovering runner can stop stale local work against the orchestrator's authoritative session list. Delivered

• Stable, human-readable public routes via label routing instead of generated runner IDs. Delivered

Nice To Have

• Opaque, application-controlled metadata advertised verbatim through discovery, bounded and explicitly non-secret. Delivered (UTF-8, 1,024 bytes)

• Configurable public proxy URL shapes, including per-proxy subdomains as well as path templates. Delivered

• Live upsert of static runner configuration without restarting the node, validated atomically per batch. Delivered

• A community-facing explainer covering how Live Runner connects to the agentic stack. Outstanding (Rick Staa with Josh, scheduled for a subsequent watercooler)