At the end of August’s roundup, I said the thing I’d underline for September was getting Alibaba models live on BlueClaw. That didn’t happen. The Livepeer Modules Suite - v2, built by the Cloud SPE, did go live, BlueClaw moved to a new backend on September 30, and I took on responsibility for helping other teams build on Livepeer.

I also built a football pool app because I was tired of trying to follow my picks through Google Sheets. That one wasn’t in the plan, but football season has a way of giving you a deadline.

BlueClaw joins Livepeer’s Live Runner direction

The Livepeer ecosystem is rallying around Livepeer’s Live Runner, and I decided BlueClaw should follow it.

I’d joined Livepeer Network Engineering SPE Phase II, with leadership responsibilities around making the ecosystem easier to build on. BlueClaw gave me a chance to use that same approach in a project of my own. If I’m going to help other developers adopt it, I want to have gone through the work myself and have a running example to point to.

So September ended with a substantial change underneath BlueClaw: a Python backend replacing the Rust service, and Livepeer’s Live Runner replacing the Livepeer Modules Suite infrastructure it had been using. The customer, admin, and OpenAI-compatible APIs were carried across so the existing sites could keep working. The execution and payment plumbing moved to orchestrators supporting Livepeer’s Live Runner, the remote signer, and Clearinghouse Batteries.

Livepeer’s Live Runner lets an orchestrator expose an external HTTP application through the network and forward client requests to it. The architecture guide shows how the application, orchestrator, discovery, and payments fit together. BlueClaw still provides the customer-facing service; underneath, it’s adopting these shared network components for running work and paying for it.

The production cutover completed September 30. With the replacement going live on the last day of the month, October will give me more to say about operating it.

I want BlueClaw to be a useful example for adoption. Moving it over is the first step; running it and finding out where builders still have to do too much work is what comes next. I’ll have more to say about that after a month on the new stack.

Livepeer Modules Suite - v2 made it out the door

Alongside that change, the Livepeer Modules Suite - v2, built by the Cloud SPE, went live. BlueClaw’s move to Livepeer’s Live Runner doesn’t erase the suite’s delivery; both happened this month.

The upgrade ran across the network modules, clearinghouse, OpenAI gateways and runners, and transcoding gateways and runners. A lot of the work was the kind that’s hard to show in a screenshot: keeping accounts separate when they share a payment wallet, recovering paid work after an interrupted process, reserving capacity before accepting a job, and making live-session shutdown and settlement recoverable.

Those details matter when an application is spending money. If a request gets interrupted, the system needs to know what it already accepted, what it already paid for, and what it can safely retry. Sharing a wallet also shouldn’t let one account’s recovery process pick up another account’s work.

I spent a good part of September making those boundaries hold across the components. The visible result is the v2 delivery. Much of the engineering behind it is about what happens when the normal path stops halfway through.

A shared foundation for Livepeer builders

My work with Livepeer Network Engineering SPE Phase II became its own sustained commitment this month, separate from the earlier Cloud SPE work whose Treasury commitments are now complete. I’m responsible for delivery of the Build Track. The Livepeer Treasury proposal sets out the program and its responsibilities.

The problem we’re tackling is familiar from BlueClaw. A team building on Livepeer has to connect access, capability discovery, pricing, execution, results, payments, and usage reporting before it can get very far with its own product. There’s enough common work there to justify a shared engine.

The plan is an open-source builder engine that applications can embed as packages or run as a service, with an HTTP API and an MCP interface for agent tools. It will integrate existing network components and come with a reference application showing the complete builder journey. Teams should be able to keep their own login, interface, and retail billing while reusing the parts that connect them to the network.

September was requirements, source assessment, architecture, and delivery planning. I worked through stakeholder input and the existing software, then put together the architecture and milestones for review. The architecture and delivery plan were accepted effective September 30, following the review window and committee responses.

Runtime integration still has to be verified. The next milestone, foundations and integration contracts, is due October 16; final delivery is planned for December 31. The September Build Track update explains the scope, and the public project tracks the milestones.

This is also why the BlueClaw decision made sense to me. My ecosystem work and my personal project now give me two ways to examine the same builder experience: designing the common foundation and using its underlying components in a running application.

I wanted a better way to follow the pool

Last year I joined a football pool run by my wife’s co-workers and friends. I’m in it again this year. The organizer uses Google Forms to collect picks and Google Sheets to keep track of the data.

That handles the organizer’s workflow, but I hated looking through those files to keep up with the pool. I wanted a UI where I could see the picks, scores, and standings without doing the spreadsheet navigation myself. So I built Football Pool Tracker.

It started as a companion to the existing setup: ingest the sheet data and make it easier to follow. It grew into live scores, scoring and tiebreaks, standings, a mobile UI, admin corrections, and what-if scenarios for looking at how game outcomes would affect the pool.

The app was live in September. The motivation is still the same small, personal one: I’m participating in this pool, and I want following it to be enjoyable.

For October, I plan to open-source the whole project and remove the Google Sheets and Forms dependency. That means taking it from a companion for our existing pool to a complete self-hosted app someone else can run for theirs. September’s version still uses the organizer’s setup; the independent version is the next piece of work.

Writing, and a few smaller experiments

I published two posts in September: August’s roundup on September 1 and MarkItDown: Converting Documents to Markdown for LLMs on September 13.

I also put together a reusable writing skill based on The Sense of Style, with editorial guidance, examples, and evaluation cases. I’m using it alongside this blog’s voice conventions. I want the help with clarity without losing the specific frustration, decision, or opinion that gave me a reason to write the post.

There were a few smaller research threads: a proposal for operator-owned Livepeer telemetry using AT Protocol, early Studio Kernel research, and Gathered Wishes discovery work. They’re at the proposal or exploration stage. I’ll give them more space when there’s a result worth explaining.

What I deliberately parked

August ended with a software factory I hadn’t planned to build and a project-management system meant to keep the portfolio honest. September gave that system some decisions to record.

My Dayflo contributions are complete, and I have no current assignment there. Software Factory is parked as weekend tinkering until a concrete need makes it worth more attention. I made a few improvements to it this month, but it didn’t become a daily priority.

That answers August’s invitation to ask whether I’d let the factory earn its keep. I worked on it a little, then chose to spend my attention elsewhere. BlueClaw, the Livepeer Modules Suite - v2, and Livepeer Network Engineering SPE Phase II took the larger share.

October: run the new stack and open the football app

October has three concrete threads: follow through on BlueClaw’s migration to Livepeer’s Live Runner and report how it works in practice, deliver the October 16 Build Track milestone for Livepeer Network Engineering SPE Phase II, and turn Football Pool Tracker into an open-source app that can run without Google Sheets or Forms.

The BlueClaw cutover happened on the last day of September, so next month’s roundup should have more to say about life after the migration. The football app has a different test ahead: making it useful to someone running a pool outside our group.

Find me on X, in the Livepeer Discord (#orchestrating, @mike_zoop), or at [email protected].

Mike