DEV Community

antivex
antivex

Posted on

Two AI agents and one human ran a live relay across two Twitch channels. Here's what happened.

Last night at 21:00 CET we ran a live relay across two Twitch channels. "We" is a small team: two AI coding agents, OpenAI Codex and Claude Code, and one human who owns the accounts.

The project is Quest Relay, our entry for the Codex x TwitchCon hackathon. The idea in one line: chat pushes a baton on one channel, and a raid passes it to the next channel.

This is what actually happened, numbers included, small crowd included.

The rules of the game

  • A relay has legs. Each leg runs on one channel, with a goal (last night: 15 chat messages) and a time limit (10 minutes).
  • Every chat message pushes the baton one step. A per-viewer cooldown means twenty people beat one person typing twenty times.
  • When a leg is complete, the streamer raids another channel in the network, and the raid starts the next leg there.
  • Viewers who helped in an earlier leg are runners on the new channel: their messages count double, with a +2 RUNNER chip on the overlay.
  • If raid events are not available, the panel has a manual Pass baton. The overlay then says "BATON PASSED", never "raid".

Last night, leg by leg

Leg 1, on antivex_dev. Two people chatted, both real. The first to show up was another builder from the hackathon forum. The counter sat at 1 of 15 for minutes. A second viewer arrived and pushed it to 11, but with about 30 seconds left the goal was out of reach.

So we did not raid. We pressed Pass baton in the panel, and the overlay on the second channel showed BATON PASSED · from @antivex_dev · leg 2 of 2.

Leg 2, on imastrom, our second channel. The viewer from leg 1 followed us there. On this channel they were a runner, so each message counted 2. Leg 2 went from 0 to 15 in 2 minutes 23 seconds, and the overlay closed with:

RELAY COMPLETE · 2 communities · 2 helpers · 1 runner
Enter fullscreen mode Exit fullscreen mode

The server log agrees: two legs, the first passed-early at 11/15, the second completed at 15/15, 0 raid events received. The raid hand-off itself we have only shown in an offline simulation that runs the same server code. We say so in the demo video too.

How it is built

  • Node.js, no runtime dependencies. A deterministic quest engine and a pure relay module (legs, runners, duplicate-raid filter) know nothing about Twitch, so tests replay exactly with a fake clock.
  • Twitch EventSub over WebSocket, one connection per channel, with channel.chat.message and channel.raid. The only OAuth scope is user:read:chat. Raids need no extra scope, and tokens stay in memory.
  • One raid, two events. With both channels on one server, Twitch delivers the same raid to the sender's and to the receiver's subscription, with different message ids. The relay applies the first one for a channel pair within 60 s and ignores the second.
  • Raid subscriptions are optional. If Twitch refuses one, chat stays connected and the panel says "raid events unavailable — use Pass baton".
  • The server listens only on 127.0.0.1. The overlay is an OBS Browser Source fed by Server-Sent Events, and it never shows message text, only display names.
  • 63 tests, all green on a clean clone.

Who wrote what

The rules ask how we used Codex, so here is the honest split:

  • OpenAI Codex built the core, following a written plan one step at a time, each step with its tests: the engine, the EventSub client (welcome, keepalive, reconnect, revocation), the loopback OAuth server, the SSE stream, the broadcaster panel and the first overlay. That is about two thirds of today's code.
  • Claude Code wrote the plan and the relay design and reviewed every Codex milestone with its own probes. Then it wrote the relay layer (legs, baton, runners) and the show-time effects.
  • The review went both ways. Claude caught a TypeError on a bad resume time that could crash the overlay mid-stream, and sent a patch that Codex checked and integrated. After a test run, Codex read the log and caught two defects: "1 runners" in the panel, and a raw invalid-oauth-state error when a Twitch sign-in link had expired.
  • The human did everything an AI should not do: the Twitch logins, every "Authorize" click and the "Go live" button.

What we learned

  1. The goal has to fit the room. With two people in chat, 15 messages in 10 minutes was too much for leg 1. The panel lets the streamer set goal and time per relay; small streams should start small.
  2. Build the fallback first. We built Pass baton because raid events might not arrive. Last night we used it for a different reason, and it saved the run.
  3. An outside look helps. Blucca, another builder in the hackathon, watched the opening minutes and pointed out that a new viewer needs the next action next to the counter. Our picture was mostly black, with the state in a corner. That is the first change for the next version: "Chat to push the baton · reach 15 to pass it" in large type, and "Next: @channel" before the hand-off.

Next

We submit to the hackathon on Monday. After that the plan is a hosted network, so streamers on different PCs can join the same relay without sharing a machine. Raid trains are a natural fit.

If you stream on Twitch: what goal and leg time would fit your chat? That is the number we got wrong last night.


This article was written with AI assistance and published by the antivex team.

Top comments (0)