English

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/web handles the dashboard, Twitch sign-in, overlays, and operator settings.
  • apps/api exposes internal runtime actions for the bot and web app.
  • apps/bot listens to Twitch chat and turns commands into runtime actions.
  • apps/worker processes async enrichment jobs like YouTube metadata fetches.
  • packages/stream defines 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/stream so 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 &copy
			}
		}
	}

	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 = &copy
		}
	}
	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.

0
0
0
0