Developer Landscape

Five developer mental models for the Livepeer network: AI inference, video platform, compute primitives, live-video-first, and protocol. Each maps to a network-direct surface.

---

Livepeer is a decentralised compute network for video and AI. Independent orchestrator nodes run GPU workloads against the Livepeer protocol on Arbitrum One. Developers reach that network through a layered set of surfaces: community gateways for free experimentation, self-hosted gateways for production control, BYOC containers for custom workloads, and the trickle protocol for transport. Hosted Solutions like Studio and Daydream sit above these surfaces; the Developers tab covers everything below.

Five developer mental models cover the surfaces you’ll actually build against. Each one maps to a quickstart and a deeper guide.

AI Inference Mental Model

You’re treating Livepeer as an OpenAI-shaped inference API. You want an endpoint, a key (or a free off-chain gateway), and a model menu. Text-to-image, image-to-video, audio-to-text, LLM completions, and seven more native pipelines are reachable through one REST surface.

Your entry surface is the AI gateway API. Two providers exist: the Livepeer Cloud Community Gateway at dream-gateway.livepeer.cloud (free, no key, off-chain), and gateways operated by Studio or other Solutions providers. Calling either one routes through the protocol to the GPU that runs your job.

The activation moment is your first successful API call. Use the .

Video Platform Mental Model

You’re treating Livepeer as a transcoding and playback backbone. You want ingest, ABR ladders, an HLS manifest, a player, optional VOD, and webhooks. The hosted-API closest fit is Studio (documented in Solutions). The network-direct path is a self-hosted video gateway running go-livepeer in broadcaster mode against Arbitrum One.

Your entry surface is go-livepeer itself, configured as a broadcaster. Inputs are RTMP or WebRTC streams; outputs are HLS or LL-HLS manifests that any HLS-capable player can consume. The @livepeer/react Player component wraps the browser side.

The activation moment is your first live stream with a playback URL. Use the .

Compute Primitives Mental Model

You’re treating Livepeer as a GPU compute market. You bring a container, the network handles routing and payment, you get paid per second of GPU compute. The cost model is closer to Modal or RunPod than to a hosted inference API.

Your entry surface is BYOC: a container contract, a capability ID registered against the network, and per-second compute billing under PR #3641. The reference implementations live at muxionlabs/byoc-example-apps, with the SDK at @muxionlabs/byoc-sdk.

The activation moment is your first BYOC container completing a paid job. Use the .

Live Video Mental Model

You’re treating Livepeer as a low-latency streaming backbone. You need sub-three-second glass-to-glass, ABR, and WebRTC ingest. The path is the same gateway as the video platform mental model, but tuned for latency: WebRTC ingest, LL-HLS playback, chunk sizing reduced, browser-side ABR aggressive.

Your entry surface is go-livepeer in broadcaster mode with low-latency flags. The browser side uses <Broadcast.Root> and <Player.Root> from @livepeer/react.

The activation moment is a sub-three-second loop between broadcaster tab and viewer tab. Use the , then the .

Protocol Mental Model

You’re treating Livepeer as a cryptoeconomic protocol. You’re interested in LPT, the staking and bonding mechanics, on-chain settlement, governance, and proposal flow. The Developers tab is not your home.

Your entry surface is the About tab for mechanics and contracts, and the Community tab for contribution and governance participation. Both are linked from .

Layer Disambiguation

Three distinctions trip up developers arriving from hosted-API backgrounds.

The network is the protocol plus the GPU operators running against it. It is not a product. It is reachable directly through any compatible gateway implementation. The protocol runs on Arbitrum One.

A gateway is a node that accepts your job and routes it to an orchestrator. Multiple gateway implementations exist: the reference go-livepeer binary, the Cloud SPE community gateway, j0sh’s Python implementation, and others under . You can call a hosted gateway or run one yourself.

A pipeline is a containerised AI workload that an orchestrator runs. Eleven native pipelines ship with ai-runner. BYOC lets you ship your own container as a new pipeline.

Hosted Solutions such as Studio and Daydream wrap a gateway and add hosted account management, dashboards, SDKs, and billing. The Solutions tab documents them. The Developers tab covers everything below the Solutions layer.

Coming From OpenAI

Your closest fit is the AI Inference Mental Model. The AI gateway API speaks JSON over HTTP and returns a Job ID; you poll or stream the result. The LLM pipeline accepts OpenAI’s /v1/chat/completions request shape, so existing OpenAI SDK code works against the LLM endpoint with a base URL swap.

What changes: pricing is per pipeline; LLM is per token; model availability depends on the active orchestrator set instead of one provider; the free community gateway lets you experiment without a key.

Coming From Mux

Your closest fit is the Video Platform Mental Model. The transcoding pipeline accepts RTMP and WebRTC, outputs HLS and LL-HLS, and embeds via @livepeer/react. Webhooks and asset APIs match the shape you’d expect.

What changes: you run the gateway yourself for network-direct, the orchestrators are independent operators across many providers, and on-chain settlement requires a small Arbitrum ETH balance for payments.

Coming From Modal or RunPod

Your closest fit is the Compute Primitives Mental Model. Wrap your workload in a container with a Livepeer capability ID, register the capability, and the network routes jobs to your container with per-second billing.

What changes: you don’t choose the GPU host; the network does, and payment settles through probabilistic micropayments on Arbitrum.

Once you know which mental model fits, the infrastructure stack page maps each model to the specific tools, SDKs, and infrastructure components you need.

After Choosing a Model

Infra Stack

See the persona-by-persona infrastructure map for your model.

Repo Map

The repositories behind each surface.