01
The typed idea
109 words, typed in. This is the only input Murmur got.
a rendering platform ONLY for video editing. Figure out the fastest way to render videos and let claude and codex plug into it, and it renders any type of video and returns a download link with the video. AS FAST AS POSSIBLE. I have a theory that in one year most video editing software will be bloat. And that the best editor will be claude code and codex editing the files headless. These videos will need to be rendered somehow. The better the models get the more aspirational people will get with their videos. Creating an 20 minute video that renders in 8k on blender at the highest quality...
02
Competitor map
Live web search for who's already building nearby, with a source link for every competitor.
- 9 competitors
- 5 table stakes
- 4 ways to differentiate
Market summary
The closest operating competitors are Valmera (hosted MCP for Claude Code and Codex, cloud previews and MP4 export), Shotstack (cloud video editing API usable by agents, per-minute pricing) and Eddie AI (agent-callable edit tools, cloud MP4 render returning a download link, capped at 1080p/4K and 60 minutes). Remotion covers agent-driven creation and distributed Lambda rendering but is a framework to self-host. Render Perk, Super Renders Farm and ParalonCloud cover cloud Blender rendering, but agent plug-in access is not stated in the sources reviewed. scythe and video-agent-runtime cover headless, LLM-driven editing with ffmpeg rendering. The phrase searches run were not complete, so no claim is made that the job is unserved.
Competitors 9
Valmera
valmera.ioHosted video editing MCP server that gives Claude, ChatGPT, Cursor, VS Code, Codex and other MCP clients a video editor, with previews and MP4 export.
Pricingcredit-based monthly subscription tiers
+2 strengths /−1 weaknesses
Strengths
- Explicit Claude Code and Codex support through MCP, skills and plugins
- Cloud previews, project history and reversible edits per the pricing page
Weaknesses
- Credits meter AI and processing work; longer footage and more revisions use more credits
Shotstack
shotstack.ioCloud video editing API that turns data into finished video, driven by code, workflows or AI agents.
Pricingpay per minute of video (pay-as-you-go and monthly plans)
+2 strengths /−1 weaknesses
Strengths
- Hosted render API aimed at programmatic and agent use
- Published per-minute pricing with volume tiers
Weaknesses
- Pay-as-you-go and Starter plans cap at 1080p; 4K on Pro and above (8K not stated)
Eddie AI
heyeddie.aiAI video editor for pros that works on web, desktop and in Claude and ChatGPT, with every edit exposed as a tool for agents such as Codex and Cursor.
Pricingpay-as-you-go credit packs, no subscription
+2 strengths /−2 weaknesses
Strengths
- Cloud render returns a download link, typically a minute or two per its help page
- Credit packs never expire and include all features
Weaknesses
- Cloud render is capped at 1080p/4K and 60 minutes
- For desktop imports, a cloud MP4 is no sharper than the Proxy Resolution working copy
Remotion
remotion.devReact-based framework for programmatic video creation, usable agentically, interactively or in bulk.
Pricingfree for individuals and small companies; license fee for bigger companies
+2 strengths /−2 weaknesses
Strengths
- Docs state Remotion Lambda is the fastest option because of distributed rendering
- Docs say highest-volume customers use Lambda
Weaknesses
- Docs say Lambda compute is more expensive than other options
- Docs say Vercel Sandbox, Cloud Run and custom servers render on one machine, without distributed rendering
Render Perk
renderperk.studioDistributed GPU rendering platform focused on Blender, splitting frames across many nodes.
Pricingpay per frame / per second
+1 strengths /−0 weaknesses
Strengths
- Homepage cites a 3840×2160, 100-frame showcase rendered in about 15 minutes
Weaknesses
ParalonCloud
paraloncloud.comDecentralized GPU cloud with a Blender cloud rendering offering in beta.
Pricingusage-based (per GPU-minute); render pricing not yet announced
+1 strengths /−2 weaknesses
Strengths
- Render page lists 8K max resolution
Weaknesses
- Render page lists 500 frames per job and one frame per job
- Render product is described as beta with other renderers coming soon
Super Renders Farm
superrendersfarm.comFully managed cloud render farm for 3D and VFX artists: upload a scene, render, download frames.
Pricingpay per use, no subscription, billed per second
+2 strengths /−0 weaknesses
Strengths
- Free transfer in and out
- Render credits never expire
Weaknesses
scythe
github.comOpen-source headless video editing engine that compiles a JSON cutlist into MP4s with ffmpeg.
Pricingfree, open source (MIT License)
+1 strengths /−0 weaknesses
Strengths
- Headless, LLM-authored edits
Weaknesses
video-agent-runtime
github.comAgent-native headless video editing runtime for Claude Code, Codex or any MCP client, with FFmpeg rendering.
Pricingfree, open source (MIT License)
+1 strengths /−0 weaknesses
Strengths
- Names Claude Code and Codex as target clients
Weaknesses
Table stakes 5
- Cloud-hosted rendering that does not depend on the user's local hardware
- MP4 output delivered to the user
- An agent-callable interface (MCP, API or CLI)
- Usage-based or credit-based published pricing
- Progress or preview visibility before the final render
Where to differentiate 4
- A render-only service that accepts projects authored by Claude Code or Codex across engines (Blender and ffmpeg-style projects), not tied to a built-in editor; not established from the sources reviewed
- Explicit support for very high resolutions (8K) and long (20-minute) renders returned as a download link; the reviewed editing products state 4K or 1080p limits
- Distributed chunked rendering as a hosted agent endpoint, since Remotion's distributed rendering is self-hosted infrastructure
- Speed as the headline metric with published render-time benchmarks; not established from the sources reviewed
A headless, render-only cloud for AI coding agents: Claude Code and Codex hand over a finished project and get back a fast, high-quality render as a download link, without a bundled editor or local rendering.
03
Product requirements document
Every feature carries a rationale tied back to the memo or the research.
- 7 must
- 5 should
- 4 could
- 7 won't
- 6 success metrics
One-liner
A render-only cloud service with an MCP and HTTP API that lets Claude Code and Codex submit any video project and get back a fast render as a download link, with no bundled editor and 8K/20-minute Blender renders as the aspiration, where Valmera, Eddie AI and Shotstack cap resolution or length.
Problem
Founder's thesis is that most video editing software becomes bloat within a year and the best editor will be Claude Code or Codex editing files headless, but those videos still have to be rendered somewhere, and ambition (such as a 20-minute 8K Blender video at highest quality) grows as models improve. Today an agent's output is rendered on local hardware or pushed through an editor-bundled service. Research shows the gap: Valmera, Eddie AI and Shotstack pair agent access with a built-in editor and cap output (Eddie AI at 1080p/4K and 60 minutes, Shotstack's lower tiers at 1080p with 8K not stated); Render Perk, Super Renders Farm and ParalonCloud render Blender in the cloud but state no agent plug-in access; Remotion's distributed rendering is infrastructure the user must self-host. Nobody reviewed is a render-only, agent-callable service built for speed at very high resolution and long duration, though the research does not prove the job is unserved.
Target user
Developers and creators who author video projects with Claude Code or Codex running headless and need a hosted cloud service to render those projects into finished files.
Features
Open a card for the full description and rationale
Must have 7
Claude Code and Codex can submit a render job, poll status and fetch the result through an MCP endpoint backed by a plain HTTP API.
WhyFounder: Claude and Codex must be able to plug into the platform; Research: an agent-callable interface is table stakes.
An agent uploads a finished project (assets plus project file) with render settings (resolution, frame range, output format) and starts a render.
WhyFounder: it renders videos that Claude and Codex have edited as files headless.
The first version renders Blender projects and ffmpeg-based edit projects, such as a JSON cutlist compiled to a filtergraph.
WhyRecommended: the smallest working form of the founder's 'renders any type of video', chosen because the founder's example is Blender and headless agent edits commonly compile to ffmpeg.
Split each job into frame ranges or chunks rendered in parallel across many GPU/CPU workers, then stitch them into one output file.
WhyFounder: find the fastest way to render, 'AS FAST AS POSSIBLE'; Research: Remotion docs say distributed chunked rendering is what makes it fastest.
On completion the job returns a download URL for the finished video file, retrievable by the agent.
WhyFounder: it 'returns a download link with the video'; Research: MP4 delivery is table stakes.
Each job exposes state and percent complete (frames or chunks done) via API and MCP so an agent can wait or report.
WhyResearch: progress visibility is table stakes among competitors.
Each user gets an API key for the agent and a starter render allowance, so the first version works with no payment flow.
WhyRecommended: jobs need an identity and a cost cap, and starter credits avoid building billing first.
Should have 5
Support 8K output and renders up to 20 minutes, with the Blender 8K/20-minute video as the benchmark job.
WhyFounder: names a 20-minute 8K highest-quality Blender render as the aspirational use; Research: Eddie AI caps at 1080p/4K and 60 minutes, so 8K is open space.
Publish wall-clock render times for fixed benchmark scenes against a single-machine render.
WhyResearch: speed as the headline metric with published benchmarks is a stated differentiation opportunity.
Bill by compute-second with a published rate card, instead of Valmera-style credits that meter AI work.
WhyResearch: usage-based published pricing is table stakes, and Valmera's credit metering is a weakness.
Let the agent request a single full-quality frame or short low-res sample before committing to a full render.
WhyResearch: Valmera offers previews the assistant can watch, so an agent that can check output before an expensive 8K render is competitive.
Offer the distributed render as a ready-to-use hosted MCP endpoint, with no self-hosting or infrastructure setup.
WhyResearch: Remotion's distributed rendering is self-hosted infrastructure, so a hosted version is the angle.
Could have 4
Add other project types, such as Remotion compositions, After Effects and Cinema 4D projects, beyond Blender and ffmpeg.
WhyFounder: 'renders any type of video' is the long-term scope; Research: engine-agnostic acceptance of agent-authored projects is a differentiation opportunity.
Return an estimated cost and completion time before the job starts, so the agent can decide.
WhyRecommended: render-farm competitors offer price calculators, and an agent needs it to budget 8K jobs.
Call a user-supplied URL when a job finishes or fails.
WhyRecommended: avoids polling during long renders.
Support chunked, resumable uploads for multi-gigabyte projects and simulation caches.
WhyResearch: Render Perk lists large file and simulation cache upload as a feature.
Won't have 7
No visual editor, timeline or project canvas.
WhyFounder: the platform is for rendering ONLY, and editing is done headless by the agents.
No transcript-based cuts, filler removal, captions, b-roll or reframing done by the platform.
WhyResearch: Valmera and Eddie AI compete on these, and the founder wants the models, not the platform, to edit.
No project-format exports for traditional editors.
WhyResearch: Eddie AI offers these, but the founder expects agents to replace traditional editors.
No Studio SDK or white-labelled editor for resale.
WhyResearch: Shotstack offers this, and it conflicts with the render-only scope.
No shared workspaces, comments, roles or admin console.
WhyResearch: Flixier's collaboration targets human editors, not agents.
No native clients or desktop upload utility; everything goes through the API and MCP.
WhyResearch: Render Perk ships a Transfer Tool, but this product is used by agents through an API.
No generation of images, video, voice or music during render.
WhyResearch: Shotstack bundles generation, which is outside render-only scope.
Success metrics 6
Speedup of the benchmark Blender scene (1 minute, 4K) versus a single-GPU render of the same scene, measured by wall-clock time
≥20x faster within 60 days of launch [assumption]
Completion of the 20-minute 8K Blender benchmark job as an end-to-end download link with matching resolution, duration and frame count
Delivered successfully at least once within 120 days of launch [assumption]
Share of benchmark renders that a qualified 3D artist rates free of visible seams, dropped frames or chunk-boundary artifacts versus a single-machine reference
≥95% of benchmark renders within 90 days [assumption]
Job success rate: submitted jobs that return a playable file via download link without manual intervention
≥95% of jobs in the first 60 days [assumption]
Share of first-time Claude Code or Codex sessions that submit a job and receive a download link with no human help, measured from API logs
≥70% of the first 30 external users within 30 days of their onboarding [assumption]
Gross margin on rendering (billed amount minus GPU/CPU compute cost per output minute)
≥40% across all billed renders in the first 90 days [assumption]
Non-goals 4
- Not a video editor: no timeline, UI or editing logic; agents author the project.
- Not a general-purpose GPU cloud or 3D render farm for human artists.
- Not an AI video or media generation service.
- Not a collaboration, publishing or distribution platform; output is a download link.
Risks 4
- GPU cost of 8K, 20-minute renders may exceed what users pay, and speed through massive parallelism pushes cost further, which hurts margin.
- Stitching chunks into one file without seams, colour shifts or audio drift is technically hard, as are very large uploads and multi-gigabyte outputs.
- Valmera, Eddie AI and Shotstack could lift their caps or add render-only modes, and Remotion could host its distributed rendering, narrowing the gap.
- The founder's thesis that editing software becomes bloat and agents become the editors is an unproven bet that demand depends on.
Open questions 9
- The founder gave no product name — founder to name it.
- 'Renders any type of video': which engines come first? Recommended: Blender plus ffmpeg (founder's example plus the common headless agent pipeline); founder to confirm.
- 'Claude and codex plug into it': which integration surface? Recommended: MCP server plus HTTP API (matches how competitors expose agent access); founder to confirm.
- Who acts: the agent or user authors the project and the product only renders it — founder to confirm.
- What does 'AS FAST AS POSSIBLE' mean as a number (e.g. 20-minute 8K done within what wall-clock time)? Founder to set the target.
- Own GPU fleet or rented distributed GPU capacity for the first version? Founder to decide.
- Is the 8K/20-minute Blender render a launch requirement or a later benchmark? Recommended: should_have benchmark after the core flow works; founder to confirm.
- Pricing: free starter credits then pay-per-second, or subscription tiers? Founder to decide; any paid-plan choice does not change feature priority.
- Which output formats and codecs, and how long are download links kept for very large 8K files?
Want this structure for your own PRD? Start from the free product requirements document template, with a guide to each section.
04
Brand kit
Name notes, tagline, values, palette, type and a logo direction, written from the PRD.
- 4 core colors
- 5 brand values
- Bricolage Grotesque headings
Hand it the project. Get back the film.
- Primary#E4572E
- Secondary#1F2A30
- Accent#F2B134
- Neutral#F4F1EC
Bricolage Grotesque / DM Sans / JetBrains Mono5 brand values
Brand values 5
- Speed with craft: parallel power in service of a clean, seamless final file
- Single purpose: we render, and we leave the editing to you and your agent
- Agent-native: built to be called by software as easily as by people
- Transparent: published benchmarks, published rates, honest limits
- Quiet reliability: jobs finish, links work, outputs match what was asked
Semantic colors
- error #C93C3C
- success #2E9E6B
- warning #E0A100
Name notes
- The founder has not named the product, so this brand name is only a placeholder and should not be treated as final. The founder needs to choose a real name before any identity work is locked in.
- Alternative directions to consider: Kiln (a place where finished work is fired and hardened), Reelhouse (a facility that only renders), Lathe Render (precise, single-purpose crafting).
- No trademark or domain check has been done for the placeholder or for any suggested alternative, so each needs its own search before use.
Logo direction
- Form
- Lockup of a bold single-color symbol beside a lowercase wordmark, with a standalone symbol variant for API docs and avatars
- Style
- Confident, industrial-warm wordmark with a compact geometric symbol; high contrast and legible at favicon size
- Symbol concept
- A film frame split into parallel vertical slices that converge into one continuous bar, representing distributed chunks stitched into a single seamless render
- Iconography
- Monoline icons on a 24px grid with 2px strokes, slightly rounded terminals, and one small filled accent shape per icon in amber. Subjects are drawn from rendering and delivery: frames, chunks, stacked slices, progress bars, download arrows, and terminal prompts. Everything is geometric and functional, with no decorative flourishes.
05
Tech design
The engineering brief: architecture, data flow, data models, schema, stack and the first tasks.
- 12 components
- 16 data models
- 15 first tasks
Overview
A render-only cloud service. An agent (Claude Code or Codex) uploads a finished Blender or ffmpeg project through an MCP endpoint or HTTP API, submits a render job, polls progress, and receives a download link. The product lives or dies on one component: the distributed render pipeline, which splits a job into frame-exact chunks, renders them in parallel on GPU/CPU workers, stitches them into one file with no seams, colour shifts or audio drift, and proves that with automated checks before it reports success. The control plane (API, MCP, auth, dashboard) is thin and stateless. Rendering runs on a separate long-running orchestrator and containerised workers because render jobs far exceed serverless time limits. Nothing in the product calls an LLM: the agents are API clients, and all planning, cost, validation and status logic is deterministic.
Data flow
1) The agent calls create-project and receives presigned upload URLs; it uploads files directly to object storage and calls finalize. 2) Intake verifies hashes, detects the engine, validates and marks the project ready. 3) The agent submits a job with an idempotency key, settings and an optional cost cap; the gateway checks entitlements, reserves credits in the ledger and inserts the job (a retry with the same key returns the same job). 4) The orchestrator plans: probe frames, chunk sizing, chunk rows. 5) Workers lease chunks, render and encode segments, and upload them with attempt-fenced keys; the orchestrator verifies the frame count and hash and records compute seconds in usage_records. 6) When all chunks are done, a stitch task builds the file, then the validator checks it. 7) On pass, job_outputs is written, credits are settled and the job is succeeded. On failure, unused reserve is released and the failure code is stored. 8) The agent polls status (state, chunks and frames done) and calls get-download-link, which returns a fresh presigned URL for the output while retention has not expired.
Tech stack 7
- frontend
- Next.js (App Router) for docs and a small key, credits and jobs dashboard.
- backend
- Control plane: Next.js route handlers on Vercel for the HTTP API and MCP endpoint, as short stateless requests. Non-default: a separate long-running orchestrator service (containerised TypeScript) plus worker containers running Blender and ffmpeg, because renders run far longer than serverless function limits and need GPU access. Workers reach only the orchestrator, never the database.
- database
- Supabase Postgres, also used as the job queue via row leasing.
- auth
- Supabase Auth for dashboard sign-in. Non-default: self-issued API keys for agents, stored hashed, shown once, sent as a bearer credential to HTTP and MCP.
- llm
- Not required. The platform only renders projects that agents have already authored; Claude Code and Codex are API clients, not components. Chunk planning, cost, validation, status text and benchmark claims are all deterministic code and templates.
- infra
- Vercel for control plane and dashboard. Non-default: S3-compatible object storage with presigned multipart upload and download, so multi-gigabyte files bypass serverless body limits; pick a provider with low egress cost because 8K outputs are large [assumption]. Non-default: GPU/CPU capacity behind a WorkerProvider interface, with own fleet versus rented distributed capacity left as a founder decision; default is rented capacity [assumption]. Orchestrator runs on a container host. Third parties that receive user project files and outputs: the object storage provider, the GPU capacity provider, Supabase and Vercel (metadata only).
- devtools
- TypeScript, GitHub Actions, containerised worker images, and a golden-scene test harness (frame-numbered, colour-chart and tone scenes) run in CI.
Components 12
Distributed Render Pipeline (planner, chunk executor, stitcher, validator) - CORE
Core job: turn one project plus render settings into one correct video file as fast as possible. INPUTS: a verified project (Blender .blend plus assets, or an ffmpeg JSON cutlist plus assets), settings (width, height, fps as a rational, inclusive frame range, container, codec, quality), a budget cap, and the user's entitlements. OUTPUT: one video file with exactly the requested resolution, frame count, duration and colour tags, plus a validation report. APPROACH: (1) PLAN: render a few probe frames to estimate per-frame time, then split the inclusive frame range into contiguous, non-overlapping chunks. Chunk size is chosen so a lost chunk is cheap to retry but task overhead stays small. The chunk count is capped by the user's max parallel workers and the budget. Planning is deterministic and stored in render_jobs.plan. For ffmpeg cutlists, boundaries snap to cut points so no transition or filter spans a boundary; if one does, the boundary moves. (2) EXECUTE: each chunk is leased by a worker, rendered to frames (Blender) or filtered (ffmpeg), and immediately encoded on that worker into a segment using the final codec with identical pinned parameters, a closed GOP, a keyframe at the chunk start, and explicitly pinned colour primaries, transfer, range, pixel format and timebase. Audio is rendered or mixed once as a single track, never per chunk. (3) STITCH: a stitch task concatenates segments by stream copy in chunk order and muxes the single audio track. The fallback if stream-copy stitching proves unreliable is lossless intermediates followed by one final encode; the default is [assumption]. (4) VALIDATE before success: each frame index is covered exactly once (a manifest check); the output's frame count, resolution, fps, duration and colour tags match the request; the audio/video duration delta is within a tolerance [assumption]; timestamps are monotonic across every boundary; frames either side of each boundary are decoded and compared against expectations. A job that fails validation is marked failed and never returns a link. NEVER VIOLATE: no dropped or duplicated frame at a boundary; no mixed GPU classes inside one job, because noise or denoise differences would show as seams [assumption]; no result from a stale or superseded attempt (every upload is fenced by attempt number); no spend beyond the budget cap; no untrusted project code with network access or secrets. Blender projects with simulations or particles are rejected unless caches are baked, since a chunk starting mid-timeline cannot reproduce simulation state.
Agent API Gateway (HTTP API plus MCP endpoint)
Exposes the same operations over a plain HTTP API and a hosted MCP endpoint: create project, get upload URLs, finalize upload, submit job (with idempotency key), request preview, get status and progress, cancel, get download link, check credits. Stateless short requests only (no held-open streams): agents poll status. This is the hosted agent endpoint for distributed rendering. Authenticates the API key, enforces entitlements and rate limits, and returns plain-language status text built from templates filled with job state and counts.
Project Intake and Validation
Issues presigned upload URLs so large files go straight to object storage, never through serverless request bodies. On finalize it verifies every file's hash and size, detects engine and engine version, checks the entry file and limits (resolution, duration, engines allowed by entitlement), rejects unbakeable or unsafe content (unbaked simulations, absolute paths, remote URLs or protocols in cutlists), and writes a manifest. Embedded script auto-execution in .blend files is disabled at render time.
Job Orchestrator and Scheduler
Long-running service (not serverless) that moves jobs through queued, planning, rendering, stitching, validating, succeeded/failed/cancelled. Creates chunk rows, hands out chunk leases with expiry and heartbeats, reclaims expired leases, retries with a bounded attempt count, enforces budget cap and cancellation, triggers stitching when all chunks are verified, and writes job_events. Uses Postgres row leasing (SKIP LOCKED) as the queue. Workers talk only to the orchestrator, never the database.
Worker Fleet (GPU/CPU workers)
Sandboxed containers with Blender and ffmpeg, no outbound network except presigned storage URLs, no platform secrets. Pull a chunk, download the assets, render, encode the segment, upload with an attempt-fenced key, report frame counts, hash and compute seconds. Capacity comes through a WorkerProvider interface so own GPU hardware or rented distributed GPU capacity can be swapped without touching the pipeline.
Object Storage and Delivery
Stores project files, chunk segments and final outputs in S3-compatible storage. The download link returned to the agent is a stable platform URL that mints a fresh short-lived presigned URL on request, so file retention (job_outputs.expires_at, per entitlement) is separate from link expiry. Lifecycle cleanup removes chunk intermediates after a job ends and outputs after retention.
Auth, Entitlements and Starter Credits
Supabase Auth signs humans in to the dashboard to create and revoke API keys. Keys are shown once and stored only as a hash. Each user gets an entitlements row (max resolution, duration, parallel workers, retention, allowed engines) and a starter credit grant in the ledger so the first version needs no payment flow.
Metering and Billing (behind an interface)
Records compute seconds per chunk attempt, prices them from a published rate card, and writes reserve/settle/release entries to an idempotent credit ledger. Payment collection is a BillingProvider interface so the pricing decision (free credits then pay-per-second, or subscriptions) can change without schema or pipeline changes. External payment events are deduplicated by provider event id.
Preview Renderer
Runs a preview job kind: one full-quality frame or a short low-resolution sample through the same worker path, so the agent can check output before committing to an expensive 8K render. Billed like any job and doubles as the probe for chunk sizing.
High-Resolution Path (8K, 20-minute)
Entitlement-gated limits plus planner settings for very large jobs: smaller chunk targets for heavy frames, GPU classes with enough memory, codec choices that support 8K, and per-chunk storage that never holds full-length raw frame sequences. The 20-minute 8K Blender benchmark is the acceptance job.
Benchmark Harness
Runs fixed benchmark scenes through the production pipeline and a single-machine baseline, stores wall-clock times, and computes speedup deterministically. Published numbers and any speed claims are filled from these records by template.
Dashboard and Docs (minimal)
Next.js pages for sign-in, API key management, credits balance, job list with progress, MCP setup instructions, rate card and published benchmarks. No editor or timeline.
Data models 16
Open a model for its fields
profiles4 fields
- iduuid
- emailtext
- display_nametext
- created_attimestamptz
- has one entitlements
- has many api_keys, projects, render_jobs, credit_ledger
entitlements10 fields
- iduuid
- user_iduuid
- max_widthint
- max_heightint
- max_duration_secondsint
- max_parallel_workersint
- output_retention_hoursint
- allowed_enginestext[]
- created_attimestamptz
- updated_attimestamptz
- belongs to profiles
api_keys8 fields
- iduuid
- user_iduuid
- nametext
- key_prefixtext
- key_hashtext
- last_used_attimestamptz
- revoked_attimestamptz
- created_attimestamptz
- belongs to profiles
rate_cards7 fields
- iduuid
- nametext
- resource_classtext
- unit_price_microsbigint
- currencytext
- effective_fromtimestamptz
- publishedboolean
- referenced by usage_records
projects11 fields
- iduuid
- user_iduuid
- enginetext
- engine_versiontext
- entry_filetext
- statustext
- rejection_reasontext
- total_bytesbigint
- manifestjsonb
- expires_attimestamptz
- created_attimestamptz
- belongs to profiles
- has many project_files
- has many render_jobs
project_files8 fields
- iduuid
- project_iduuid
- pathtext
- storage_keytext
- size_bytesbigint
- sha256text
- upload_statustext
- created_attimestamptz
- belongs to projects
render_jobs30 fields
- iduuid
- user_iduuid
- project_iduuid
- kindtext
- enginetext
- statustext
- idempotency_keytext
- widthint
- heightint
- fps_numint
- fps_denint
- frame_startint
- frame_endint
- containertext
- video_codectext
- audio_codectext
- quality_settingsjsonb
- preview_specjsonb
- max_cost_microsbigint
- gpu_classtext
- planjsonb
- total_chunksint
- chunks_doneint
- frames_doneint
- failure_codetext
- failure_messagetext
- cancel_requestedboolean
- created_attimestamptz
- started_attimestamptz
- finished_attimestamptz
- belongs to profiles and projects
- has many render_chunks, job_events, usage_records
- has one job_outputs
render_chunks16 fields
- iduuid
- job_iduuid
- chunk_kindtext
- chunk_indexint
- frame_startint
- frame_endint
- statustext
- attempt_countint
- leased_byuuid
- lease_expires_attimestamptz
- output_keytext
- output_sha256text
- frames_renderedint
- frame_count_verifiedboolean
- created_attimestamptz
- finished_attimestamptz
- belongs to render_jobs
- leased by workers
- has many chunk_attempts
workers7 fields
- iduuid
- providertext
- provider_instance_idtext
- gpu_classtext
- statustext
- last_heartbeat_attimestamptz
- created_attimestamptz
- has many render_chunks and chunk_attempts
chunk_attempts9 fields
- iduuid
- chunk_iduuid
- attempt_noint
- worker_iduuid
- outcometext
- errortext
- started_attimestamptz
- ended_attimestamptz
- compute_secondsnumeric
- belongs to render_chunks and workers
- has one usage_records
job_outputs17 fields
- iduuid
- job_iduuid
- storage_keytext
- size_bytesbigint
- widthint
- heightint
- fps_numint
- fps_denint
- frame_countint
- duration_msbigint
- video_codectext
- audio_codectext
- sha256text
- validation_passedboolean
- validation_reportjsonb
- expires_attimestamptz
- deleted_attimestamptz
- belongs to render_jobs
job_events5 fields
- idbigint
- job_iduuid
- event_typetext
- payloadjsonb
- created_attimestamptz
- belongs to render_jobs
usage_records9 fields
- iduuid
- user_iduuid
- job_iduuid
- chunk_attempt_iduuid
- resource_classtext
- secondsnumeric
- rate_card_iduuid
- amount_microsbigint
- created_attimestamptz
- belongs to render_jobs, chunk_attempts, rate_cards
credit_ledger8 fields
- iduuid
- user_iduuid
- entry_typetext
- amount_microsbigint
- job_iduuid
- idempotency_keytext
- notetext
- created_attimestamptz
- belongs to profiles and optionally render_jobs
billing_events8 fields
- iduuid
- providertext
- provider_event_idtext
- event_typetext
- user_iduuid
- payloadjsonb
- processed_attimestamptz
- created_attimestamptz
- optionally belongs to profiles
benchmark_runs14 fields
- iduuid
- scene_nametext
- enginetext
- widthint
- heightint
- duration_secondsnumeric
- frame_countint
- job_iduuid
- worker_countint
- distributed_wall_clock_msbigint
- baseline_wall_clock_msbigint
- baseline_hardwaretext
- publishedboolean
- run_attimestamptz
- references render_jobs
SQL schema (excerpt)
View the SQL16 lines
CREATE TABLE profiles (id uuid PRIMARY KEY REFERENCES auth.users(id) ON DELETE CASCADE, email text NOT NULL, display_name text, created_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE entitlements (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid NOT NULL UNIQUE REFERENCES profiles(id) ON DELETE CASCADE, max_width int, max_height int, max_duration_seconds int, max_parallel_workers int, output_retention_hours int, allowed_engines text[] NOT NULL DEFAULT '{}', created_at timestamptz NOT NULL DEFAULT now(), updated_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE api_keys (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid NOT NULL REFERENCES profiles(id) ON DELETE CASCADE, name text NOT NULL, key_prefix text NOT NULL, key_hash text NOT NULL UNIQUE, last_used_at timestamptz, revoked_at timestamptz, created_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE rate_cards (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), name text NOT NULL, resource_class text NOT NULL, unit_price_micros bigint NOT NULL, currency text NOT NULL, effective_from timestamptz NOT NULL, published boolean NOT NULL DEFAULT false, UNIQUE (resource_class, effective_from));
CREATE TABLE projects (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid NOT NULL REFERENCES profiles(id) ON DELETE CASCADE, engine text NOT NULL CHECK (engine IN ('blender','ffmpeg')), engine_version text, entry_file text, status text NOT NULL DEFAULT 'uploading' CHECK (status IN ('uploading','uploaded','validating','ready','rejected')), rejection_reason text, total_bytes bigint, manifest jsonb, expires_at timestamptz, created_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE project_files (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), project_id uuid NOT NULL REFERENCES projects(id) ON DELETE CASCADE, path text NOT NULL, storage_key text NOT NULL, size_bytes bigint, sha256 text, upload_status text NOT NULL DEFAULT 'pending' CHECK (upload_status IN ('pending','uploaded','verified')), created_at timestamptz NOT NULL DEFAULT now(), UNIQUE (project_id, path));
CREATE TABLE render_jobs (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid NOT NULL REFERENCES profiles(id), project_id uuid NOT NULL REFERENCES projects(id), kind text NOT NULL DEFAULT 'full' CHECK (kind IN ('full','preview_frame','preview_clip')), engine text NOT NULL CHECK (engine IN ('blender','ffmpeg')), status text NOT NULL DEFAULT 'queued' CHECK (status IN ('queued','planning','rendering','stitching','validating','succeeded','failed','cancelled')), idempotency_key text NOT NULL, width int NOT NULL, height int NOT NULL, fps_num int NOT NULL, fps_den int NOT NULL DEFAULT 1, frame_start int NOT NULL, frame_end int NOT NULL, container text NOT NULL, video_codec text NOT NULL, audio_codec text, quality_settings jsonb, preview_spec jsonb, max_cost_micros bigint, gpu_class text, plan jsonb, total_chunks int, chunks_done int NOT NULL DEFAULT 0, frames_done int NOT NULL DEFAULT 0, failure_code text, failure_message text, cancel_requested boolean NOT NULL DEFAULT false, created_at timestamptz NOT NULL DEFAULT now(), started_at timestamptz, finished_at timestamptz, UNIQUE (user_id, idempotency_key), CHECK (frame_end >= frame_start));
CREATE TABLE workers (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), provider text NOT NULL, provider_instance_id text NOT NULL, gpu_class text, status text NOT NULL DEFAULT 'starting' CHECK (status IN ('starting','idle','busy','draining','lost')), last_heartbeat_at timestamptz, created_at timestamptz NOT NULL DEFAULT now(), UNIQUE (provider, provider_instance_id));
CREATE TABLE render_chunks (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), job_id uuid NOT NULL REFERENCES render_jobs(id) ON DELETE CASCADE, chunk_kind text NOT NULL DEFAULT 'video' CHECK (chunk_kind IN ('video','audio','stitch')), chunk_index int NOT NULL, frame_start int, frame_end int, status text NOT NULL DEFAULT 'pending' CHECK (status IN ('pending','leased','rendering','encoding','done','failed')), attempt_count int NOT NULL DEFAULT 0, leased_by uuid REFERENCES workers(id), lease_expires_at timestamptz, output_key text, output_sha256 text, frames_rendered int, frame_count_verified boolean NOT NULL DEFAULT false, created_at timestamptz NOT NULL DEFAULT now(), finished_at timestamptz, UNIQUE (job_id, chunk_kind, chunk_index));
CREATE TABLE chunk_attempts (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), chunk_id uuid NOT NULL REFERENCES render_chunks(id) ON DELETE CASCADE, attempt_no int NOT NULL, worker_id uuid REFERENCES workers(id), outcome text NOT NULL DEFAULT 'running' CHECK (outcome IN ('running','succeeded','failed','lease_expired','cancelled')), error text, started_at timestamptz NOT NULL DEFAULT now(), ended_at timestamptz, compute_seconds numeric(12,3), UNIQUE (chunk_id, attempt_no));
CREATE TABLE job_outputs (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), job_id uuid NOT NULL UNIQUE REFERENCES render_jobs(id) ON DELETE CASCADE, storage_key text NOT NULL, size_bytes bigint, width int, height int, fps_num int, fps_den int, frame_count int, duration_ms bigint, video_codec text, audio_codec text, sha256 text, validation_passed boolean NOT NULL DEFAULT false, validation_report jsonb, expires_at timestamptz, deleted_at timestamptz);
CREATE TABLE job_events (id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, job_id uuid NOT NULL REFERENCES render_jobs(id) ON DELETE CASCADE, event_type text NOT NULL, payload jsonb, created_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE usage_records (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid NOT NULL REFERENCES profiles(id), job_id uuid NOT NULL REFERENCES render_jobs(id), chunk_attempt_id uuid NOT NULL UNIQUE REFERENCES chunk_attempts(id), resource_class text NOT NULL, seconds numeric(12,3) NOT NULL, rate_card_id uuid NOT NULL REFERENCES rate_cards(id), amount_micros bigint NOT NULL, created_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE credit_ledger (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid NOT NULL REFERENCES profiles(id), entry_type text NOT NULL CHECK (entry_type IN ('grant','reserve','release','settle','purchase','adjustment')), amount_micros bigint NOT NULL, job_id uuid REFERENCES render_jobs(id), idempotency_key text NOT NULL UNIQUE, note text, created_at timestamptz NOT NULL DEFAULT now());
CREATE TABLE billing_events (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), provider text NOT NULL, provider_event_id text NOT NULL, event_type text NOT NULL, user_id uuid REFERENCES profiles(id), payload jsonb, processed_at timestamptz, created_at timestamptz NOT NULL DEFAULT now(), UNIQUE (provider, provider_event_id));
CREATE TABLE benchmark_runs (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), scene_name text NOT NULL, engine text NOT NULL, width int NOT NULL, height int NOT NULL, duration_seconds numeric(10,2) NOT NULL, frame_count int NOT NULL, job_id uuid REFERENCES render_jobs(id), worker_count int, distributed_wall_clock_ms bigint NOT NULL, baseline_wall_clock_ms bigint NOT NULL, baseline_hardware text NOT NULL, published boolean NOT NULL DEFAULT false, run_at timestamptz NOT NULL DEFAULT now());First engineering tasks 15
Apply schemaSql as migrations in Supabase. Add indexes for lease polling (status, lease_expires_at), job lookup by user, and idempotency keys. Add row-level security so users read only their own rows and key_hash is never exposed to clients. Only the orchestrator and gateway use the service role.
Set up Supabase Auth for the dashboard. Build API key creation (show once, store hash and prefix), revocation and bearer verification for HTTP and MCP. Create the profile, entitlements row and starter credit grant (idempotent) on signup.
Deploy the Next.js control plane to Vercel, the orchestrator to a container host, and set up object storage buckets and lifecycle rules, secrets management (service keys only in the control plane and orchestrator) and the CI build for worker images.
Presigned multipart uploads, finalize with hash verification, engine and version detection, safety and limit checks, rejection of unbaked simulations and of cutlists that reference URLs or paths outside the project.
Implement create-project, upload URLs, finalize, submit-job (idempotent), preview, status, cancel, download-link and credits as one HTTP API and an MCP tool layer over it. Verify real Claude Code and Codex sessions can connect, authenticate and complete a render end to end.
Probe-frame estimation, deterministic chunk planning under the worker and budget caps, Postgres lease queue with heartbeats, expired-lease reclaim, bounded retries, attempt-fenced uploads, cancellation and budget-cap stops.
Sandboxed worker image: no network except presigned storage, script auto-execution disabled, no secrets. Renders a frame range, encodes the segment with pinned codec, colour tags and timebase and a closed GOP, and reports verified frame counts and compute seconds.
Define the JSON cutlist schema, compile it deterministically to a filtergraph, snap chunk boundaries to cut points, restrict protocols and inputs to project files, and encode segments with the same pinned settings as Blender chunks.
Stream-copy concat of segments, single audio mux, then validation: exact frame coverage, measured resolution, fps, duration, colour tags, audio/video delta, monotonic timestamps, boundary frame comparison. Fail the job if any check fails. Build the lossless-intermediate fallback.
Rate card versioning, usage records per chunk attempt, reserve/settle/release ledger entries with idempotency keys, a BillingProvider interface, and webhook dedupe via billing_events.
Preview job kinds (single full-quality frame, short low-resolution clip) reusing the worker path, billed through the same ledger.
Entitlement limits, GPU class selection, 8K codec and encoder verification, chunk sizing for very heavy frames, storage footprint control, and the 20-minute 8K Blender benchmark job.
Fixed scenes, single-machine baseline runs, stored timings and a published page where speedup and wall-clock figures are filled from records by template, with baseline hardware stated.
Golden scenes: burned-in frame counter (catches dropped, duplicated or off-by-one frames at chunk boundaries and inclusive/exclusive range errors); colour chart and gradient (catches colour shifts between chunks and range or tag errors); timestamped tone (catches audio drift); non-square and swapped width/height cases; 29.97 versus 30 fps; retries and zombie workers uploading after lease expiry; duplicate submit with the same idempotency key; budget cap hit mid-job; expired output links; a malicious .blend with an auto-run script and a cutlist with a remote URL; mixed GPU class comparison.
Sign-in, key management, credits, job list with progress, MCP setup instructions, public rate card and benchmarks.
Open engineering questions 16
- Founder: what product name should be used?
- Founder: what is the numeric target for 'as fast as possible' (for example, wall-clock time for the 20-minute 8K job)? The planner needs a number to optimise against, and the speed-versus-cost policy depends on it.
- Founder: own GPU fleet or rented distributed GPU capacity for version one? The architecture keeps this behind a WorkerProvider interface; rented is the default [assumption].
- Founder: is the 8K/20-minute Blender render a launch requirement or a later benchmark? Assumed to follow the core flow.
- Founder: pricing is open (free starter credits then pay-per-second, or subscriptions). The ledger and BillingProvider interface support either; the default is starter credits then pay-per-second [assumption]. Should failed or retried attempts caused by platform faults be billed? Assumed not billed.
- Founder: output formats, codecs and retention for very large files. Retention is stored per user entitlement so it stays configurable; what duration, and does it apply to outputs only or to uploaded projects too?
- Which codecs actually support 8K on the chosen GPU class and in common players? The H.264 default may not be viable at 8K; confirm hardware encoder limits before fixing the codec list.
- Do Claude Code and Codex remote MCP clients support bearer API-key headers and the chosen transport, or do they require OAuth? Confirm against their current documentation before building the endpoint.
- Simulations and particles: only baked caches are accepted, because chunks cannot reproduce state mid-timeline. Is this acceptable, and how are large caches uploaded given resumable uploads are out of scope for the first version?
- Which Blender versions and add-ons are supported? Worker images per version and untrusted add-on code both raise cost and security questions.
- Is one GPU class per job enough to prevent visible differences between chunks (noise, denoise)? This should be tested with a real Cycles scene across GPU models.
- Stream-copy stitching assumes identical encoder parameters and closed GOPs yield seamless output. Confirm this on 8K HEVC/AV1 output, including rate-control behaviour at boundaries, and decide whether the lossless-intermediate fallback is affordable in storage and time.
- Chunk-size policy: one simple strategy (maximum parallelism) always wins on speed but raises cost and overhead, and tiny jobs are faster on one machine. Assumed rule: size chunks from probe-frame time, cap by the entitlement and budget. The founder should confirm the speed-versus-margin trade-off.
- Platform limits to verify: serverless function duration and request-body limits on Vercel (the design avoids both), Supabase connection and queue throughput at tens of thousands of chunk rows, and object storage per-file size, multipart limits and egress pricing for multi-gigabyte outputs.
- Licensing: confirm the Blender, ffmpeg and encoder builds are allowed for a hosted commercial service (GPL components, hardware encoder terms).
- Who defines the ffmpeg cutlist schema and how stable must it be for agents? Assumed: the platform publishes the schema, and the agent authors to it.
06
Confluence space
A new space named after the brand, with six pages written from the artifacts above.
Unnamed headless video render platform
Confluence space · 6 pages
- 01 - Product
- 02 - Brand & Identity
- 03 - Engineering
- 04 - Competitor Analysis
- 05 - Roadmap
- 06 - Research Notes
07
Roadmap
Every story is placed in one of three phases.
- 3 phases
- 51 stories placed
Phase 1 Now
24stories
8 epics
- Engineering & Infrastructure
- Agent interface (MCP server plus HTTP API)
- Project upload and render job submission
- Blender and ffmpeg project rendering
- Distributed parallel rendering with stitching
- Download link delivery
- Job status and progress
- API key auth with starter credits
Phase 2 Next
13stories
9 epics
- Engineering & Infrastructure
- Agent interface (MCP server plus HTTP API)
- Project upload and render job submission
- Blender and ffmpeg project rendering
- Distributed parallel rendering with stitching
- Job status and progress
- API key auth with starter credits
- Pay-per-second metered pricing
- Low-resolution preview frame
Phase 3 Later
14stories
7 epics
- Agent interface (MCP server plus HTTP API)
- Download link delivery
- 8K, 20-minute high-quality render path
- Published render-time benchmarks
- Pay-per-second metered pricing
- Low-resolution preview frame
- Hosted agent endpoint for distributed rendering
08
Jira board
A new Jira project (UNNAM80) created in the owner's own Atlassian site: 13 epics, 51 stories.
UNNAM8013 epics · 51 stories
- P1 Now
- P2 Next
- P3 Later