Don't send raw video input to an AI model. Prep it in FFmpeg.

Muse Wonder went live on the Meta Model API five days ago. Most agent builders will pipe a user's upload straight into it, then read the bill. Video-in models meter sampled frames, not files, and the gap between a 1080p master and what the model needs to read is where the feature's cost lives.

Quick answer: Never hand a raw upload to a video input AI model. At roughly 300 tokens per second of default-resolution footage, one hour is about 1.08M input tokens, which overflows muse-wonder-1.0's ~1M context and costs about $4.32 at $4 per million. Prep the file with four FFmpeg steps first: downscale (-vf scale=-2:360), trim to the span that matters (-ss and -t), split the audio out for transcription (-vn), and sample keyframes instead of every frame (-skip_frame nokey). To skip the local binary, FFmpeg Micro runs each of those as one API call and bills the duration of video processed, per second, so trimming 30 seconds out of an hour costs 30 seconds.

What an hour of 1080p actually costs as model input

A video-in model doesn't read your MP4. It samples frames at a fixed rate, usually 1 FPS, and tokenizes each kept frame plus the audio track. Meta hasn't published a per-frame token rate for muse-wonder-1.0, so the only public meter is Google's: the Gemini video docs state 258 tokens per frame at default media resolution and 66 at low. Add audio and that's around 300 tokens per second at default resolution, roughly 100 at low.

muse-wonder-1.0 shipped on the Meta Model API on October 12, 2026 at $4 per million input tokens and $20 per million output, with a ~1M-token context and text-only replies. Cached input is $0.20 per million. Rate limits sit at 3,000 requests and 4M tokens per minute, and Muse Wonder Full isn't on the API at all.

The row that matters isn't the cheapest one. It's the first: an hour of default-resolution video doesn't fit, so past about 50 minutes prep isn't a cost optimization, it's the only way the request succeeds. Every video-in model has its own ceilings, which is why the Gemini video file limit isn't one number, it's four.

You can't preflight the bill, so estimate it from duration

Meta documents POST /v1/responses/input_tokens as the authoritative way to estimate cost before you spend it. For video it doesn't work. A cookbook issue reports a turn where attaching a video moved the estimate by a handful of tokens and then billed about 2,600 extra input tokens, because the counter isn't walking the frames.

Price the request yourself instead, from duration: seconds of video times your assumed per-second rate, times the model's input price. That's the number your agent checks against a budget, because no API call will check it for you.

The four prep steps, as FFmpeg and as one API call

Each prep step is a single transcode. CLI version first, then the hosted equivalent, using the same inputs / outputFormat / options body the FFmpeg Micro API takes.

Downscale to the smallest resolution the model still reads

Resolution is the biggest lever, because token count scales with the frame, not the file. Dropping to 360p takes the per-second rate from roughly 300 tokens to roughly 100, a 3x cut before you've removed a second.

ffmpeg -i input.mp4 -vf "scale=-2:360" -c:v libx264 -preset fast -crf 28 -an prep.mp4

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [{ "url": "https://example.com/input.mp4" }],
    "outputFormat": "mp4",
    "options": [
      { "option": "-vf", "argument": "scale=-2:360" },
      { "option": "-c:v", "argument": "libx264" },
      { "option": "-preset", "argument": "fast" },
      { "option": "-crf", "argument": "28" },
      { "option": "-an" }
    ]
  }'

The job returns immediately with an id and status: "pending"; poll GET /v1/transcodes/{id} until it reads completed and take output_url. 360p is fine for faces, rooms, products and physical action, and too small for a screencast where the model has to read UI labels. For text on screen, stay at 720p and buy the savings back on duration.

Trim to the span that matters

Trimming is where the money is on long recordings, because you're deleting seconds rather than pixels. Four minutes out of an hour is a 93% cut on its own.

ffmpeg -ss 00:12:30 -i input.mp4 -t 240 -c copy clip.mp4

{
  "inputs": [{ "url": "https://example.com/input.mp4" }],
  "outputFormat": "mp4",
  "options": [
    { "option": "-ss", "argument": "00:12:30" },
    { "option": "-t", "argument": "240" },
    { "option": "-vf", "argument": "scale=-2:360" },
    { "option": "-c:v", "argument": "libx264" },
    { "option": "-crf", "argument": "28" }
  ]
}

Fold the downscale into the trim and you pay for one job instead of two. On FFmpeg Micro that job bills four minutes, not sixty: the meter runs on the duration of video processed, not the source length.

Split the audio out and send text instead of a soundtrack

Speech is the densest information in most footage and the cheapest to carry. An hour of talking is about 9,000 words, roughly 12,000 tokens as text, against roughly 1.08M tokens as video. If your question is about what someone said, skip the frames entirely.

ffmpeg -i input.mp4 -vn -c:a libmp3lame -b:a 64k -ac 1 -ar 16000 audio.mp3

{
  "inputs": [{ "url": "https://example.com/input.mp4" }],
  "outputFormat": "mp3",
  "options": [
    { "option": "-vn" },
    { "option": "-c:a", "argument": "mp3" },
    { "option": "-b:a", "argument": "64k" },
    { "option": "-ac", "argument": "1" },
    { "option": "-ar", "argument": "16000" }
  ]
}

Mono at 16 kHz is what Whisper and most hosted speech-to-text endpoints want anyway, and it keeps the upload under their usual 25 MB cap. Stitching the returned transcript back to timestamps is fiddlier than it looks: transcription API to SRT isn't a format swap, it's timing math.

Sample keyframes, not every frame

Keyframes are the frames the encoder already decided were new information. Sampling those tracks scene changes, while fps=1 returns evenly spaced frames whether or not anything moved. On a screencast or a static interview, that's dozens of near-identical stills you paid full price for.

ffmpeg -skip_frame nokey -i input.mp4 -vsync vfr -q:v 3 frame_%03d.jpg

That's the fast CLI form, documented by jdhao: -skip_frame nokey tells the decoder to skip everything but I-frames. Through the API, select the same frames with a filter and tile them into one contact sheet:

{
  "inputs": [{ "url": "https://example.com/clip.mp4" }],
  "outputFormat": "jpeg",
  "options": [
    { "option": "-vf", "argument": "select='eq(pict_type,I)',scale=-2:360,tile=4x4" },
    { "option": "-frames:v", "argument": "1" },
    { "option": "-q:v", "argument": "3" }
  ]
}

A 4x4 sheet is one image rather than sixteen, the cheapest way to show the model sixteen moments. The trade-off: it loses frame order metadata, and fine detail shrinks by a quarter in each direction.

Running prep when your agent has a URL and no FFmpeg binary

Most MCP servers for frame extraction shell out to a local FFmpeg against a local file, which a hosted agent doesn't have. Your agent has a signed URL, a token budget, and no shell.

FFmpeg Micro's MCP server covers that case: transcode_video and transcode_and_wait for the downscale, trim and keyframe steps, transcribe_audio for an SRT straight from a video URL, and request_upload_url plus confirm_upload when the agent holds bytes instead of a link. Auth is OAuth 2.1 with PKCE, so there's no API key in the agent's environment. Billing matters inside a loop: you're charged per second of video processed, and failed jobs are never billed, so a retry storm costs nothing. One token buys 10 seconds, and a new account starts with 200, about 33 minutes of video, no card. The OpenAI Agents API post walks the same wiring end to end.

Pitfalls that cost real money

Prep pitfalls show up after the bill arrives, the wrong time to find them.

When prep isn't worth doing

Prep has a floor. Thirty seconds of default-resolution video is about 9,000 input tokens, roughly 3.6 cents at $4 per million, and no pipeline beats that by enough to matter. If your agent handles short clips only, send them raw.

Keyframe sampling is the wrong tool when timing is the subject. Gait analysis, sign language, sports officiating, anything where the answer lives in motion between frames loses the signal you're measuring. Downscale and trim those, but keep the frame rate. FFmpeg Micro is an API, not an editor: if you need a person deciding which four minutes matter, no transcode job replaces that. A transcript gets you to the timestamp faster than scrubbing, though.

FAQ

How many minutes of video fit in muse-wonder-1.0's context window?

At roughly 300 tokens per second of default-resolution video, a ~1M-token context fills at about 55 minutes, with nothing left for your prompt or the model's reasoning. Plan on 45 minutes as the practical ceiling, or push past two hours with low-resolution frames at roughly 100 tokens per second.

Is extracting keyframes different from setting fps=1?

Keyframe extraction and fps=1 return different frames. Keyframe extraction pulls the I-frames the encoder chose, where the picture genuinely changed. fps=1 resamples on a clock, one frame per second whether the shot moved or not. Use keyframes for screencasts and static interviews, fps=1 when coverage needs to be even across the timeline.

Should I send audio to the model or transcribe it separately?

Transcribe the audio separately in almost every case, and send the model text instead of a soundtrack. An hour of speech is about 12,000 tokens as text against roughly 1.08M tokens as default-resolution video, and a transcript is searchable, cacheable and cheap to re-send across turns. Send audio to the model only when tone, overlap or non-speech sound is part of the question.

If I trim one minute out of a two-hour recording, what does FFmpeg Micro bill?

FFmpeg Micro bills one minute, not two hours. Charges run on the duration of video produced by the job, metered per second with no rounding up to the minute, so a 60-second trim costs 6 tokens regardless of the source length. Failed jobs aren't billed at all.

Point your agent at mcp.ffmpeg-micro.com and the four prep steps become tool calls it makes on its own, against a URL, with no binary to install. The free tier covers about 33 minutes, enough to price your own footage before you commit: sign up free.