标签：#Web

The capability phase is over For the past two years, the AI conversation has been about...

Multiplayer bugs in Unity rarely look like networking bugs. They look like "the game froze," "the player teleported," or "it worked in the Editor and broke in the WebGL build." By the time you've traced it back to the actual cause, you've usually burned an afternoon. Here are 10 issues that show up constantly in Unity networking code — WebSocket-based, Socket.IO, or otherwise — with the actual root cause and the fix. A few of these come straight out of real regression tests and commit history in socketio-unity , an MIT-licensed Socket.IO v4 client for Unity. The rest are patterns you'll recognize if you've shipped a multiplayer game. 1. Reconnect wipes your room/namespace state Symptom: Connection drops for two seconds, comes back, and the player is no longer in their room/lobby/channel — even though the server never removed them. Cause: A common (bad) reconnect implementation tears down the whole client and rebuilds it from scratch — including the list of channels/namespaces the player had joined. The reconnect "succeeds" at the transport level but silently drops application-level state. Fix: Reconnect logic should preserve subscriptions across the transport reset and only re-emit join / connect for namespaces the client already had open. If you're rebuilding the socket object on every reconnect attempt, stop — reconnect the transport, keep the namespace map. // Wrong: rebuilds everything, loses namespace state void OnReconnect () => CreateFreshEngine (); // Right: reuses the existing namespace map void OnReconnect () => ReconnectEngine (); // _namespaces untouched 2. "get_gameObject can only be called from the main thread" Symptom: Random UnityException thrown from inside a network event handler, but only sometimes — usually right when the server sends something. Cause: Your WebSocket/network library delivers callbacks on its own I/O thread. Any Unity API call ( transform.position = , Instantiate , even some Debug.Log paths) from that thread throws. Fix: Never tou

Software spends a surprising amount of its life just moving structured data around: an API returns JSON, a config file is written in YAML or TOML, a report is exported as CSV, a spreadsheet wants tabular rows. These formats are not interchangeable — each was designed for a particular job, and using the wrong one creates friction. Knowing the strengths of each makes you faster and saves you from a category of frustrating bugs. JSON: the lingua franca of APIs JSON (JavaScript Object Notation) is the default for data exchange between systems, especially web APIs. It represents nested objects and arrays cleanly, every programming language can parse it, and its rules are strict enough to be unambiguous. That strictness is also its main friction for humans: no comments are allowed, every string needs double quotes, and a single trailing comma makes the whole document invalid. JSON is excellent for machine-to-machine communication and data storage; it is merely tolerable for files humans have to edit by hand. YAML: configuration humans edit YAML was designed to be readable and writable by people. It uses indentation instead of braces, supports comments, and drops most of the punctuation that makes JSON noisy. This makes it popular for configuration in tools like CI pipelines and container orchestration. Its strength is also its danger: because structure is defined by indentation, a single misplaced space can silently change the meaning of your file or break it entirely. YAML also has surprising type-coercion quirks (the classic example: the word "no" being read as the boolean false ). Use YAML for human-edited configuration, but validate it. TOML: configuration that stays unambiguous TOML (Tom's Obvious Minimal Language) aims for YAML's readability without YAML's ambiguity. It uses explicit, INI-like sections and clear key-value pairs, supports comments, and has unambiguous typing. It is less prone to the silent indentation mistakes that plague YAML, which is why a number

In JavaScript and TypeScript, object references are often treated as disposable. An object is created, assigned to a variable, passed around, replaced, copied, spread, cloned, and eventually discarded. That is normal language behavior, but in larger mutable systems it creates a specific class of bugs: stale aliases. A stale alias appears when one part of the program still holds a reference to an old object while another part has already replaced that object with a new one. The old reference is still valid JavaScript, but it no longer points to current data. Hard Object References is a discipline for avoiding that class of bugs. The idea is simple: Object and array references should be stable. Do not replace them as a normal update mechanism. Copy data into existing objects instead. This rule is useful for application state, but it is not limited to global stores. It applies to ordinary variables, local component state, nested fields, arrays, drafts, snapshots, runtime models, and temporary objects. The broader principle is: Replace primitive values. Do not replace object and array references. The First Rule: const for Objects and Arrays The first level is variable bindings. If a variable holds an object or array, it should normally be declared with const : const user = { /* ... */ }; const items = [ /* ... */ ]; not: let user = { /* ... */ }; let items = [ /* ... */ ]; The point is not that the object becomes immutable. It does not. This is still possible: user . name = ' Alex ' ; items . push ( nextItem ); The point is that the variable should not be rebound to a different object: user = nextUser ; items = nextItems ; That replacement changes which object the variable points to. Any other code that still holds the old reference now points to obsolete data. So the first rule is: Use const for object and array references. Mutate or copy data into the object. Do not rebind the reference. This rule also applies to temporary objects. A temporary object may be short-live

Four years of optimizing React and Next.js projects taught me one thing: unoptimized images are everywhere, and nobody wants to fix them. Every project has the same pattern. Heavy PNG and JPG files are sitting inside /public , there is no consistent image pipeline, and some of those files have no business being that large in a production codebase. This is especially common in small and mid-sized projects. There is no CDN transformation layer or dedicated asset pipeline. Images get added while the product is moving quickly, and the cleanup becomes a task for “later.” Later, of course, never comes. Then, at 1am, while refactoring an extremely vibe-coded Next.js project, I found myself doing the cleanup manually again. Find an image. Upload it to an online compressor. Hit the free limit. Open another tool. Convert a few more. Download everything. Replace the original files. Hunt through the codebase for every import and src path. Hope I did not miss one. And I finally thought: I am a developer. Why am I doing this by hand? So I built pixcrush . npx pixcrush . One command to convert the images, compress them, and update their matching code references automatically. “But doesn’t Next.js already optimize images?” Yes, and if your application uses next/image consistently, you should absolutely take advantage of it. The Next.js <Image> component can resize images for different devices, lazy-load them, and serve modern formats such as WebP. Files inside /public can be referenced from the root URL, while statically imported images also give Next.js access to their intrinsic dimensions. The official Next.js image documentation explains these runtime optimizations in detail. But that solves a different layer of the problem. I wanted to clean up the source assets themselves: Replace heavy PNG and JPG files with smaller WebP files when conversion is worthwhile. Update existing imports and string-based image paths across the repository. Identify images that are no longer reference

Documentation is often the first product a developer experiences. Before they see your architecture, your engineering culture, or your code quality, they interact with your documentation. If that experience is confusing, incomplete, or frustrating, many developers won't make it to their first successful API request. Over the past few weeks, I've been reviewing documentation from AI startups to understand what makes onboarding smooth—and where teams unintentionally create friction. While every company is different, the same patterns kept appearing. 1. Quickstarts assume too much Many Quickstarts jump straight into code without explaining prerequisites. Developers are expected to know: Where to get an API key Which SDK to install Required environment variables Authentication steps A Quickstart should help someone go from zero to a successful request with as little guesswork as possible. 2. Error messages aren't documented Developers don't judge documentation by how it works when everything goes right. They judge it by how quickly it helps them recover when something goes wrong. Instead of only listing error codes, explain: Why the error happens Common causes How to fix it What to try next Good troubleshooting documentation builds confidence. 3. Examples are incomplete Too many examples leave out important details. Developers shouldn't have to infer: Authentication headers Environment variables Request payloads Expected responses Examples should be copy, paste, run, and understand. 4. There's no clear learning path Documentation often feels like a collection of pages instead of a guided journey. A better structure might look like this: Quickstart Core Concepts Tutorials API Reference Advanced Guides Troubleshooting When developers always know what to read next, they make progress faster. 5. Documentation isn't written for AI-assisted development Today, developers increasingly rely on AI coding assistants. That means documentation should also be easy for AI tools to int

Let's be honest, you can't scroll through your feed, listen to a podcast, or even make coffee without someone, somewhere, mentioning the impending AI apocalypse. It is usually framed as: "AI is coming for your job, your keyboard, and your favorite coffee mug." But isn't that incredibly ironic? We are the software developers. We are literally the architects building the AI, writing the code, and then using that AI to build even more tools. Are we truly creating our own replacements, or are we just very efficiently automating the boring parts of our day? It feels a bit like a baker building a robot to knead the dough, only to worry the robot will eventually want to run the whole bakery. I've always wanted to weigh in on this discussion and share my perspective, but I was always hesitant because I am not an "AI expert" and didn't want to get ratioed by researchers. However, I read something truly interesting recently that gave me a new perspective, and I had to share it. The Computer Era Paradigm We have all heard the stories of how we moved from papers to digital, and how computers were coming into the picture and they will take the job of the workers who were writing them everything in the registers. The wave that we are experiencing right now is kind of similar to that wave. At that time, people who were doing everything on the papers would have felt terrified and didn't wanna lose to a computer. But as the computers were new, they were quite fast and were efficient in doing the jobs and storing each and everything in the memory to be kept for later use. This tension is perfectly depicted in a movie I watched (Hidden Figures, if you're looking for it). Initially, teams of human "computers" did complex space research calculations and re-evaluated all the answers so the spacecraft wouldn't deviate from its path. Then, electronic computers were introduced, creating the same panic that we experience these days: "All these people doing calculations will be let off!" But

We are two friends building Pageonaut , a collection of 126 free browser tools (converters, calculators, PDF and image utilities, dev helpers). Early on we committed to one constraint: everything runs client-side . No file uploads, no accounts, no server-side processing. That one decision shaped the whole architecture, and it broke things in ways I did not expect. Here are the lessons, including the one where our server filled up with 419 GB of cache and took the site down twice. Why client-side only Every time I needed a quick converter, the top search results wanted me to upload my file to their server, create an account, or pay to remove a watermark. For work that a browser can trivially do locally. So the rule became: drop a file into one of our converters and it never leaves your device. You can watch the network tab while using it. This is great for privacy and trust, and it has a nice side effect: our server does almost nothing per user, so hosting stays cheap even if a tool gets popular. The cost: some tools are genuinely harder to build. PDF manipulation in the browser (we use client-side libraries instead of a server queue), image processing on the main thread without freezing the UI, and no "just call an API" escape hatch. When a tool truly needs the network (say, fetching a URL you give it), the page says so explicitly. Lesson 1: Unbounded URL params + ISR = a full disk This is the expensive one. We built shareable challenge pages: beat my score, try this color, that kind of thing. The URLs look like /tools/<slug>/challenge/<value> , where <value> is user-generated. With Next.js ISR, every unique URL that renders gets persisted to the filesystem cache. You can see where this is going. The value space is infinite. Bots found the pattern and started enumerating it. .next/server/app grew to 419 GB . The disk filled up, the site went down, and because we did not understand the root cause immediately, it happened a second time a few days later. The fix was tw

For internal websites, client portals, development environments, and WordPress projects that should not be publicly accessible. Not every private WordPress website needs a complete membership system. Sometimes there is no need to manage subscriptions, membership plans, payments, complex user roles, or dozens of content-access rules. Sometimes the requirement is much simpler: The website should only be accessible to logged-in users. That is the reason I created Supracorona Login Gate , a lightweight WordPress plugin that places a simple access gate in front of a website. When the plugin is enabled, logged-out visitors cannot browse protected site content. Instead, they are redirected to the standard WordPress login page or to a custom page selected by the site administrator. The plugin is now published on WordPress.org: Supracorona Login Gate The problem the plugin solves Many WordPress projects are not intended to be publicly accessible at every stage of their lifecycle. They may be: development or staging websites; internal company or organization websites; client portals; private knowledge bases; documentation websites intended only for team members; projects being prepared for launch; demo websites available only to selected users; websites temporarily closed during migration or reconstruction. WordPress provides privacy controls for individual posts, but that is not the same as restricting access to the entire website. Installing a full membership plugin is possible, but it is often far more than the project requires. Such systems may introduce additional database tables, large settings panels, custom profiles, login forms, subscription management, and complex rule engines that will never be used. Supracorona Login Gate has a much narrower responsibility. It is not intended to become a complete membership platform. It is intended to answer one clear question: Is the current visitor logged in? When the answer is yes, the website behaves normally. When the answer

I built a daily Linux documentation site I created this site because I've noticed that Linux documentation is generally confusing. What is xybss? xybss is a simple site that publishes Linux documentation every day. No ads No tracking No JavaScript Just plain HTML docs I add at least one new command every day. Who is it for? Beginners learning Linux Anyone who needs a quick reference People who want simple, clean docs Current content Right now, the site covers basic commands like ls and rm. More commands are added daily. Check it out 👉 https://xybss.github.io Feedback is welcome

I missed the tiny "x" on a browser tab again today. Meant to close it, switched to it instead. Aiming a one-pixel pointer at an eleven-pixel checkbox is basically microsurgery, and somewhere along the way we all just accepted that. Here's the strange part: HCI research solved this twenty years ago. It just never shipped. The paper In 2005, Grossman and Balakrishnan published The Bubble Cursor at CHI. The whole idea fits in one sentence: Make the cursor's hit area a dynamic circle that always contains exactly one target. That turns out to be the same thing as always selecting the target nearest to the pointer. Picture the screen divided into Voronoi cells, one per clickable thing, and the cursor picking the owner of whatever cell it's currently in. The clever part is what it refuses to do. Naive "gravity" cursors snap to every link on the way to the one you actually want, and they get stuck. The bubble cursor grabs exactly one target by definition. The moment a second target becomes nearer, it switches. So it stays calm on link-dense pages, and the paper showed significant speedups in controlled experiments. Twenty years later our cursors are still naked, so I built it as a Chrome extension. It's called MagPoint . The core is about 30 lines A content script collects clickable elements ( a[href] , button , input , ARIA roles and so on) and, every frame, picks the one with the smallest point-to-rectangle distance: function pointToRect ( x : number , y : number , r : DOMRect ): number { const dx = Math . max ( r . left - x , 0 , x - r . right ); const dy = Math . max ( r . top - y , 0 , y - r . bottom ); return Math . hypot ( dx , dy ); } Clicks that land in the empty space near a captured element get re-routed to it. Past a max radius of 120px the magnet lets go, and empty-space clicks behave like the normal web. It also stands down while you type or select text, because getting yanked toward a link mid-sentence would be infuriating. The rule that kept me sane: the vis

The mental model most people have is too simple "Chainlink Functions lets smart contracts call APIs." That's true the same way "Ethereum lets people send money" is true. Technically accurate, misses almost everything that makes the product interesting and almost everything that matters for security. Chainlink Functions is better understood as a decentralized serverless compute platform: arbitrary JavaScript runs across every node in a DON, each node executes independently, OCR aggregates the results, and the aggregated output gets delivered back to the consumer contract through a verified callback. The "API call" is just one of the things that JavaScript can do inside that environment. The DON consensus and the threshold-encrypted secrets model are what make it meaningfully different from a centralized API proxy. This is day 9 of the 28-day Chainlink architecture series. Today covers the full request lifecycle, every contract in the chain, how threshold encryption protects secrets without exposing them to any individual node, and the integration mistakes that come from misunderstanding how billing and callbacks actually work. The four contracts you need to understand Before tracing the full lifecycle, it helps to know exactly which contract does what. FunctionsRouter : the stable, immutable entry point for consumers. Manages subscriptions and authorized consumer contracts. Its interface doesn't change when the underlying implementation upgrades, consumer contracts call sendRequest here and only here. Also handles billing: estimates fulfillment cost at request time and finalizes it at response time. FunctionsCoordinator : the interface between the Router and the DON. Emits the OracleRequest event that DON nodes watch for. Handles fee distribution to transmitters via a fee pool. Inherits from OCR2Base , meaning the full OCR consensus machinery runs here. This contract can be upgraded independently of the Router, which is why the Router exists as a stable facade in fro

Everyone is building rails for AI agents to spend money. Google's AP2 gives agents payment mandates. Coinbase's x402 pattern turns HTTP 402 into machine-to-machine micropayments. Agent wallets are everywhere. But watch what agents actually do all day in 2026: they build products. A Lovable app in an evening. A SaaS in Cursor over a weekend. And every one of those products eventually needs the thing no spending protocol covers — accepting money. The wall every agent hits Here's a session I've watched a hundred times: ➜ ~ claude "finish my app" ✓ scaffold — Next.js + Tailwind ✓ UI — components & design system ✓ UX — onboarding flow polished ✓ auth — Google sign-in wired ✓ database — schema + migrations ✓ deploy — production live ▸ application is almost ready… ✗ missing: payments And then the agent — which just shipped a full product in one session — tells you: "To accept payments you need a merchant account. Traditional PSP onboarding requires a compliance review — expect to wait at least a week for approval." An app built in an evening, waiting 7 days for permission to charge £1. That's not risk management. That's a workflow designed when software took months to ship, and nobody went back to fix it. Your other options aren't better: no company? The classic path detours through Stripe Atlas ($500) and an IRS EIN wait that stretches to weeks for non-US founders — before you can even apply . Software's bottleneck has moved — from writing code to accepting payments. What "agent-native" means on the merchant side The spending side got protocols. The earning side needs four properties: 1. Machine-readable everything. Docs an agent consumes in one pass — llms.txt , agents-first API references. The integrating developer is increasingly not a human. 2. Provisioning tools, not just management tools. Stripe's MCP server can operate an account you already have — customers, refunds, invoices. The agent-native question is one level deeper: create the account. 3. Progressive KYB. G

How I Cut Our AI API Bill by 95% — The Engineering Playbook When our finance lead forwarded me the AWS bill for March, I almost choked on my coffee. We were a team of nine engineers shipping AI features, and somehow we'd burned through enough on inference to cover two salaries. The worst part? I hadn't even noticed because the charges were scattered across OpenAI, Anthropic, and a couple of side experiments. That's the moment I decided to actually treat LLM spending like a real infrastructure problem instead of a credit card swipe. What follows is the playbook I wish I'd had on day one. These aren't theoretical tips — they're the exact moves I made across three products to get our run-rate down to roughly 5% of where it started, without shipping worse software. The Harsh Truth About Model Defaults Here's the dirty secret nobody tells you in the LLM hype cycle: most teams default to the most famous model for every single call. GPT-4o for everything. Claude Sonnet for everything. Then they wonder why their "simple AI feature" costs them a kidney. The model selection decision is where I recovered the majority of my budget. When you look at it rationally, the gap between the flagship tier and the cheap-tier models is absurd for tasks that don't require frontier reasoning. This is the matrix I landed on, and it still governs our routing today: Task What I Used To Use What I Use Now Cost Cut Simple chat GPT-4o ($10/M out) DeepSeek V4 Flash ($0.25/M) 97.5% Classification GPT-4o-mini ($0.60/M) Qwen3-8B ($0.01/M) 98.3% Code generation GPT-4o ($10/M) DeepSeek Coder ($0.25/M) 97.5% Summarization GPT-4o ($10/M) Qwen3-32B ($0.28/M) 97.2% Translation GPT-4o ($10/M) Qwen-MT-Turbo ($0.30/M) 97% I want you to really sit with the classification row. Qwen3-8B at $0.01 per million output tokens. That's sixty times cheaper than GPT-4o-mini. For a binary sentiment classifier, the accuracy difference in my benchmarks was under 1.5 percentage points. The ROI math isn't even close. The code

One of the biggest misconceptions about AI is that every project is unique. At first glance, it certainly feels that way. One project is a chatbot. Another is an AI-powered search system. Another automates documentation. Another generates code. But after building AI systems across multiple brands and initiatives, I started noticing something surprising. The technology changes. The business domain changes. The users change. The underlying principles rarely do. Here are some of the biggest lessons I've learned. 1. AI Doesn't Fix Broken Systems Many teams believe AI will solve operational problems. In reality, AI usually exposes them. If documentation is inconsistent, AI becomes inconsistent. If data is outdated, AI produces outdated answers. If workflows are unclear, automation becomes unreliable. One of the biggest lessons I've learned is this: AI amplifies the quality of your existing systems. It rarely compensates for poor foundations. That's why I spend far more time understanding processes than choosing models. 2. Simplicity Beats Complexity Every new AI framework looks exciting. Agents. Memory. Planning. Reflection. Tool calling. Multi-agent orchestration. I've experimented with many of these approaches, but one principle keeps proving itself. The simplest solution that solves the problem is usually the best solution. A straightforward workflow is often easier to: Build Test Maintain Scale Explain Complexity should be introduced only when it delivers clear value. 3. Prompt Libraries Are More Valuable Than Individual Prompts When I first started using AI, I wrote prompts from scratch. Eventually I realized I was solving the same problems repeatedly. Now I build prompt libraries. Instead of creating new prompts every day, I improve existing ones. This creates consistency across projects. If you're interested in how I manage this, I recently shared the system I use to organize more than 10,000 prompts across different projects. The shift from individual prompts to

I had a /image endpoint capped at 3 requests per minute. Simple express-rate-limit, keyed by IP,...

In my previous articles, I’ve consistently emphasized a core architectural principle: once the render layer no longer dictates the entire data flow, the boundaries between State, Derived State, and Effects become critical. When we fall into the habit of stuffing every UI-affecting variable into generic "state," the system quickly loses its semantic structure. In modern frontend applications, this architectural gap becomes most glaring when dealing with asynchronous work. Async data is never merely "a value that will appear in the future." It carries complex semantics regarding its source, temporal validity, cancellation, error recovery, and invalidation. If these semantics aren't modeled explicitly, they inevitably get pushed down into the UI framework’s lifecycle—indirectly patched together through component mounts, effect dependencies, and callback guards. This brings us to the core question of this article: What does a system lose when the correctness of async work is forced to depend on the UI lifecycle? We are all incredibly familiar with this pattern: const data = await fetchSomething () setState ( data ) Or, using a standard UI framework hook: useEffect (() => { let cancelled = false fetchSomething (). then ( result => { if ( ! cancelled ) { setData ( result ) } }) return () => { cancelled = true } }, []) There is nothing inherently wrong with this code for simple use cases. It’s intuitive and perfectly aligns with how Promises are designed to work: trigger the operation, wait for the resolution, and write the result back into state. However, this mental model has a subtle downside. It encourages us to think of async work as simply calling setState after a Promise resolves. That may hold up for simple screens, but as an application grows, the model starts to expose structural problems. Promise Only Describes Completion, Not Ownership A Promise solves a very specific problem: A piece of work will complete in the future, and it will either succeed or fail. It c

A few months ago I didn't know much about coding. Today I have a full stack marketplace running with a real API, a live database, user authentication, image uploads, messaging and a React frontend. The Idea Kisumu has a huge secondhand clothes market. Mitumba is everywhere — Kibuye market, roadside stalls, WhatsApp groups. But there is no dedicated digital platform for it. If you want to sell a jacket in Kondele you have no easy way to reach buyers in your area. If you want to find size L shoes in CBD you have to physically go and look. I wanted to build something that solved a real local problem. Not another todo app. Not another weather app. Something that could actually help people in my city. That is how Kisumu Marketplace was born. The Tech Stack I Chose I built the backend in Go using the Gin framework. The database is PostgreSQL hosted on Neon.tech — a free cloud database that saved me more than once when my laptop broke. Authentication uses JWT tokens and bcrypt for password hashing. Images are uploaded to Cloudinary. The frontend is React with Tailwind CSS. I chose Go because Zone 01 teaches it and I wanted to go deep on one language rather than shallow on many. I chose PostgreSQL because it is the industry standard and learning it properly matters. I chose React because it is the most in-demand frontend framework and I wanted to build something real with it. What I Learned I learned Go from scratch while building this. I learned React from scratch while building this. I learned PostgreSQL, JWT, bcrypt, Cloudinary, Tailwind, axios, React Router and more — all by needing them for this project. The most valuable thing I learned is that you understand something properly only when you build with it. Reading about JWT is nothing like debugging a 401 Unauthorized error at midnight. I also learned that documentation is a skill. Writing this article, explaining how things work, is making me understand my own project better.

📦 Code: github.com/USER/hls-multi-audio - replace before publishing TL;DR We'll add a working language picker to an HLS player. The hard part isn't the dropdown, it's the manifest. We'll author alternate audio with EXT-X-MEDIA audio groups, package it correctly, debug the classic "zero audio tracks" bug, and wire a switcher on hls.js v1.7 . Adaptive video, captions, the whole pipeline already works. Now someone wants an English/Spanish audio toggle. In HLS, "which audio can the viewer pick" is decided at packaging time and written into the master playlist. The player just displays it. Let's build it in that order. 1. Understand the structure (audio groups) HLS decouples video variants from audio renditions: Each audio rendition is an #EXT-X-MEDIA:TYPE=AUDIO entry pointing at its own media playlist. Renditions are bundled into a named audio group via GROUP-ID . Each video variant ( #EXT-X-STREAM-INF ) references a group with AUDIO="..." . A correct master playlist: #EXTM3U #EXT-X-VERSION:6 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="English",LANGUAGE="en",DEFAULT=YES,AUTOSELECT=YES,CHANNELS="2",URI="audio/en.m3u8" #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="Espanol",LANGUAGE="es",DEFAULT=NO,AUTOSELECT=YES,CHANNELS="2",URI="audio/es.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=2128000,CODECS="avc1.640028,mp4a.40.2",AUDIO="aud" video/720p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1128000,CODECS="avc1.640020,mp4a.40.2",AUDIO="aud" video/480p.m3u8 Every attribute earns its place: LANGUAGE - BCP-47 code, used for the label. DEFAULT - plays when the viewer has no preference. AUTOSELECT - may be auto-picked from the OS language. CHANNELS - needed so the player can reason about stereo vs surround. BANDWIDTH on each video variant must include the audio group's bitrate , or your ABR logic works from a wrong total. 2. Author the renditions with FFmpeg Extract/encode each language's audio, then package. First, encode video-only and audio-only renditions: # video only (no audio), two ladder rungs

📦 Code: github.com/USER/video-api-bench - replace before publishing TL;DR The per-minute delivery rate is the easiest number to compare and the least useful. The real cost lives in encoding, analytics, and the player. This post compares Mux, Cloudflare Stream, api.video, FastPix, and AWS on what each includes by default, then gives you a tiny script to benchmark upload and time-to-ready on your own files so you stop trusting marketing pages. I have shipped video on four managed APIs across three jobs, and every single time the invoice surprised someone. Not because the delivery rate was wrong, but because encoding, analytics, and the player turned out to be separate line items on some platforms and free on others. Let's compare the parts that don't show up in the headline number. ⚠️ Note: pricing pages move. Everything here was checked in June 2026; verify the links before quoting numbers. 1. Encoding: free or metered? This is the widest spread in the whole comparison. Platform Encoding Delivery Storage Cloudflare Stream Free $1 / 1,000 min delivered $5 / 1,000 min stored api.video Free (unlimited) $0.0017 / min $0.00285 / min FastPix Free on standard plan ~$0.00096 / min @1080p Per-minute, tiered Mux Metered per minute Per minute Per minute AWS (DIY) Per minute (MediaConvert) Per GB (CloudFront) Per GB (S3) If your catalog is upload-heavy (lots of assets encoded once, watched rarely), metered encoding is not a rounding error. It can flip which platform is cheapest, even when the delivery rates look identical. 2. Analytics: included or a $499 floor? QoE analytics is the feature teams forget to price until playback breaks in production. Platform QoE analytics Entry cost FastPix (Video Data) Session-level, 50+ signals/session Free up to 100K views/month Mux (Mux Data) Mature, broad device SDKs $499/month (Media plan, 1M views, +$0.50/1K) Cloudflare Stream Basic Included, limited depth api.video Available Usage-based AWS Build it yourself (CloudWatch + logs) Engineerin