DEV Community: Vihanga

Facebook as a headless CMS: building a Sri Lankan F1 fan site on Next.js 16

Vihanga — Wed, 30 Sep 2026 15:24:30 +0000

F1 Paddock SL is a Formula 1 fan site I build for Sri Lankan supporters: race analysis, driver stories in Sinhala and English, live standings and telemetry, and paddock news pulled from our Facebook Page. It's live at f1paddocksl.com.

It's a fan project, not a startup. Nobody is paying for F1 data, and I don't have a newsroom. That constraint shaped every decision in the stack — and one of them turned out to be the most interesting thing in the codebase: Facebook is the CMS.

This is the six things that cost real time, and what I'd do differently.

The shape of it

app/            22 pages: calendar, drivers/[id], standings, dashboard,
                schedule, news, stories, teams, constructors, video, faq
app/api/        5 routes: openf1/[...path], fbimg, fb-chat, news, comments
components/     35 components (WebGL hero, live timing boards, dotted track maps)
lib/            f1.ts (data), facebook.ts (Graph API), blog-cache.ts, comments.ts
scripts/        refresh-fb-token.mjs
data/           fb-posts.json + one JSON file per cached post

Next.js 16.3 (App Router), React 19.2, TypeScript, Tailwind v4, MUI 9, Supabase, three.js. 34 dependencies total.

1. Two free F1 APIs, and cache by how fast the data rots

There is no official F1 API you can afford. There are two good free ones, and they solve different problems:

Jolpica (the community-run Ergast successor) — standings, schedules, results, qualifying.
OpenF1 — live timing: car telemetry, positions, session metadata.

I used both, and the interesting part is that they get very different cache lifetimes. A constructor's point total changes once a week. A car's gear changes four times a second.

Data	Source	`revalidate`
Standings, schedule, results, qualifying	Jolpica	3600s
Facebook post feed	Graph API	600s
Facebook follower count	Graph API	1800s
Facebook live chat	Graph API	`no-store`
Live positions, car telemetry	OpenF1	15s

The whole TTL policy is one optional parameter:

async function fetchJson(url: string, revalidate = 3600) {
  const res = await fetch(url, {
    headers: { Accept: "application/json", ...(isServer ? openf1Headers() : {}) },
    ...(isServer ? { next: { revalidate } } : {}),
  });
  if (!res.ok) throw new Error(`API error ${res.status}: ${url}`);
  return res.json();
}

You get this wrong in both directions. Set a 1-hour TTL on positions and your live timing board is a lie. Set no-store on standings and you've turned a static page into a request that hammers a free community API on every visit — which is how you get rate-limited and the whole site goes blank.

The same library, two transports

Server Components can't share a fetch cache with the browser, so the data layer picks a transport per environment:

function openf1(path: string): string {
  return isServer ? `${OPENF1_BASE}${path}` : `/api/openf1${path}`;
}

Server components call OpenF1 directly and get Next's data cache for free. Client components hit our own /api/openf1/[...path] proxy, which re-applies the same revalidate and forwards the optional bearer token. One data layer, two callers, no duplicated logic.

The proxy is 20 lines and exists purely so a client component can read a JSON API without dragging CORS or a token into the browser.

Don't fan out without a cap

Generating season race reviews meant fetching results and qualifying for each of the last 10 rounds. Straight Promise.all means 20 simultaneous requests at a free API on the first cold cache hit.

export async function mapLimit<T, R>(
  items: T[], limit: number, fn: (item: T) => Promise<R>,
): Promise<R[]> {
  const out: R[] = new Array(items.length);
  let i = 0;
  async function worker() {
    while (i < items.length) {
      const idx = i++;
      try {
        out[idx] = await fn(items[idx]);
      } catch {
        out[idx] = undefined as unknown as R; // one failed round, not a failed page
      }
    }
  }
  await Promise.all(Array.from({ length: limit }, worker));
  return out;
}

const reviews = await mapLimit(finished, 3, async (race) => { /* ... */ });

Three workers, and a single failed round drops out of the list instead of taking the page with it.

2. The CMS was already on Facebook

Here's the actual problem. The people writing paddock news are not logging into an admin panel. They are posting on the Facebook Page, because that's where the audience already is.

So rather than build an editor, I read the Page through the Graph API and treat it as a content backend:

POST to Facebook Page  →  Graph API /{page-id}/posts  →  normalised FetchedPost  →  JSON on disk  →  blog

The normalisation is the part that matters. Facebook's post shape is generous — message, story, description, attachments, child_attachments — and inconsistent. I flatten it into one type and make a decision about what a post's title is, because Facebook posts don't have titles:

const heading =
  message.split("\n")[0].trim() ||
  description.split("\n")[0].trim() ||
  attachment?.title ||
  story ||
  `New post from ${pageName}`;

const title = heading.slice(0, 110);

First line of the message, truncated. That's it. It works because our posts are written with a deliberate first line, which is a content rule, not a technical one — worth being honest about that in a headless CMS.

The cache is the site

Once Facebook is your database, you have a hard dependency on someone else's uptime, rate limits, and token policy. So the cache isn't an optimisation. It's the site.

export async function getCachedBlogPosts(limit = 20): Promise<BlogPost[]> {
  const cached = readCache();
  try {
    const live = await getBlogPosts(30, "Facebook");
    if (live.length) {
      const map = new Map<string, BlogPost>();
      for (const p of [...live, ...cached]) {   // live wins, cache fills the gaps
        const key = dedupeKey(p);              // id → link → title
        if (key && !map.has(key)) map.set(key, p);
      }
      const merged = Array.from(map.values()).sort(
        (a, b) => new Date(b.pubDate).getTime() - new Date(a.pubDate).getTime(),
      );
      writeCache(merged);
      merged.forEach(writePostFile);
      return merged.slice(0, limit);
    }
  } catch {
    // live fetch failed — fall back to cache
  }
  return cached.slice().sort(/* … */).slice(0, limit);
}

Two files per refresh: a merged data/fb-posts.json for listing pages, and one permanent file per post in data/posts/. The per-post file is the important one. It's what makes a direct link to /blog/{id} keep working after a cache rebuild, a Facebook outage, or a deleted post.

There are 65 of them on disk right now. The blog is effectively a Git-less archive of our Page.

Every read path in this codebase does the same thing: try the network, and on any failure return the last known-good value. readCache swallows corrupt JSON, writeCache swallows read-only filesystems, getFacebookPosts returns [] instead of throwing. The F1 site's core promise is "never show the user an error page" — the blog is just where that promise is hardest to keep.

3. Sixty days is not a long time

Meta does not give you a permanent credential. A Page Access Token is good for about 60 days. This site needs to run for years.

The naive version is a human noticing the follower counter going to zero and copying a new token out of the Graph API Explorer into .env.local and the Vercel dashboard. That's a monthly chore with a failure mode nobody notices until it ships.

So the token became a scheduled job:

1. extend the stored long-lived user token   (oauth/access_token, fb_exchange_token)
2. swap it for a fresh page token            (/me/accounts, matched on FB_PAGE_ID)
3. verify it against the Graph API          (name + follower count)
4. write it back to .env.local              (masked output, never printed)
5. PATCH the value into Vercel project env  (production + preview + development)

Step 5 is the one I care about. It hits api.vercel.com/v9/projects/{id}/env/{id} and patches the existing variable in place, rather than creating a duplicate, across all three targets. So production picks up a new token without a redeploy and without a dashboard session.

const res = await fetch(
  `https://api.vercel.com/v9/projects/${projectId}/env/${found.id}`,
  {
    method: "PATCH",
    headers,
    body: JSON.stringify({ value, target: ["production", "preview", "development"] }),
  },
);

npm run fb:refresh, on a monthly cron. If the local write succeeds but the Vercel push fails, it logs a warning and exits cleanly — the local value is still correct, so re-running is safe.

The general lesson: anything with an expiry is infrastructure, not configuration. A credential in a .env file that a human is expected to renew is a scheduled job wearing a disguise. I wrote this script after the follower count silently hit zero twice.

4. Never render an image URL you don't control

Facebook post images broke the layout constantly, for two separate reasons:

Hotlink protection. The browser can't load scontent.xx.fbcdn.net URLs directly — they need a referrer and a browser-shaped user agent.
Signed expiry. The URL carries an oe= expiry token. Once it lapses, the CDN returns an error. A post from six months ago has a dead image URL, and that URL is baked into the JSON we cached.

You cannot fix this in the browser. The fix is a server-side proxy with an allowlist:

const u = req.nextUrl.searchParams.get("u");
if (!u || !/^https:\/\/(scontent\.|.*\.fbcdn\.net|www\.facebook\.com|m\.facebook\.com|platform-lookaside\.fbcdn\.net)/.test(u)) {
  return new Response("Invalid URL", { status: 400 });
}

That regex is the whole security model of the route. Without it you've written an open proxy that will fetch any URL anyone sends it — including 169.254.169.254, which is the SSRF mistake that turns a fan site into a cloud-credentials leak. If you build one of these, the host allowlist is not optional, and it should be as narrow as you can make it.

And when the upstream fails anyway — expired signature, deleted post, CDN hiccup — the route returns a 200 with a generated SVG instead of a 404:

const svg = `<svg width="1200" height="675" viewBox="0 0 1200 675">
  <defs><linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">…</linearGradient></defs>
  <rect width="1200" height="675" fill="url(#bg)"/>
  <g fill="#ffffff" opacity="0.04">
    ${Array.from({ length: 10 }, (_, r) =>
      Array.from({ length: 16 }, (_, c) =>
        `<rect x="${c * 80 + (r % 2 ? 40 : 0)}" y="${r * 75}" width="40" height="40"/>`).join(""),
    ).join("")}
  </g>
  <rect width="10" height="675" fill="#e10600"/>
  <text x="600" y="330" text-anchor="middle" font-size="52" fill="#ffffff">F1 PADDOCK SL</text>
  <text x="600" y="386" text-anchor="middle" font-size="22" letter-spacing="6" fill="#e10600">FORMULA 1 · SRI LANKA</text>
</svg>`;

The r % 2 offset generates a chequered flag. A dead image still reads as a flag, the layout never shifts, and a 40-year-old F1 fan site doesn't look broken.

5. Two design systems, one App Router

The UI is Tailwind v4 with shadcn components. A few data-heavy surfaces (the timing tables, the tabbed data views) are MUI. Both ship CSS-in-JS-or-utility opinions, and in the App Router that combination has a specific failure mode: Emotion injects styles at runtime, so MUI components FOUC or hydrate-mismatch if the cache isn't registered during SSR.

The fix is one component, and it has to wrap everything:

"use client";
import { AppRouterCacheProvider } from "@mui/material-nextjs/v16-appRouter";

export default function MuiProvider({ children }: { children: React.ReactNode }) {
  const { resolved } = useThemeMode();
  return (
    <AppRouterCacheProvider options={{ key: "paddock" }}>
      <ThemeProvider theme={createAppTheme(resolved)}>{children}</ThemeProvider>
    </AppRouterCacheProvider>
  );
}

AppRouterCacheProvider is MUI's own App Router integration — it handles Emotion's server style extraction and insertion. The subpath matters: /v16-appRouter for Next 16.

Then, so the two systems can't drift, the MUI theme is generated from the same light/dark tokens Tailwind reads:

export function createAppTheme(mode: "light" | "dark"): Theme {
  const C = mode === "light" ? LIGHT : DARK;
  return createTheme({
    palette: {
      mode,
      primary: { main: C.red, dark: C.redDark },
      background: { default: C.bg, paper: C.elevated },
      text: { primary: C.text, secondary: C.textDim },
      divider: C.border,
    },
    shape: { borderRadius: 4 },
  });
}

One source of truth, two renderers. A MUI button and a shadcn button are the same red in dark mode because they read the same constant.

6. Bilingual by font fallback, not by translation layer

Driver stories ship in English and Sinhala on the same page. The naive approach is a language toggle and two strings per field. I just concatenated them and let the font stack do the routing:

const sinhala = Abhaya_Libre({ subsets: ["latin", "sinhala"], … });
const sinhalaHeading = Gemunu_Libre({ subsets: ["latin", "sinhala"], … });
const bigHeading = Bricolage_Grotesque({ subsets: ["latin"], axes: ["opsz"], … });
const f1Font = Russo_One({ weight: ["400"], subsets: ["latin"], … });

Latin glyphs resolve against the Latin face at the front of the stack; Sinhala glyphs have no glyph in Geist, so the browser falls through to Abhaya or Gemunu. One journey field in English and one si.journey in Sinhala, both rendered, both indexed.

The F1-specific part: Russo_One is the closest freely-licensed stand-in for the official Formula1 wordmark, and it's applied only to the live race-countdown numerals, where wide condensed digits are the entire aesthetic. Bricolage_Grotesque carries the opsz axis so the browser picks a heavier display cut for large headlines.

While I was in there: no flash of the wrong theme. A beforeInteractive script reads localStorage and resolves system against prefers-color-scheme before first paint, so a dark-mode visitor never gets a white flash.

var stored = localStorage.getItem("paddock-theme");
var theme = stored === "light" || stored === "dark" || stored === "system" ? stored : "system";
var resolved = theme === "system"
  ? (window.matchMedia("(prefers-color-scheme: dark)").matches ? "dark" : "light")
  : theme;
document.documentElement.classList.add(resolved);

It's 15 lines of blocking script and it's the difference between the site feeling native and feeling cheap.

Small things that mattered

SEO from one constant. SITE_NAME, SITE_URL, SITE_DESCRIPTION in lib/site.ts feed the root metadata, the WebSite JSON-LD, the manifest, robots.txt, and the sitemap. Renaming the site was a one-line diff that updated every surface — including the alternateName field that tells Google which name to index.

Live chat, carefully. A Messenger-style widget polls /api/fb-chat, which is force-dynamic + no-store and hits Graph API fresh each time. Nested comments come back in one request using field expansion rather than N+1:

comments.summary(true).limit(6){id,from{name,picture.width(64).height(64)},message,
  created_time,comments.summary(true).limit(3){…}}

The constraint that shaped it: it must never be cached, because a stale comment count on a live race thread is worse than no widget at all.

What I'd do differently

Move the cache off the filesystem. data/*.json works great locally and on a long-lived Node host, but it's a poor fit for read-only serverless filesystems. Supabase is already connected for comments and authored posts; the blog cache should live there too.
Stop scraping titles from the first line. It works because we wrote the posts that way. A real editorial field would be one API permission away and would survive me changing how we write.
Add a token-expiry alarm. The cron keeps the token alive, but nothing tells me if the cron itself stopped. A 60-day silent failure is exactly the kind of bug that ships and nobody files a ticket about.
Delete the dual design system eventually. Tailwind and MUI in one App Router tree works, but every future contributor has to learn which one to reach for. I inherited that decision and haven't found a cheap way to undo it.

The through-line across all six: this project runs on other people's infrastructure — Meta's Graph API, Jolpica's mirrors, OpenF1's rate limits, Vercel's env store. The engineering wasn't really about Next.js or WebGL. It was about caching aggressively, failing soft, and turning every expiring credential into a scheduled job so the site keeps answering long after everyone's API keys expire.

If you're building something on free community APIs, budget for that. It's the actual project.

Streaming YouTube into a Discord voice channel: the four bugs that nearly killed it

Vihanga — Wed, 30 Sep 2026 14:41:45 +0000

Shen is a self-hosted music bot I run for my own server. You search a song on the web app, hit play, and it either streams in your browser or lands in a Discord voice channel — same track, same queue, one process.

Live at shen.zagan.space. Source is private for now.

This isn't a tutorial. It's the four problems that took real time, and the fixes.

The shape of it

One Node process, one repo, two deployment targets:

server.js      Express: REST API + Server-Sent Events + serves the built site + boots the bot
bot.js         discord.js + @discordjs/voice: joins channels, streams audio, 14 slash commands
audio.js       yt-dlp → ffmpeg → the browser player, and YouTube captions → synced lyrics
queue.js       per-guild queues + the web "pending" buffer (both are EventEmitters)
search.js      YouTube + YouTube Music search, tolerant of layouts changing under it
store.js       JSON persistence: pending, library, history, playlists, favorites
ytdlp-util.js  the single place that decides how yt-dlp talks to YouTube
web/           Vite + React 19 + Tailwind v4 + shadcn/ui

Backend on Render (Docker, because it needs ffmpeg and yt-dlp binaries), frontend on Vercel with /api/* rewritten to the backend. The container entrypoint is literally:

CMD ["sh", "-c", "wireproxy -c /app/warp/wireproxy.conf & sleep 3 && node server.js"]

You'll see why that exists in a minute.

Live state is a plain SSE stream. Every mutation emits change on the queue manager, one function serializes a snapshot, every connected browser gets it:

queueManager.on("change", broadcast);

app.get("/api/events", (req, res) => {
  res.set({
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive",
  });
  // 15s comment-ping so proxies don't reap an idle stream
  const heartbeat = setInterval(() => res.write(": ping\n\n"), 15000);
  ...
});

No WebSocket library, no shared mutable state on the client, and the queue UI in the browser is always exactly what the bot thinks the queue is.

1. "Sign in to confirm you're not a bot"

This is the wall. yt-dlp worked perfectly from my laptop and returned nothing at all from Render — not a 403, just zero formats. YouTube blocks datacenter IP ranges at the playability check, before it even looks at cookies.

Two changes fixed it. First, don't claim to be a browser that isn't, and try several player clients:

export async function ytdlpBaseArgs() {
  const args = [
    "--no-warnings",
    "--no-progress",
    "--force-ipv4",
    "--extractor-args", "youtube:player_client=web,mweb,android",
    "--user-agent", UA,
  ];
  if (await isWarpAvailable()) args.push("--proxy", WARP_PROXY);
  return args;
}

Second — and this is the part that actually mattered — change the exit IP. I run a Cloudflare WARP userspace proxy (wireproxy, a single static binary) inside the container and point yt-dlp at socks5://127.0.0.1:1080. The availability check is a 2-second TCP connect that gets cached, so when the proxy isn't running the app degrades to a direct connection instead of hanging:

export async function isWarpAvailable() {
  if (warpAvailable !== null) return warpAvailable;
  warpAvailable = await new Promise((resolve) => {
    const sock = net.connect({ host, port });
    sock.setTimeout(2000, () => done(false));
    sock.once("connect", () => done(true));
    sock.once("error", () => done(false));
  });
  return warpAvailable;
}

If you take one thing from this post: when a scraper works at home and returns nothing in production, suspect your egress IP before you suspect the scraper.

2. Silence, but with a green status light

Discord voice wanted Opus. I was handing it Opus. It played pure silence.

The reason is in the ffmpeg invocation. If you declare an already-encoded ogg/Opus stream as StreamType.Opus, the decoder assumptions don't line up and you get zeros. Give it raw PCM instead and let @discordjs/voice run its own encoder:

const ffmpegArgs = [
  "-i", "pipe:0",
  "-f", "s16le",       // raw PCM, not a container
  "-ar", "48000",      // Discord's native sample rate
  "-ac", "2",
  "-acodec", "pcm_s16le",
  "-map_metadata", "-1",
  "-loglevel", "error",
  "pipe:1",
];

ytdlp.stdout.pipe(ffmpeg.stdin);
// only resolve once real audio is flowing, not when the process spawns
ffmpeg.stdout.once("data", () => {
  resolve({ stream: ffmpeg.stdout, proc: ffmpeg, inputType: StreamType.Raw });
});

Note the last line. Spawning successfully means nothing — I only start the AudioPlayer after the first byte of PCM arrives, with a 30s timeout to kill both children. Otherwise a slow extraction shows up as an instant "nothing is playing".

3. One dropped connection took down the whole server

Render started returning 502s at random. The log said EPIPE.

In Node, an error event on a stream with no listener is thrown. Not handled — thrown, globally. My audio pipeline had four streams (ytdlp.stdout, ytdlp.stderr, ffmpeg.stdin, ffmpeg.stdout) and when someone closed their laptop mid-track, ffmpeg.stdin emitted EPIPE with nobody listening, and the entire bot + API process died. Restart, wait, repeat.

The fix is unglamorous and mandatory. Attach a listener to every child-process stream:

const safeOnError = (label, stream) =>
  stream.on("error", (err) => console.warn(`[bot] ${label} stream error: ${err.message}`));
safeOnError("ytdlp stdout", ytdlp.stdout);
safeOnError("ytdlp stderr", ytdlp.stderr);
safeOnError("ffmpeg stdin", ffmpeg.stdin);
safeOnError("ffmpeg stderr", ffmpeg.stderr);
safeOnError("ffmpeg stdout", ffmpeg.stdout);

And a safety net at the top of the process, because one missed stream should never be an outage:

process.on("uncaughtException", (err) => console.error("[server] uncaughtException:", err));
process.on("unhandledRejection", (reason) => console.error("[server] unhandledRejection:", reason));

I'd rather have a degraded bot than a 502 page. Treat every child-process stream as capable of throwing at you, because they will.

4. The bug that was actually a security hole

The web app had a "send this to Discord" button. It POSTed a guildId and channelId to my API, and the API passed them straight to the bot.

Which means any visitor could POST the ID of any server the bot was in and steer it into any voice channel. It's a single-user app, so it didn't feel like an auth problem — but it was.

The fix inverts the trust direction. The client never gets to say where. The server derives the destination from the caller's own Discord voice state, which the bot already tracks:

function requireVoiceAuth(req, res) {
  const user = sessionUser(req);
  if (!user?.id) {
    res.status(401).json({ error: "Sign in with Discord required" });
    return null;
  }
  const voice = getUserVoiceState(user.id);
  if (!voice) {
    res.status(400).json({ error: "You're not in a voice channel. Join a voice channel in Discord first." });
    return null;
  }
  // guildId + channelId come from Discord's own voice state, never the request body
  const guild = client.guilds.cache.get(voice.guildId);
  return { guildId: voice.guildId, channelId: voice.channelId, guild };
}

You can only control the server you're actually connected to, because the server checked. Session IDs live in an in-memory Map behind an HttpOnly cookie — I originally packed the user object straight into the cookie and it grew past the 4KB limit, which silently broke every login callback. Moving session state server-side fixed it in one commit.

Two more worth mentioning

The double-add. Clicking "Queue" on the website added the track to the web's pending buffer and fired the bot's play path, so every track appeared twice. The fix is a single decision in one place:

async enqueue(track) {
  const active = this.activeQueue();
  if (active && active.playing) {
    return active.add({ ...track, queuedVia: "website" }); // live, exactly once
  }
  return addPending(track); // idle: buffer until /join or /play
}

Live queue if the bot is playing, pending buffer if it isn't. Never both.

The double-start race. When a track ended, q.next() emitted a change event that triggered playback, and the player's own Idle handler also triggered playback. Same track, started twice, queue advancing twice. A one-line reentrancy guard fixed it:

const starting = new Set(); // guards the gap between "ended" and "next stream up"

async function playTrack(guildId, track) {
  if (starting.has(guildId)) return;
  starting.add(guildId);
  try { /* ... */ } finally { starting.delete(guildId); }
}

The part nobody warns you about

YouTube reorganised its search results page and my search broke in production while my last commit was green. play-dl aborts the entire batch when it hits a single channel or Shorts card, so I stopped trusting it and parse ytInitialData myself, skipping anything that isn't a plain video:

const v = item?.videoRenderer;
if (!v?.videoId) continue;                       // not a video: channel, playlist, shelf
if (v.upcomingEventData?.startTime) continue;     // scheduled premiere
if (!v.lengthText?.simpleText) continue;          // live stream, no duration

Same story for playlists, which moved to a new lockupViewModel shape, and for YouTube Music, which goes through the InnerTube WEB_REMIX endpoint. I wrapped every third-party call that ships with no timeout — play-dl's validate, playlist_info, all_videos — in my own, because one slow URL will otherwise hang a request for minutes and hold a connection open:

function withTimeout(promise, ms, label) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error(`${label} timed out after ${ms / 1000}s`)), ms);
    promise.then((v) => { clearTimeout(timer); resolve(v); },
                 (e) => { clearTimeout(timer); reject(e); });
  });
}

Assume every scraper is one deploy away from breaking, and write the fallback parser before you need it.

One non-code bug worth writing down

Vercel builds failed with vite: command not found. The cause was my own: I'd run npm install --package-lock-only in web/ to quiet a dependency warning, and it pruned vite out of the lockfile. Vercel runs npm ci, which installs exactly what the lockfile says — so no Vite.

The trap that cost me an hour: npm run build still succeeded locally, because node_modules on my machine still had the old Vite installed. A green local build tells you nothing about your lockfile. Regenerate it, confirm node_modules/vite is in the lockfile, commit it.

What I'd do next

A real database. Everything is JSON files rewritten on every mutation. Fine for one user, wrong the moment there's a second.
Remove play-dl from bot.js. The comment claims it's a stream fallback; the code only ever uses yt-dlp. It's still load-bearing in search.js, where it is.
Drop googleapis and opusscript. Both are dependencies I stopped using.
Multi-user separation. Right now the bot has one active guild at a time. Proper per-user queues with real auth is the obvious architectural next step.

Honest limitations

Streaming YouTube audio to other people is against YouTube's terms and will hit rate limits at any real scale. This is a personal server tool, not a product.
Only the active guild's queue is surfaced on the website at a time.
The WARP proxy is a workaround, not a fix. YouTube could close this hole tomorrow and I'd be back to square one on a different error message.

If you're building something similar, the hard parts in order of how much time they cost me: egress IP → stream error handling → trusting the client → layout drift. Everything else was ordinary CRUD.

Cursor releases its own self-trained LLM - Also launched a Git platform called Origin + mobile app

Vihanga — Thu, 23 Jul 2026 19:30:54 +0000

Cursor's Shift From AI Code Editor to Full-Stack Developer Ecosystem

Cursor has officially expanded beyond an AI code editor into a full-stack developer ecosystem. At its inaugural Compile 26 conference, Cursor announced three major products: a 1.5-trillion-parameter proprietary AI model, an AI-native Git hosting platform called Origin, and a mobile app for on-the-go agent management.

1. Custom 1.5-Trillion-Parameter LLM

Instead of relying strictly on third-party foundation models, Cursor is shifting toward vertical integration.

Massive scale: a 1.5T-parameter frontier model pre-trained completely from scratch
Compute power: trained on over 100,000 GPUs via a strategic compute partnership with SpaceX
Deep integration: optimized natively for complex, multi-file code execution, reasoning, and context-aware editing within Cursor Composer

2. Origin: The "Agentic" Git Platform

Built as a direct competitor to GitHub, Origin is a Git forge redesigned from first principles for a world where AI agents outnumber human coders.

High-throughput branching: built to comfortably process thousands of parallel agents making concurrent commits and rebases
Automated pipeline: AI-driven merge conflict resolution, automated CI bug fixing, and automated PR reviews
Human-in-the-loop: the platform autonomously handles repetitive infrastructure tasks, only pinging human developers when a high-level review is strictly necessary
Graphite engine: leverages architecture from Cursor's acquisition of Graphite to handle stacked pull requests seamlessly
Status: waitlist-only, with broad launch scheduled for Fall 2026

3. Cursor Mobile (iOS Beta)

Cursor Mobile changes software engineering from an active, laptop-bound task into a high-level monitoring role.

Remote control: prompt, launch, and monitor persistent, always-on AI coding agents running in isolated cloud VMs
Voice-to-code: voice input and prompt dictation to guide agents using conversational language
Live Activities: integrates with iOS lock screens for real-time push notifications when an agent completes a feature, hits a blocker, or needs review
Status: public beta, available to all paid Cursor plan subscribers

The Big Picture

These updates land amid massive momentum for the startup, following a $60 billion acquisition of Cursor's parent company, Anysphere, by SpaceX — placing it under the xAI umbrella and giving it access to the Colossus supercomputer infrastructure. By owning the editor (Composer), the review cycle (Graphite), and the hosting layer (Origin), Cursor is building what it calls the first true end-to-end autonomous "AI software factory."

Why Vertical Integration Gives Cursor a Competitive Edge

For years, Cursor operated as an extremely capable AI code editor sitting on top of someone else's foundation — calling out to OpenAI, Anthropic, or Google for the heavy lifting, then delivering results back into the editor. That approach built a massive user base, but it also created a permanent ceiling: every time a third-party model changed its pricing, behavior, or introduced latency, Cursor felt it.

Vertical integration changes that. When you own the model, the editor, the review pipeline, and the hosting layer, you stop being a wrapper and start being a platform:

The model layer — a proprietary 1.5T-parameter LLM trained specifically for code, not fine-tuned from a general-purpose base
The editor layer — Cursor Composer, already deeply embedded in developer workflows
The review layer — Graphite's stacked PR architecture, acquired and baked directly into the product
The hosting layer — Origin, the new Git forge built from scratch for agentic workflows

This stack gives Cursor something competitors relying on stitched-together third-party APIs can't replicate overnight: deep, native optimization across every step of the software development lifecycle.

Compile 26: A New Era for Developer Tools

Most developer tool companies announce incremental improvements at their events. Compile 26 dropped three category-defining announcements in a single session:

Announcement	What It Changes
1.5T-Parameter Custom LLM	Removes dependency on third-party model providers
Origin Git Platform	Challenges GitHub's near-monopoly on code hosting
Cursor Mobile iOS Beta	Redefines what "writing software" even means

An AI can now write code, commit it, open a pull request, fix CI failures, and get human review — all within a single Cursor-controlled environment. The message to enterprise buyers is clear: Cursor is positioning itself as infrastructure, not a productivity add-on.

The SpaceX Acquisition and Colossus Infrastructure

Training a 1.5-trillion-parameter model from scratch requires sustained compute at a scale only a handful of organizations can access — which is where the SpaceX acquisition of Anysphere becomes central to the story.

SpaceX's xAI division operates Colossus, one of the largest AI supercomputer clusters ever assembled, reportedly running over 100,000 GPUs in Memphis. Through this partnership, Cursor gained infrastructure access previously reserved for OpenAI, Google DeepMind, and Meta.

Why it matters beyond raw numbers:

Cost structure: owned or deeply discounted compute lowers per-token training cost compared to buying API access indefinitely
Model iteration speed: faster retraining and experimentation without negotiating GPU contracts
Competitive moat: a training run of this size is a genuine barrier to entry for pure software competitors
Alignment with Origin: as Origin scales to thousands of parallel agents, Cursor can fine-tune on the patterns and failure modes unique to agentic Git workflows

Native Multi-File Code Reasoning

General-purpose models often do well on a single function but struggle across a complex multi-file project — hallucinating, losing context, or producing plausible-sounding but wrong output. Real codebases have deeply nested dependency graphs, unwritten conventions, long-range cascading effects, and mixed paradigms that a model needs to track simultaneously.

Cursor's proprietary model is pre-trained natively for these conditions, with the model and Cursor Composer designed as a single unified system:

Extended context utilization: reasoning over entire repository structures, not just individual files
Execution-aware reasoning: tracking state mutations, call chains, and side effects the way a senior engineer would
Edit coherence across sessions: retaining meaningful context across long editing sessions
Task decomposition: breaking complex refactors into ordered sub-tasks, checking outputs between steps

What This Means for Developers Using Composer Daily

Better first-pass accuracy on complex tasks, with fewer corrections needed
Longer, more reliable agentic runs — the model holds the thread longer before going off the rails
Reduced latency on deep context queries across large monorepos
Less model-switching — one proprietary model good across the coding task spectrum
A platform that improves with usage — Cursor closes the feedback loop between real developer behavior in Composer and future training runs

Origin: The Agentic Git Platform Built to Replace GitHub

High-Throughput Branching

Traditional Git platforms were designed for human developers — a team of 50 engineers pushing commits was considered high-traffic. Origin assumes thousands of concurrent agent commits instead:

Concurrent agent isolation: each AI agent operates in its own sandboxed branch environment
Elastic branch creation: branches spin up and tear down at machine speed
Rebase at scale: thousands of concurrent rebases handled through custom infrastructure
Conflict-aware scheduling: intelligently sequences operations on overlapping files to minimize collisions

Automated Merge Conflict Resolution and CI Bug Fixing

Origin's AI analyzes the semantic meaning of both sets of changes, the broader intent behind each branch, and historical patterns from similar conflicts. When confident, it resolves conflicts automatically and explains its reasoning in plain language; when not, it flags the conflict for a human with a clear summary.

For CI failures, Origin reads error logs, traces the root cause, generates a candidate fix, re-runs affected tests, and submits the patch as part of the existing PR — landing automatically when high-confidence, or surfacing a proposed fix with context otherwise.

Task	Traditional Workflow	Origin Automated Workflow
Merge conflict resolution	30–120 min per conflict	Seconds to minutes, auto-resolved
CI failure investigation	15–60 min per failure	Automated patch with explanation
PR review prep	Manual summary writing	Auto-generated review summary
Rebase after upstream changes	Manual, error-prone	Handled automatically

Human-in-the-Loop, Not Human-in-Every-Loop

Origin's philosophy: humans should make high-judgment calls, not repetitive ones.

Routine tasks run autonomously: rebasing, dependency updates, boilerplate, minor fixes
Escalation is intelligent: pings only for architectural decisions, breaking changes, or high-risk merges
Notifications are contextual: full briefings, not just alerts
Approval gates are configurable: e.g., any PR touching the auth module requires human sign-off

The Graphite Acquisition Advantage

Graphite was built to solve the pain of stacked pull requests for human developers; Cursor's acquisition brings that directly into Origin:

Visual stack management of dependency chains
Automatic stack synchronization when lower PRs merge or update
Incremental reviews — reviewers see only the diff for each layer, not the cumulative diff
Agent-friendly architecture — aligns naturally with how agents build features in incremental steps

Joining the Waitlist

Sign up at cursor.com/origin with your email or existing Cursor account, and optionally fill out a survey about team size and use case (larger agent workloads are prioritized for early access). Early access includes the Origin web interface, Composer integration, the Graphite-powered stacked PR interface, limited-beta CI/conflict-resolution automation, and dedicated onboarding.

Feature	Waitlist Beta	Fall 2026 Full Launch
Repository hosting	Limited capacity	Full capacity
Stacked PR management	Available	Available
Automated conflict resolution	Beta quality	Production quality
CI auto-fix	Partial	Full
Enterprise SSO & permissions	Not yet	Available
Public repository support	Not yet	Available
GitHub migration tooling	Manual	Automated

Cursor Mobile iOS Beta and Remote Agent Management

Agents no longer live on your local machine — they run in isolated cloud VMs active 24/7, independent of your laptop. The mobile app lets you:

Spin up new agents by typing or speaking a prompt
Monitor active agents across multiple projects
Review progress snapshots without a full IDE
Approve or redirect agents at decision points
Pause or kill agents that go off track

Voice-to-Code Input

Typing detailed prompts on a phone is painful, so Cursor Mobile supports voice input and dictation tuned for technical vocabulary:

Scenario	Typing Prompt	Voice Prompt
Quick task delegation	Slow, error-prone	Fast, natural
Complex multi-step instructions	Hard to structure on mobile	Flows conversationally
Technical terminology	Autocorrect nightmares	Handles developer vocabulary
Iterating on a prompt	Requires careful editing	Just speak the change

Lock Screen Notifications

Built on iOS Live Activities, notifications surface only completions, blockers, and review requests — not every function written or lint check run. A typical day: assign tasks at standup, glance at updates between meetings, get a Live Activity ping at lunch that a PR is ready, review and approve on your commute, and end the day with features shipped without opening the IDE.

The Vision of an End-to-End Autonomous AI Software Factory

Cursor now controls all three core layers of the development lifecycle:

The Editor (Composer): where code is written and reasoned about, powered by the custom 1.5T model
The Review Cycle (Graphite): where PRs are stacked, reviewed, and merged, with AI-driven conflict resolution and CI fixes
The Hosting Layer (Origin): where code lives, branches, and deploys, built for thousands of parallel agents

The Data Flywheel

Every keystroke in Composer, every merge conflict resolved in Origin, every agent task completed via mobile feeds proprietary training signal back into the model — a feedback loop no third-party LLM provider gets.

Layer	Traditional Developer Stack	Cursor's Integrated Stack
Code Writing	VS Code + Copilot	Cursor Composer + Custom 1.5T Model
Version Control	GitHub / GitLab	Origin (Agentic Git Platform)
PR Review	Manual + Reviewers	Automated AI + Human-in-the-Loop
CI/CD	Jenkins / GitHub Actions	Automated CI Bug Fixing in Origin
Agent Management	N/A	Cursor Mobile (iOS)
Compute Backend	Local / Cloud VMs	SpaceX Colossus Infrastructure

What This Means for Software Teams

The developer role is shifting toward orchestration rather than implementation — reviewing architectural decisions, unblocking agents, and approving merges rather than writing every line. The skills that matter shift toward:

Clear prompt engineering and requirement articulation
Architectural thinking — spotting when a solution is technically correct but structurally wrong
Systems-level review across the whole codebase
Judgment calls on when "good enough" really is

This creates pressure on team size economics: a small team running the full Cursor stack could ship at the velocity of a team several times its size, shifting the value of headcount toward people who define what needs to be built and verify it was built correctly.

Origin also puts direct competitive pressure on GitHub and GitLab, betting that patching human-centric infrastructure with AI features isn't the same as rebuilding it for an agent-first world.

What Teams Should Consider

Workflow lock-in is real — workflows, agent history, and PR context all live inside Cursor's platform
Skill investment matters — writing clear specs and critically reviewing AI-generated code is becoming as important as traditional coding skills
The waitlist window is short — Origin is waitlist-only through Fall 2026

Conclusion

Cursor has made a bold leap from AI code editor to full developer ecosystem powered by its own AI. The custom 1.5-trillion-parameter model, trained on over 100,000 GPUs, brings serious firepower to code reasoning and editing. Origin takes on GitHub with agentic-first design built for thousands of parallel AI commits, automated PR reviews, and smart merge conflict resolution. The iOS mobile beta lets developers manage cloud-based coding agents from their phone, hands-free if needed.

Backed by SpaceX's compute infrastructure, Cursor is building the first end-to-end AI software factory — owning the editor, the review layer, and the hosting platform.