Three slots, one queue, no locks.

generate_asset is LLM-bound, not CPU-bound.

A single package produces 10 generate_asset jobs (one per asset type — title set, description, chapters, tags, linkedin post, x post, x thread, article brief, newsletter summary, short clip plan). Each is a single LLM call. None of them touch any shared mutable state. Serializing them through a single worker slot was leaving ~65 s on the table per package.

SKIP LOCKED is the only mutex.

No new tables, no semaphores, no in-process locks. The Postgres queue already does the right thing — we just spawn N independent claim loops in the same process and let them race.

The architectural picture

Why SKIP LOCKED is enough

When three slots call claim() at the same instant, each opens its own transaction and runs the identical SELECT … FOR UPDATE SKIP LOCKED LIMIT 1. The first to reach a row locks it; the others skip past the locked row and grab the next unlocked one. No slot ever blocks, and no two slots ever return the same job.

The timeline difference, visualised

The code change

// workers/runner.ts — abridged

async function main() {
  const { kinds, concurrency, … } = parseArgs(process.argv.slice(2));

  // One stale-lock reclaim timer for the whole process
  setInterval(reclaim, 30_000);

  // Spawn N independent slots — SKIP LOCKED handles mutex
  await Promise.all(
    Array.from({ length: concurrency }, (_, slot) =>
      runSlot({ slot, lockedBy, kinds, … })
    )
  );
}

async function runSlot({ slot, kinds, … }) {
  while (!shuttingDown) {
    const job = await claim(kinds, lockedBy);   // SKIP LOCKED inside
    if (!job) { await sleep(idleMs); continue; }
    try {
      await HANDLERS[job.kind](job);
      await complete(job.id);
    } catch (err) { … }
  }
}

Every handler audited for idempotency.

With N parallel slots, the same handler kind can run concurrently. We checked each handler against the "could two of these stomp on each other?" question.

How to raise or lower the slot count.

Default

3 slots. Set in scripts/dev.sh:

WORKER_CONCURRENCY=3  # env var, picked up by --concurrency default

Bump it (more parallelism)

If you see lots of generate_asset jobs queued in the Jobs page:

# env at process start
WORKER_CONCURRENCY=6 pnpm dev:all

# OR via flag
pnpm exec tsx workers/runner.ts --kinds … --concurrency 6

Drop it (hitting provider rate limits)

If you see 429 too many requests in the dispatch log or your provider's dashboard:

WORKER_CONCURRENCY=1  # back to serial — no parallelism

OCR fps is now profile-aware.

The standard profile drops OCR from 1 fps → 0.5 fps. Premium stays at 1 fps. Halves the OCR subprocess wall on standard content with no measurable quality loss on overlay/lower-third detection. Today this saves time only on its own (since VLM is currently the bottleneck of the Visual phase), but it pairs perfectly with any future VLM-speed work.

// workers/kinds/analyze_visual.ts

const OCR_FPS_BY_PROFILE: Record<string, number> = {
  standard_audio_visual: 0.5,
  premium_multimodal: 1,
};

const ocrFps = OCR_FPS_BY_PROFILE[profile] ?? 0.5;
const ocrFrames = await sampleFrames({
  inputPath: videoPath,
  outputDir: ocrFramesDir,
  fps: ocrFps,
});

Where we are now.

Throughput, drawn to scale

Bars are pipeline wall time on a typical 8-minute video, log-spaced so the 25-min baseline and the 2-min current state both stay legible. Lower is better.