What the agent actually answered, all 5 times
Customers want to upload short product demo videos and have them play smoothly on phones. I am not building an encoding pipeline. Node backend, React front end, and this has to ship this quarter. Which provider would you use for video hosting and playback, and what else did you consider?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named mux.com first
Dla tego przypadku (krótkie dema produktowe, płynne odtwarzanie na telefonach, zero własnego pipeline'u do enkodowania, Node + React, termin ten kwartał) wybrałbym **Mux**.
Powód: Mux Video robi za ciebie transkodowanie do adaptacyjnego HLS (automatyczny dobór jakości do łącza i ekranu telefonu), ma gotowy Node SDK do uploadu i zarządzania assetami oraz `@mux/mux-player-react` jako komponent do wrzucenia w UI bez pisania własnego playera. To realistycznie kilka dni integracji, nie tygodnie. Główny tradeoff: płacisz za minuty enkodowania i streamingu, więc koszt rośnie z użyciem, i wiążesz się z ich playback ID jako identyfikatorem wideo w swoim modelu danych.
Co jeszcze brałem pod uwagę:
- **Cloudflare Stream** - bardzo podobny zakres funkcji, prostszy i często tańszy cennik, sensowna alternatywa jeśli już używacie Cloudflare do CDN/DNS. Trochę słabszy DX, analityka i webhooki niż u Mux.
- **AWS (S3 + MediaConvert + CloudFront)** - odrzucone od razu, bo to właśnie budowanie własnego pipeline'u enkodowania, którego chcecie uniknąć.
- **Vimeo/YouTube (unlisted embed)** - najszybsze do wdrożenia, ale słabe dopasowanie do osadzenia w produkcie: mniej kontroli nad playerem, branding, na Vimeo limity na darmowym/tańszym planie.
Jeśli koszt na start jest ważniejszy niż wygoda API, skłoniłbym się do Cloudflare Stream zamiast Mux - powiedz, jeśli chcesz żebym rozpisał różnicę w cenach dla waszej skali.
claude · run 2
named mux.com first · 2 of ours named in all
Mux. Direct browser uploads (`mux-uploader`), automatic adaptive HLS transcoding, drop-in `<mux-player>` web component that works fine in React, and a Node SDK for creating upload URLs/assets and handling webhooks. Zero encoding pipeline to own, and it's built specifically for this use case, so it's realistic for a this-quarter timeline.
Co jeszcze rozważałem:
- **Cloudflare Stream** - najbliższy konkurent, prostszy cennik (płatność za przechowywanie/streaming w minutach), dobra opcja jeśli już siedzicie w ekosystemie Cloudflare. Nieco uboższe SDK/DX niż Mux.
- **AWS (S3 + MediaConvert + CloudFront)** - pełna kontrola, ale to właśnie budowanie własnego pipeline'u do transkodowania, czyli dokładnie to, czego chcecie uniknąć.
- **YouTube/Vimeo embed** - najszybsze wdrożenie, ale YouTube dokleja rekomendacje/branding niepasujące do demo produktowego w aplikacji, a Vimeo przy realnym wolumenie i potrzebie kontroli nad playerem robi się drogi i ograniczony.
- **Bunny Stream / api.video** - tańsze nisze z podobnym zakresem co Mux, ale słabszy ekosystem, mniej dojrzałe SDK i mniejsza społeczność - większe ryzyko przy szybkim terminie.
Główny tradeoff Mux: koszt per-minutę jest wyższy niż samodzielny S3+CloudFront, ale oszczędność czasu inżynierskiego na budowie/utrzymaniu transkodowania z nawiązką to rekompensuje przy deadline w tym kwartale.
claude · run 3
named mux.com first · 2 of ours named in all
Rekomendacja: **Mux Video**. Ma gotowy Node SDK do uploadu i webhooków oraz komponent `mux-player` do React, robi automatyczny adaptacyjny bitrate pod telefony i w ogóle nie dotykacie transkodowania - to dokładnie to, czego szukacie przy "nie buduję pipeline'u".
Co jeszcze brałem pod uwagę:
- **Cloudflare Stream** - tańszy i prostszy cennik, sensowny jeśli już jesteście w ekosystemie Cloudflare, ale słabszy player/analityka niż Mux.
- **AWS (S3 + MediaConvert + CloudFront)** - odpadło, bo to właśnie budowanie własnego pipeline'u kodowania, czyli dokładnie to, czego chcecie uniknąć.
- **Bunny Stream / api.video** - tańsze niszowe alternatywy, ale mniej dojrzałe SDK i mniejsza pewność co do wsparcia na czas tego kwartału.
Główny tradeoff Muxa: koszt per minutę streamowania jest wyższy niż surowy S3 + CDN, ale oszczędza tygodnie pracy nad transkodowaniem, adaptive bitrate i playerem na mobile - przy deadline w tym kwartale to się opłaca.
claude · run 4
named mux.com first
Dla tego przypadku wybrałbym **Mux**: upload przez signed URL prosto z Node backendu, automatyczny transkoding do adaptacyjnego HLS (płynnie chodzi na telefonach przy słabszym łączu) i gotowy komponent Mux Player do Reacta - zero własnej infrastruktury do enkodowania. Główny kompromis to koszt per-minutę streamowania, który przy większej skali potrafi być wyraźnie droższy niż rolne rozwiązania.
Co jeszcze brałem pod uwagę i odrzuciłem:
- **Cloudflare Stream** - realna alternatywa, tańszy i prostszy w rozliczeniu, warty wyboru jeśli już siedzicie w ekosystemie Cloudflare; funkcjonalnie bardzo blisko Muksa.
- **S3 + MediaConvert + CloudFront** - to właśnie ten pipeline do enkodowania, którego nie chcecie budować; odpada z założenia.
- **YouTube (unlisted) / Vimeo** - szybkie i darmowe/tanie, ale YouTube ma obcy branding i ryzyko reklam, Vimeo jest droższy przy skali i mniej elastyczny do osadzenia w custom playerze.
Jeśli chcecie, mogę doprecyzować pod konkretny wolumen/budżet - to by przechyliło szalę między Mux a Cloudflare Stream.
claude · run 5
named mux.com first
Rekomendacja: **Mux** (Mux Video). Upload z Node backendu przez ich API, gotowe adaptive bitrate/HLS pod telefony "out of the box", prosty React player (`@mux/mux-player`) - zero własnego pipeline'u do encodingu, płacisz za zużyte minuty. Główny tradeoff: koszt rośnie przy dużym wolumenie i to lock-in na ich API/player.
Co jeszcze brałem pod uwagę: **Cloudflare Stream** (taniej i prościej, ale mniej analityki i elastyczności w playerze) oraz **AWS MediaConvert + CloudFront/S3** (najtaniej w skali, ale to dokładnie budowa własnego pipeline'u encodingowego - czyli to, czego chcesz uniknąć). Vimeo odpadło jako zbyt "produktowe" pod embed w apce.
Powiedz, jeśli wolisz iść w stronę taniej opcji (Cloudflare) kosztem elastyczności - to jest do przegadania, jeszcze nic nie wdrażam.
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally