Cuepoint Control Center: Planning Streams Like a Runtime System
Cuepoint is a stream operations stack for Twitch production work: planning a show, coordinating chat-driven markers, managing VOD-oriented metadata, and automating stream title changes from the live control room. The project started as a Go monorepo for markers, FFmpeg command generation, and bot automation, then expanded into a Next.js control center that gives the streamer one place to plan, operate, and inspect live state. Cuepoint is built around a shared stream runtime model that powers the dashboard, chatbot, overlays, and post-production workflows.
Runtime Architecture
Cuepoint separates live production responsibilities into independent services:
- operator workflow
- runtime orchestration
- chat command execution
- asynchronous enrichment
- shared stream state
This separation keeps the live runtime deterministic while allowing overlays, bots, and dashboards to evolve independently.
What Cuepoint Is Building
The main goal is to turn stream planning into something closer to a live runtime than a static calendar. A stream plan is not just a list of notes. In Cuepoint, a plan has ordered segments, segment timing, title overrides, YouTube react metadata, chatbot markers, and runtime state that can be acted on while the stream is live.
The control center is the operator-facing layer. It is built with Next.js and shadcn/ui, and it sits on top of the existing Go services:
apps/webhandles the dashboard, Twitch sign-in, overlays, and operator settings.apps/apiexposes internal runtime actions for the bot and web app.apps/botlistens to Twitch chat and turns commands into runtime actions.apps/workerprocesses async enrichment jobs like YouTube metadata fetches.packages/streamdefines the shared runtime model for plans, segments, sessions, markers, and title formatting.
Core Features
Stream planning
Users can create dated stream plans, add ordered segments, and give each segment planning notes, timing rules, estimated duration, and optional stream title overrides. Segments can be clock-based or elapsed-time-based, which makes the same model work for scheduled shows and live improvised segments.
Title automation
Cuepoint can capture the original Twitch stream title, update it automatically when a segment starts, and restore it when the segment ends. Title format strings are configurable, so the bot can support patterns like:
{original_title} | {segment_title}- custom per-session overrides
The bot also exposes chat commands to restore the original title, apply the current segment title, toggle automatic title updates, and inspect or reset the format.
React segments
Segments can point at YouTube URLs. Cuepoint resolves metadata for those links, including the video title, creator name, and canonical URL. That metadata feeds both chatbot replies and overlay pages for OBS browser sources.
Overlays
The web app serves overlay routes for persistent and periodic react overlays. Those pages are designed for browser sources and read public overlay data rather than exposing internal user IDs.
Chatbot markers
The bot can create timeline markers from chat commands. That matters because the same marker stream can later be used for VOD cutting, FFmpeg command generation, and post-show review.
Why The Architecture Looks Like This
The project deliberately splits responsibilities:
- The web app owns human workflow.
- The API owns runtime orchestration.
- The bot owns chat parsing and command execution.
- The worker owns background enrichment.
- Shared Go types live in
packages/streamso the runtime model stays consistent everywhere.
That split keeps the bot thin and makes the live state model reusable across the API, dashboard, overlays, and worker jobs. It also makes it easier to toggle features on or off per user later, which is already reflected in the bot settings model.
Interesting Code Snippet
One of the more important pieces is the active-segment resolver. It decides what segment the stream is currently in, and it now prefers the live session’s current segment before falling back to schedule math. That keeps manual runtime actions aligned with what the bot reports in chat.
func ResolveActiveSegment(plan StreamPlan, session StreamSession, segments []PlanSegment, now time.Time) *PlanSegment {
if len(segments) == 0 {
return nil
}
SortSegments(segments)
if session.CurrentSegmentID != "" {
for i := range segments {
if segments[i].ID == session.CurrentSegmentID {
copy := segments[i]
return ©
}
}
}
var active *PlanSegment
for i := range segments {
segment := segments[i]
start, ok := resolveSegmentStart(plan, session, segment)
if !ok || now.Before(start) {
continue
}
end := start.Add(time.Duration(segment.DurationEstimateSeconds) * time.Second)
if segment.DurationEstimateSeconds <= 0 || now.Before(end) {
copy := segment
active = ©
}
}
return active
}
The key idea here is simple: runtime state should win over pure schedule prediction when the stream is already live. That keeps commands like !react, !watching, and !nextsegment attached to the segment the operator actually started.
Product Direction
Cuepoint is aiming for a practical, production-focused control center rather than a generic content planner. The long-term shape is:
- one place to define a stream
- one place to operate it live
- one bot that understands the plan
- one shared model for markers, titles, overlays, and post-production artifacts
That makes the project useful both as a stream desk during a live show and as a source of structured data for VOD workflows afterward.
Current State
The first control center pass is in place:
- Twitch sign-in via Better Auth
- sidebar dashboard UI with dark mode
- stream plan editing
- dev overrides for forcing live state
- internal Twitch bridge routes
- chat commands for title and segment control
- marker and react segment plumbing
The next obvious step is tightening runtime behavior around real Twitch streams and expanding the dashboard from scaffold into a full operational console.