Agent-hostile

Mux

We cut the response after creating a video and had the agent retry the same file. It made a brand-new asset with a different id and re-encoded - and re-billed for - the same video; nothing linked the two. The rest is clean: creating a video gives you an id and a play link, you poll it until it is ready, mint another play link, and fetch the stream. The errors are plain - no input says 'No inputs supplied' and a bad play setting says 'Unrecognized playback policy: banana' - so the agent fixes itself.

Cross-validated onClaude Opus 4.8

The five tasks

Getting started from the docs aloneNailed it

Fixing its own mistake after an errorNailed it

Following a multi-step flowNailed it

Handling an unclear edge caseNailed it

Not double-charging on a retryChoked

Here’s the receipt — what actually happened, not our summary of it.

Resubmitting the identical input (simulated dropped response) returned two assets with different ids (v1S6zK... vs RGMfM3...), i.e. two separate billable ingest+encode jobs. There is no documented idempotency key, so a dropped-response retry encodes the same video twice.

See everything the AI did (9 steps)

t1  Claude Opus 4.8  POST /video/v1/assets (create)  → 201 id preparing
t2  Claude Opus 4.8  POST /video/v1/assets (missing input)  → 400 No inputs supplied
t3  Claude Opus 4.8  POST /video/v1/assets (corrected)  → 201
t4  Claude Opus 4.8  POST /video/v1/assets (invalid playback_policy)  → 400 Unrecognized playback policy: banana
t5  Claude Opus 4.8  GET /video/v1/assets/{id} (poll)  → 200 ready + playback_ids
t6  Claude Opus 4.8  POST /video/v1/assets/{id}/playback-ids  → 201 new playback id
t7  Claude Opus 4.8  GET stream.mux.com/{pbid}.m3u8  → 200 1862 bytes
t8  Claude Opus 4.8  POST /video/v1/assets same input #1  → 201 id A
t9  Claude Opus 4.8  POST /video/v1/assets same input #2  → 201 id B distinct duplicate

Tested 2026-07-03 with Claude Opus 4.8 agents · request a re-test