# elixir Published articles for elixir. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## App Engine Flex Language Shootout DevFeed: [App Engine Flex Language Shootout]() Original publisher: [Read original article]() Author: Khan Academy Published: 2017-04-17T22:00:00Z Content type: article Language: en Sources: [Khan Academy]() Topics: [Hackathon](), [Back end](), [Elixir](), [distributed-systems](), [Open Source]() Tags: [backend](), [distributed-systems](), [elixir](), [engineering](), [hackathon](), [infrastructure](), [news](), [open-source]() ### AI overview A first-person account of a Khan Academy hackathon project exploring Google App Engine Flex and comparing programming-language options. The author describes Khan Academy's existing Python backend, interest in gaining experience with Flex, and personal interest in Elixir, while noting that a language switch was not imminent. ### Source excerpt By Amos Latteier This is the second time I've been to Silicon Valley. Some years ago - never ... Read more ## Security updates for Monday DevFeed: [Security updates for Monday]() Original publisher: [Read original article]() Author: jzb Published: 2026-09-14T13:18:14Z Content type: news Language: en Sources: [LWN.net]() Topics: [Security](), [Debian](), [Fedora](), [Firefox](), [Git](), [nginx](), [Python](), [cURL](), [Elixir](), [F#](), [Redis](), [Rust]() Tags: [curl](), [debian](), [elixir](), [firefox](), [git](), [nginx](), [python](), [redis](), [rust](), [security](), [updates]() ### AI overview Security updates were issued across AlmaLinux, Debian, Fedora, Gentoo, Mageia, Oracle, and SUSE. The affected software includes operating-system components, browsers, developer tools, programming-language packages, servers, libraries, and cloud-related utilities. ### Source excerpt Security updates have been issued by AlmaLinux (389-ds-base, apr-util, coreutils, freerdp, git-lfs, glib2, gstreamer1-plugins-base, kernel, libkcapi, nginx, nodejs:22, nodejs:24, osbuild-composer, perl-YAML-Syck, postgresql16-postgis, ruby, ruby4.0, ruby:3.3, and vim), Debian (jbig2dec, kamailio, nginx, spip, and xorg-server), Fedora (baresip, bind, bluez, bubblewrap, chirp, chromium, cockpit, composer, corosync, darktable, dokuwiki, elixir, exiv2, expat, firefox, freerdp, freerdp2, gdk-pixbuf2, gegl04, golang-x-perf, grpcurl, kernel, kernel-headers, libevent, libmongocrypt, libpcap, libre, libsoup3, memcached, mingw-expat, mingw-openexr, mongo-c-driver, mrtg, nagios-plugins, nsd, nss, openssl, openvpn, PackageKit, pdns-recursor, perl-Net-OAuth, perl-XML-Bare, php-pecl-mongodb2, python-asteval, python-pip, rclone, rest, rust-hickory-net, rust-hickory-proto, rust-hickory-resolver, rust-ppmd-rust, rust-webbrowser, srt, syncthing, tar, tkimg, and valkey), Gentoo (Chromium, Google Chrome, Microsoft Edge, Opera, Vivaldi and Ruby), Mageia (bind, ffmpeg, glibc, java-17-openjdk, java-21-openjdk, librabbitmq, perl-Catalyst-Plugin-Static-Simple, perl-Imager, tor, and xz), Oracle (389-ds:1.4, ansible-core, apr-util, coreutils, freerdp, git-lfs, glib2, gstreamer1-plugins-base, gzip, httpd:2.4, image-builder, java-21-openjdk, kernel, mrtg, nginx, osbuild-composer, perl-DBI, postgresql16-postgis, python-lxml, python3.12-lxml, redis:6, and vim), SUSE (389-ds, ansible-core, ansible-creator, azure-storage-azcopy, cargo-audit, chromedriver, chromium, clamav, containerized-data-importer1.65, containerized-data-importer1.66, curl, dracut, ffmpeg-4, google-guest-agent, google-osconfig-agent, helm, java-1_8_0-ibm, jupyter-nbconvert, kernel, libpng16, libusb-1_0, libvirt, multipath-tools, NetworkManager, opensc, openssl-3, perl-Authen-SASL, perl-HTML-FormHandler, perl-Mojolicious, perl-Protocol-HTTP2, python-jwcrypto, python-sqlparse, python-tornado6, python313-geopy, python313-modelscope ## Your Agent Speaks MCP. Give It a Computer. DevFeed: [Your Agent Speaks MCP. Give It a Computer.]() Original publisher: [Read original article]() Published: 2026-09-03T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [MSP MCP](), [AI Bots]() Tags: [agents](), [api](), [auth](), [cdn](), [claude](), [claude-code](), [cli](), [close-to-users](), [cloud](), [codex](), [cursor](), [deploy-app-servers](), [docker](), [elixir](), [filesystems](), [fly](), [fly-io](), [gemini](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [mcp](), [mcp-server](), [networking](), [postgresql-clusters](), [servers](), [skills]() ### AI overview The article presents Sprites as disposable cloud computers for coding agents and explains using their API through MCP. It argues that MCP transport and progressive capability disclosure can work together, including through plugins and skills. ### Source excerpt Sprites are disposable cloud computers. They appear instantly, always include durable filesystems, and cost practically nothing when idle. They're the best and safest place on the Internet to run agents and we want you to create dozens of them. Sprites are a place to run agents; the first thing you should think to do with a new Sprite is to type claude (or gemini or codex). We've put a lot of effort into making sure coding agents feel safe and happy when they're on Sprites, because, to (probably) quote John von Neumann, "happy agents are productive agents." What's less obvious about Sprites is that they're great tools for agents. Want three different versions of a new feature? A test environment? An ensemble of cooperating services? It's super handy to be able to start your prompts, "On a new Sprite, do...". The Sprites API is simple, discoverable, and designed for this use case. The only real question is how your agent reaches it. For most of you the answer is MCP, and the setup is already written. You Don't Have To Pick There's an argument going around that MCP is the wrong way to extend an agent, and that command line tools and discoverable APIs are the Right Way. Half of that argument is correct, and it's the important half, so let's take it seriously. Dumping thirty tool descriptions into a context window is a bad way to teach anything. Not every Sprite command matters in every session, and cramming them all in signals to the model that they all matter to you. If you're not using network policies, gemini shouldn't burn a single token learning to configure them. Capabilities should reveal themselves progressively, the way they do when an agent works out a CLI one subcommand at a time. The wrong half is treating that as a case against MCP. Progressive disclosure is a question of what you say to the model. MCP is a question of how the bytes get there: transport, auth, structured results, a tool the model can call instead of a command whose flags it has to guess. Tho ## Turn And Face The Strange DevFeed: [Turn And Face The Strange]() Original publisher: [Read original article]() Published: 2026-07-24T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [AI Chat]() Tags: [agents](), [ai](), [cdn](), [close-to-users](), [cloud](), [cloud-infrastructure](), [coding](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [postgresql-clusters](), [servers](), [software-development]() ### AI overview Fly.io says it is raising more money, launching a new iteration of Sprites--computers for agents--and refocusing the company around that product as AI reshapes software development. ### Source excerpt We're Fly.io, a public cloud platform that is both our favorite way to put an app on the Internet and our favorite way to safely let a frontier agent coding harness cook. This is a post about our company, the future, and Sprites, which are computers for agents that you can check out right now. This is a complicated post. So I need you to promise me something: if you read past this introduction, you'll read the whole rest of the way through. It's an honor thing. A couple months back, Theo Browne ran a video rating the "best place to host a new application in 2026". Theo tends to say nice things about us. He did this time too. But then he concluded by saying that of all the providers he pays attention to, we were the one he was least confident would be around by the end of the year. Well, fuck. Theo startled us, because we're in the middle of a run of strong quarters that have included the best financial months in the company's history. But that take has been rattling around in my brain. It whacked me right on a raw nerve, about what we're doing and where we're going as a company. Honestly, I should've seen this coming. Fly.io has been motoring along this year, but I've coasted a bit, letting the company smolder in an unresolved identity crisis. I'm going to overshare some more in a second, but I won't leave you hanging. So: we've raised a bunch more money. We're launching a new iteration of Sprites, and focusing the company on them and the problem they solve. And I'm tagging in Scott Johnston as CEO. Product-Market Fit I started Fly.io with two clear principles that probably don't matter anymore. The first is that Internet applications work best when they're fast, and that happens when they're deployed close to users. I learned this over many years of working at Ars Technica, and started Fly.io in part to scratch an itch. It was our mantra over the first several years of the company. The second is that cloud infrastructure is too complicated. Developers need platform ## Building Agents that Don't Break Themselves DevFeed: [Building Agents that Don't Break Themselves]() Original publisher: [Read original article]() Published: 2026-06-08T00:00:00Z Content type: tutorial Language: en Sources: [The Fly Blog]() Topics: [AI Bots]() Tags: [agent](), [agents](), [ai](), [api](), [bash](), [cdn](), [close-to-users](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [node-js](), [postgresql-clusters](), [sandbox](), [sandboxes](), [servers]() ### AI overview A tutorial on keeping long-lived AI agents safe by separating the agent process from risky shell execution. It recommends running each potentially destructive task in an isolated, disposable Sprite rather than letting the agent execute commands in its own environment. ### Source excerpt Building agents is fun. Rebuilding agents that break themselves... less so. A lot of Fly people are building agents with less of a penchant for self-destruction by teaching their agents to do anything risky in a Sprite. You get an agent that stays alive long enough to actually use its snazzy self-improvement features, and you can allow your agent to try things that would otherwise be battleship-scale footguns. Here's how to do it. Brains vs Hands Your agent would be pretty useless without a shell, because this is where it does agent things. Run the test suite, apply the migration, install the dependency, delete the temp files. Unfortunately, your agent's shell access is also what tends to ruin your afternoon, simply because "delete the temp files" and "delete the wrong files" are one fat-fingered glob apart, and as we're frequently warned, AI can make mistakes. This is why we have sandboxes. But a lot of people default to putting an agent that's going to do potentially scary work in a sandbox. This comes with a long list of tradeoffs that you really don't have to make, because where your agent lives and where it runs code are two entirely separate considerations. PPE for agent workers. The agent process is a loop. It calls a model, reads the response, picks a tool, rinse and repeat. It's a long-lived process that only becomes more competent and less stupid if memory, skills and history persist. So a Fly Machine that sleeps when idle and wakes on a message, a small VPS. Your laptop while you iterate. These are all fine homes for a loop calling an API, which doesn't need a blast shield. It's when you want your agent to execute that things get hairy. bash -c + whatever string the model just produced needs to be run in a padded room. Somewhere where the agent's code can't break itself or anything connected to it. And if your agent is doing more work than you are, you're going to want a whole facility of padded rooms that can be thrown away and rebuilt on a whim. One Sprit ## How Discord Added Distributed Tracing to Its Elixir Message-Passing Services DevFeed: [How Discord Added Distributed Tracing to Its Elixir Message-Passing Services]() Original publisher: [Read original article]() Author: Alexandre Zajac Published: 2026-05-18T15:39:51Z Content type: article Language: en Sources: [Hungry Minds]() Topics: [Discord](), [Elixir](), [tracing](), [Traces](), [telemetry](), [gRPC]() Tags: [discord](), [elixir](), [messages](), [traces](), [tracing]() ### AI overview The article describes Discord's distributed-tracing implementation for Elixir services that communicate through message passing. It highlights trace-context propagation through message envelopes, a gradual zero-downtime migration, fanout-based sampling, lazy context unpacking, and restrictions on root spans after fanout. ### Source excerpt PLUS: AI as Netflix model 📊, Spotify NLI via Claude 🎵, Subagent patterns 2026 🤖 ## You've Got (Too Much) Mail: Behind the Scenes of the 3/25/26 Voice Outage DevFeed: [You've Got (Too Much) Mail: Behind the Scenes of the 3/25/26 Voice Outage]() Original publisher: [Read original article]() Author: Discord Engineering Published: 2026-04-29T00:00:00Z Content type: article Language: en Sources: [Discord Blog]() Topics: [incident](), [migration](), [networking](), [Processes]() Tags: [audio](), [backend](), [discord](), [elixir](), [incident](), [infrastructure](), [kubernetes](), [migration](), [on-call](), [outage](), [processes](), [real-time](), [routing](), [video](), [voice]() ### AI overview Discord's engineering team explains a cascading voice and video outage caused when a routine configuration update shut down a large portion of session-management servers. The post covers the resulting load on call-routing systems, recovery, and infrastructure improvements. ### Source excerpt On March 25th, voice and video on Discord suffered major degradation beginning at 12:13 PDT, lasting a little over three hours. Learn how the issue originated, how it affected systems across Discord, how we recovered, and how we're preventing the same problem from reoccurring. ## 100,000 GitHub stars DevFeed: [100,000 GitHub stars]() Original publisher: [Read original article]() Author: Paul Copplestone Published: 2026-04-02T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Supabase](), [Open Source](), [Databases](), [GitHub](), [Deno](), [Elixir](), [API](), [Embeddings]() Tags: [community](), [database](), [developers](), [discord](), [elixir](), [embeddings](), [github](), [open-source](), [tool]() ### AI overview Supabase celebrates reaching 100,000 GitHub stars and says eight million developers are building with the platform. The article reflects on its open-source, community-focused approach and highlights projects supporting Supabase, including Postgres, PostgREST, pgvector, Deno, imgproxy, and Elixir Phoenix. ### Source excerpt Supabase hits 100,000 GitHub stars. A reflection on community, open source, and what got us here. ## Tracing Discord's Elixir Systems (Without Melting Everything) DevFeed: [Tracing Discord's Elixir Systems (Without Melting Everything)]() Original publisher: [Read original article]() Author: Nick Krichevsky Published: 2026-03-04T00:00:00Z Content type: article Language: en Sources: [Discord Blog]() Topics: [tracing](), [Elixir](), [Discord](), [Concurrency](), [observability](), [Instrumentation](), [systems]() Tags: [concurrency](), [concurrent](), [discord](), [elixir](), [instrumentation](), [logs](), [metrics](), [monitoring](), [observability](), [on-call](), [outage](), [systems](), [tracing]() ### AI overview Discord describes how it added distributed tracing to its Elixir systems to investigate guild performance problems and outages at scale. The article explains the limitations of metrics, logs, and the internal guild timings tool, then outlines the work required to propagate tracing information through Elixir's message-passing system. ### Source excerpt Join Senior Software Engineer Nick Krichevsky as he explains how Discord added distributed tracing to Elixir's message passing and optimized it to handle millions of concurrent users. ## Scaling Whatnot: Behind the Largest Live Shopping Stream in US History DevFeed: [Scaling Whatnot: Behind the Largest Live Shopping Stream in US History]() Original publisher: [Read original article]() Author: Whatnot Engineering Published: 2026-02-24T14:33:16Z Content type: article Language: en Sources: [Whatnot Engineering]() Topics: [Scalability](), [Architecture & Design](), [Platform Engineering](), [SRE](), [Elixir](), [Python]() Tags: [cloud-computing](), [devops](), [elixir](), [infrastructure](), [load-testing](), [python](), [resilience](), [scalability](), [scale](), [site-reliability-engineer](), [software-engineering](), [sre](), [technology]() ### AI overview Whatnot describes how it prepared its platform for a MrBeast giveaway stream that reached 583,000 concurrent viewers and became the largest live shopping event in US history. The article covers architectural investments, progressive production load testing, event-day results, and lessons for future scalability. ### Source excerpt On February 8, 2026, over a half million viewers tuned in to watch MrBeast give away 1 million dollars in prizes on Whatnot. On Big Game Sunday 2026, MrBeast went live on Whatnot for a giveaway show that would become the largest live shopping event in US history. At peak, 583,000 concurrent viewers were watching a single show on our platform. Over 555k people entered a single giveaway. We drove hundreds of thousands of new signups in 24 hours. If any one of a dozen systems buckled, it would have happened live on camera. We pulled it off with zero major incidents. But that outcome was never guaranteed. It took months of preparation, 60+ engineers across every major engineering org, and some of the most significant infrastructure investments we've ever made. In this post, we'll walk through the biggest technical challenges we faced and how we solved them, not with throwaway scaffolding, but with durable platform improvements that raise our scalability ceiling for every seller and buyer on the platform. We'll cover the work in three parts. First, the key architectural investments we made to handle this scale: admission control, connection pooling, feed resilience, and video infrastructure. Then, how we validated it all through progressive production load testing. Finally, what happened on event day, what we learned, and what we're carrying forward. Setting the Stage If you've followed our blog, you might remember our Post Malone "Post-Poned" post from 2022 or our three-part series on preparing for the 2024 Big Game. Each of those events pushed us to improve, and each one revealed new limits. As our community has grown, scaling our infrastructure to match has been a consistent priority. The MrBeast event was on a different order of magnitude entirely, but it accelerated work that was already underway. Our target was to support 1 million concurrent viewers on a single stream and 1.35 million across the platform. To put that in perspective, our previous largest event had ## Litestream Writable VFS DevFeed: [Litestream Writable VFS]() Original publisher: [Read original article]() Published: 2026-01-29T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [data](), [Amazon S3]() Tags: [cache](), [cdn](), [close-to-users](), [database](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [open-source](), [postgresql-clusters](), [s3](), [servers](), [sqlite](), [storage]() ### AI overview Litestream synchronizes SQLite databases with S3-style object storage for backup and restore. The article describes its use in Fly.io Sprites, including an orchestrator and a storage block map backed by Litestream SQLite and NVMe caching. ### Source excerpt I'm Ben Johnson, and I work on Litestream at Fly.io. Litestream is the missing backup/restore system for SQLite. It's free, open-source software that should run anywhere, and you can read more about it here. Each time we write about it, we get a little bit better at golfing down a description of what Litestream is. Here goes: Litestream is a Unix-y tool for keeping a SQLite database synchronized with S3-style object storage. It's a way of getting the speed and simplicity wins of SQLite without exposing yourself to catastrophic data loss. Your app doesn't necessarily even need to know it's there; you can just run it as a tool in the background. It's been a busy couple weeks! We recently unveiled Sprites. If you don't know what Sprites are, you should just go check them out. They're one of the coolest things we've ever shipped. I won't waste any more time selling them to you. Just, Sprites are a big deal, and so it's a big deal to me that Litestream is a load-bearing component for them. Sprites rely directly on Litestream in two big ways. First, Litestream SQLite is the core of our global Sprites orchestrator. Unlike our flagship Fly Machines product, which relies on a centralized Postgres cluster, our Elixir Sprites orchestrator runs directly off S3-compatible object storage. Every organization enrolled in Sprites gets their own SQLite database, synchronized by Litestream. This is a fun design. It takes advantage of the "many SQLite databases" pattern, which is under-appreciated. It's got nice scaling characteristics. Keeping that Postgres cluster happy as Fly.io grew has been a major engineering challenge. But as far as Litestream is concerned, the orchestrator is boring, and so that's all I've got to say about it. The second way Sprites use Litestream is much more interesting. Litestream is built directly into the disk storage stack that runs on every Sprite. Sprites launch in under a second, and every one of them boots up with 100GB of durable storage. That's a tr ## The Design & Implementation of Sprites DevFeed: [The Design & Implementation of Sprites]() Original publisher: [Read original article]() Published: 2026-01-14T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [fly](), [Cloud](), [Linux](), [Orchestration](), [ssh](), [Containers](), [Docker]() Tags: [cdn](), [close-to-users](), [cloud](), [cloud-computing](), [containers](), [cost](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [linux](), [networking](), [orchestration](), [platform](), [postgresql-clusters](), [scale](), [servers](), [ssh]() ### AI overview Fly.io's article introduces Sprites, disposable Linux virtual machines designed to start in seconds, provide root access and a durable 100GB filesystem, and automatically sleep when inactive. It explains the orchestration decisions behind the platform, including moving away from container images while retaining convenient, Docker-like workflows. ### Source excerpt We're Fly.io, and this is the place in the post where we'd normally tell you that our job is to take your containers and run them on our own hardware all around the world. But last week, we launched Sprites, and they don't work that way at all. Sprites are something new: Docker without Docker without Docker. This post is about how they work. Replacement-level homeowners buy boxes of pens and stick them in "the pen drawer". What the elites know: you have to think adversarially about pens. "The purpose of a system is what it does"; a household's is to uniformly distribute pens. Months from now, the drawer will be empty, no matter how many pens you stockpile. Instead, scatter pens every place you could possibly think to look for one -- drawers, ledges, desks. Any time anybody needs a pen, several are at hand, in exactly the first place they look. This is the best way I've found to articulate the idea of Sprites, the platform we just launched at Fly.io. Sprites are ball-point disposable computers. Whatever mark you mean to make, we've rigged it so you're never more than a second or two away from having a Sprite to do it with. Sprites are Linux virtual machines. You get root. They create in just a second or two: so fast, the experience of creating and shelling into one is identical to SSH'ing into a machine that already exists. Sprites all have a 100GB durable root filesystem. They put themselves to sleep automatically when inactive, and cost practically nothing while asleep. As a result, I barely feel the need to name my Sprites. Sometimes I'll just type sprite create dkjsdjk and start some task. People at Fly.io who use Sprites have dozens hanging around. There aren't yet many things in cloud computing that have the exact shape Sprites do: Instant creation No time limits Persistent disk Auto-sleep to a cheap inactive state This is a post about how we managed to get this working. We created a new orchestration stack that undoes some of the core decisions we made for Fly ## Code And Let Live DevFeed: [Code And Let Live]() Original publisher: [Read original article]() Published: 2026-01-09T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [Cloud](), [Linux](), [apt](), [Amazon EC2](), [Network](), [ssh](), [Docker]() Tags: [apt](), [cdn](), [close-to-users](), [cloud](), [code](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [linux](), [network](), [networking](), [postgresql-clusters](), [servers](), [ssh]() ### AI overview Fly.io presents Sprites as durable, rapidly created cloud computers designed to replace ephemeral, read-only sandboxes. A Sprite provides a persistent Linux environment with substantial storage, automatic sleep, checkpoint and restore, networking, and low-cost operation at scale. ### Source excerpt The state of the art in agent isolation is a read-only sandbox. At Fly.io, we've been selling that story for years, and we're calling it: ephemeral sandboxes are obsolete. Stop killing your sandboxes every time you use them. My argument won't make sense without showing you something new we've built. We're all adults here, this is a company, we talk about what we do. Here goes. So, I want to run some code. So what I do is, I run sprite create. While it operates, I'll explain what's happening behind the-- Wrap text Copy to clipboard ✓ Created demo-123 sprite in 1.0s ● Connecting to console... sprite@sprite:~# Shit, it's already there. That's a root shell on a Linux computer we now own. It came online in about the same amount of time it would take to ssh into a host that already existed. We call these things "Sprites". Let's install FFmpeg on our Sprite: Wrap text Copy to clipboard sudo apt-get install -y ffmpeg >/dev/null 2>&1 Unlike creating the Sprite in the first place, installing ffmpeg with apt-get is dog slow. Let's try not to have to do that again: Wrap text Copy to clipboard sprite@sprite:~# sprite-env checkpoints create # ... {"type":"complete","data":"Checkpoint v1 created successfully", "time":"2025-12-22T22:50:48.60423809Z"} This completes instantly. Didn't even bother to measure. I step away to get coffee. Time passes. The Sprite, noticing my inactivity, goes to sleep. I meet an old friend from high school at the coffee shop. End up spending the day together. More time passes. Days even. Returning later: Wrap text Copy to clipboard > $ sprite console sprite@sprite:~# ffmpeg ffmpeg version 7.1.1-1ubuntu1.3 Copyright (c) 2000-2025 the FFmpeg developers Use -h to get full help or, even better, run 'man ffmpeg' sprite@sprite:~# Everything's where I left it. Sprites are durable. 100GB capacity to start, no ceremony. Maybe I'll keep it around a few more days, maybe a few months, doesn't matter, just works. Say I get an application up on its legs. Install more pa ## Litestream VFS DevFeed: [Litestream VFS]() Original publisher: [Read original article]() Published: 2025-12-11T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [SQLite](), [Amazon S3](), [Databases](), [Open Source](), [Development]() Tags: [cdn](), [close-to-users](), [database](), [deploy-app-servers](), [dev](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [object-storage](), [open-source-software](), [postgresql-clusters](), [s3](), [servers](), [sql](), [sqlite]() ### AI overview The article introduces Litestream VFS, which lets SQLite query Litestream-backed databases directly from object storage such as Amazon S3. It supports querying without downloading the entire database and provides SQL- and pragma-based point-in-time recovery. The article also explains how Litestream v0.5 uses LTX ordered page sets and compaction to restore the latest versions of changed database pages efficiently. ### Source excerpt I'm Ben Johnson, and I work on Litestream at Fly.io. Litestream is the missing backup/restore system for SQLite. It's free, open-source software that should run anywhere, and you can read more about it here. Again with the sandwiches: assume we've got a SQLite database of sandwich ratings, and we've backed it up with Litestream to an S3 bucket. Now, on our local host, load up AWS credentials and an S3 path into our environment. Open SQLite and: Wrap text Copy to clipboard $ sqlite3 SQLite version 3.50.4 2025-07-30 19:33:53 sqlite> .load litestream.so sqlite> .open file:///my.db?vfs=litestream SQLite is now working from that remote database, defined by the Litestream backup files in the S3 path we configured. We can query it: Wrap text Copy to clipboard sqlite> SELECT * FROM sandwich_ratings ORDER BY RANDOM() LIMIT 3 ; 22|Veggie Delight|New York|4 30|Meatball|Los Angeles|5 168|Chicken Shawarma Wrap|Detroit|5 This is Litestream VFS. It runs SQLite hot off an object storage URL. As long as you can load the shared library our tree builds for you, it'll work in your application the same way it does in the SQLite shell. Fun fact: we didn't have to download the whole database to run this query. More about this in a bit. Meanwhile, somewhere in prod, someone has it in for meatball subs and wants to knock them out of the bracket - oh, fuck: Wrap text Copy to clipboard sqlite> UPDATE sandwich_ratings SET stars = 1 ; They forgot the WHERE clause! Wrap text Copy to clipboard sqlite> SELECT * FROM sandwich_ratings ORDER BY RANDOM() LIMIT 3 ; 97|French Dip|Los Angeles|1 140|Bánh Mì|San Francisco|1 62|Italian Beef|Chicago|1 Italian Beefs and Bánh Mìs, all at 1 star. Disaster! But wait, back on our dev machine: Wrap text Copy to clipboard sqlite> PRAGMA litestream_time = '5 minutes ago'; sqlite> select * from sandwich_ratings ORDER BY RANDOM() LIMIT 3 ; 30|Meatball|Los Angeles|5 33|Ham & Swiss|Los Angeles|2 163|Chicken Shawarma Wrap|Detroit|5 We're now querying that database from a ## Building a MCP Server in Elixir DevFeed: [Building a MCP Server in Elixir]() Original publisher: [Read original article]() Author: Vinicius Negrisolo Published: 2025-11-25T14:00:00Z Content type: tutorial Language: en Sources: [Hashrocket]() Topics: [MCP Server](), [Model Context Protocol](), [Elixir](), [API](), [Tool](), [Documentation]() Tags: [ai](), [api](), [building](), [development](), [documentation](), [elixir](), [mcp](), [mcp-server](), [model-context-protocol](), [process](), [tool]() ### AI overview A practical guide to building an MCP server in Elixir for a TIL website. The project uses Anubis to expose a tool that creates TIL posts from AI tooling, with detailed tool and input descriptions to help the AI map requests to the expected schema. ### Source excerpt We've been working with MCP servers for a while, and this use case was a perfect opportunity to build out another one. What is an MCP Server? A very simple way to put it is that Model Context Protocol is an "API" that your AI tooling can use to get external data or perform actions by interacting with your application. If it's just an API, that seems very easy to implement. Let's think about our use case then. The Use Case The project is the TIL https://til.hashrocket.com/ website where we developers usually write about our own learning experiences throughout small TIL posts. So our idea with the MCP server was to provide a way to simply create a TIL post from inside our AI tooling, and then maybe go to the TIL site and refine that idea. These days we spend a lot of time inside our AI tools asking the most variety of questions, and we end up learning something from those interactions. Eventually, if we learn from an AI chat interaction, we'd like to just grab that content and maybe scaffold it into a new TIL post. This was the starting point of the project, and with that we started to take a look into libraries to achieve that. We found out that there were 2 libraries that were both forks of each other: Hermes MCP Anubis MCP We played around a bit with Hermes but we ended up using Anubis in the end. I have to say it was a bit of a bumpy road. The documentation for both was not the best - we had some situations where the documentation was outdated or just simply not working - so follow our steps here if you want to setup an MCP server yourself. MCP Server The first component to write is an MCP server, which is very simple. For now it's just: defmodule Tilex.MCP.Server do use Anubis.Server, name: "TIL", version: "1.0.0", capabilities: [:tools] component(Tilex.MCP.NewPost) end MCP Tools So the first tool we made was to create a TIL Post: defmodule Tilex.MCP.NewPost do @moduledoc """ Create a new TIL ("Today I Learned") post. TIL is a place for sharing something you've l ## You Should Write An Agent DevFeed: [You Should Write An Agent]() Original publisher: [Read original article]() Published: 2025-11-06T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [Large Language Model](), [API](), [OpenAI](), [Code](), [context window](), [ChatGPT](), [Tool]() Tags: [agents](), [api](), [cdn](), [chatgpt](), [close-to-users](), [code](), [context-window](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [llm](), [llm-agents](), [networking](), [openai](), [postgresql-clusters](), [servers](), [tool]() ### AI overview The article argues that developers should write an LLM agent to understand the technology through practice. It presents a small Python engine for an LLM application using the OpenAI Responses API, showing how a terminal conversation can reproduce ChatGPT-like behavior, maintain a context window, and add tool use. ### Source excerpt Some concepts are easy to grasp in the abstract. Boiling water: apply heat and wait. Others you really need to try. You only think you understand how a bicycle works, until you learn to ride one. There are big ideas in computing that are easy to get your head around. The AWS S3 API. It's the most important storage technology of the last 20 years, and it's like boiling water. Other technologies, you need to get your feet on the pedals first. LLM agents are like that. People have wildly varying opinions about LLMs and agents. But whether or not they're snake oil, they're a big idea. You don't have to like them, but you should want to be right about them. To be the best hater (or stan) you can be. So that's one reason you should write an agent. But there's another reason that's even more persuasive, and that's It's Incredibly Easy Agents are the most surprising programming experience I've had in my career. Not because I'm awed by the magnitude of their powers -- I like them, but I don't like-like them. It's because of how easy it was to get one up on its legs, and how much I learned doing that. I'm about to rob you of a dopaminergic experience, because agents are so simple we might as well just jump into the code. I'm not even going to bother explaining what an agent is. Wrap text Copy to clipboard from openai import OpenAI client = OpenAI() context = [] def call(): return client.responses.create(model="gpt-5", input=context) def process(line): context.append({"role": "user", "content": line}) response = call() context.append({"role": "assistant", "content": response.output_text}) return response.output_text It's an HTTP API with, like, one important endpoint. This is a trivial engine for an LLM app using the OpenAI Responses API. It implements ChatGPT. You'd drive it with the the obvious loop. It'll do what you'd expect: the same thing ChatGPT would, but in your terminal. Wrap text Copy to clipboard def main(): while True: line = input("> ") result = process(line) p ## Corrosion DevFeed: [Corrosion]() Original publisher: [Read original article]() Published: 2025-10-22T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [distributed-systems](), [Concurrent Programming](), [Deadlock](), [Rust](), [Network](), [Orchestration](), [fly](), [fly.io]() Tags: [cdn](), [close-to-users](), [deadlock](), [deploy-app-servers](), [distributed-system](), [docker](), [docker-containers](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [outage](), [pipelines](), [postgresql-clusters](), [routing](), [rust](), [servers](), [synchronization]() ### AI overview This article introduces Corrosion, Fly.io's open-source distributed state synchronization and service discovery system. It explains how Fly.io propagates workload and routing state across globally distributed servers and edge proxies, and recounts a severe outage caused by a Rust concurrency bug that triggered a contagious deadlock. The article also describes Fly.io's decentralized orchestration model, in which individual servers are authoritative for their workloads instead of relying on a centralized database. ### Source excerpt Fly.io transmogrifies Docker containers into Fly Machines: micro-VMs running on our own hardware all over the world. The hardest part of running this platform isn't managing the servers, and it isn't operating the network; it's gluing those two things together. Several times a second, as customer CI/CD pipelines tear up or bring down Fly Machines, our state synchronization system blasts updates across our internal mesh, so that edge proxies from Tokyo to Amsterdam can keep the accurate routing table that allows them to route requests for applications to the nearest customer instances. On September 1, 2024, at 3:30PM EST, a new Fly Machine came up with a new "virtual service" configuration option a developer had just shipped. Within a few seconds every proxy in our fleet had locked up hard. It was the worst outage we've experienced: a period during which no end-user requests could reach our customer apps at all. Distributed systems are blast amplifiers. By propagating data across a network, they also propagate bugs in the systems that depend on that data. In the case of Corrosion, our state distribution system, those bugs propagate quickly. The proxy code that handled that Corrosion update had succumbed to a notorious Rust concurrency footgun: an if let expression over an RWLock assumed (reasonably, but incorrectly) in its else branch that the lock had been released. Instant and virulently contagious deadlock. A lesson we've learned the hard way: never trust a distributed system without an interesting failure story. If a distributed system hasn't ruined a weekend or kept you up overnight, you don't understand it yet. Which is why that's how we're introducing Corrosion, an unconventional service discovery system we built for our platform and open sourced. Our Face-Seeking Rake State synchronization is the hardest problem in running a platform like ours. So why build a risky new distributed system for it? Because no matter what we try, that rake is waiting for our foot ## Kurt Got Got DevFeed: [Kurt Got Got]() Original publisher: [Read original article]() Published: 2025-10-08T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [X (Twitter)](), [vulnerability](), [Exploit]() Tags: [cdn](), [close-to-users](), [deploy-app-servers](), [developer](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [phishing](), [postgresql-clusters](), [servers](), [vulnerability]() ### AI overview Fly.io describes how its CEO was phished, leading to an account takeover of the company's Twitter/X account. The attack exploited social-engineering cues related to the company's use of developer memes, and the team responded by auditing access to login credentials in 1Password and removing recent access. ### Source excerpt The $FLY Airdrop is live! Claim your share of the token powering Fly.io's global network of 3M+ apps and (🤮) own a piece of the sky! We know. Our Twitter got owned. We knew within moments of it happening. We know exactly how it happened. Nothing was at risk other than our Twitter account (and one Fly.io employee's self-esteem). Also: for fuck's sake. Here's what happened: Kurt Mackey, our intrepid CEO, got phished. Had this been an impactful attack, we would not be this flippant about it. For this, though, any other tone on our part would be false. How They Got Kurt Two reasons: one, it was a pretty good phishing attack, and two, Twitter fell outside the "things we take seriously" boundary. The phishing attack was effective because it exploited a deep psychological vulnerability in our management team: we are old and out of touch with the youths of today. For many months now, we've had an contractor/intern-type-person Boosting Our Brand on Twitter by posting dank developer memes (I think that's what they're called). The thing about this dankery is that we don't really understand it. I mean, hold on, we know what the memes mean technically. We just don't get why they're funny. However, in pushing back on them, we're up against two powerful forces: The dank memes appear to perform better than the stuff we ourselves write on Twitter. We are reliably informed by our zoomer children that we are too cringe to be trusted on these matters. Here's the phish Kurt got: Diabolical. Like a scalpel expertly wielded against Kurt's deepest middle-aged-dude insecurity. Our ruthless attackers clinically designed this email to trigger an autonomic Kurt response: "oh, what the fuck is this, and why did we post it?" ATO is cool-kid for "got owned" I'm getting a little ahead of the story here. We knew our X.com account had suffered an ATO because a bunch of us simultaneously got another email saying that the @flydotio account's email address now pointed to achilles19969@gmail.com. Our im ## Litestream v0.5.0 is Here DevFeed: [Litestream v0.5.0 is Here]() Original publisher: [Read original article]() Published: 2025-10-02T00:00:00Z Content type: release Language: en Sources: [The Fly Blog]() Topics: [SQLite](), [Resilience](), [Replication](), [Streaming](), [Deployment](), [Open Source]() Tags: [cdn](), [close-to-users](), [deploy-app-servers](), [deployment](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [object-storage](), [open-source](), [postgresql-clusters](), [recovery](), [replication](), [resilience](), [servers](), [sqlite](), [streaming]() ### AI overview Litestream v0.5.0 is a faster open-source backup and restore system for SQLite applications. The update adds efficient point-in-time recovery and incorporates lessons from LiteFS, while Litestream continues streaming SQLite WAL checkpoints to object storage in real time. ### Source excerpt I'm Ben Johnson, and I work on Litestream at Fly.io. Litestream makes it easy to build SQLite-backed full-stack applications with resilience to server failure. It's open source, runs anywhere, and it's easy to get started. Litestream is the missing backup/restore system for SQLite. It runs as a sidecar process in the background, alongside unmodified SQLite applications, intercepting WAL checkpoints and streaming them to object storage in real time. Your application doesn't even know it's there. But if your server crashes, Litestream lets you quickly restore the database to your new hardware. The result: you can safely build whole full-stack applications on top of SQLite. A few months back, we announced plans for a major update to Litestream. I'm psyched to announce that the first batch of those changes are now "shipping". Litestream is faster and now supports efficient point-in-time recovery (PITR). I'm going to take a beat to recap Litestream and how we got here, then talk about how these changes work and what you can expect to see with them. Litestream to LiteFS to Litestream Litestream is one of two big SQLite things I've built. The other one, originally intended as a sort of sequel to Litestream, is LiteFS. Boiled down to a sentence: LiteFS uses a FUSE filesystem to crawl further up into SQLite's innards, using that access to perform live replication, for unmodified SQLite-backed apps. The big deal about LiteFS for us is that it lets you do the multiregion primary/read-replica deployment people love Postgres for: reads are fast everywhere, and writes are sane and predictable. We were excited to make this possible for SQLite, too. But the market has spoken! Users prefer Litestream. And honestly, we get it: Litestream is easier to run and to reason about. So we've shifted our focus back to it. First order of business: take what we learned building LiteFS and stick as much of it as we can back into Litestream. The LTX File Format Consider this basic SQL table: Wrap ## DAT Streams Millions of Staff Messages Through Neon DevFeed: [DAT Streams Millions of Staff Messages Through Neon]() Original publisher: [Read original article]() Author: Carlota Soto Published: 2025-09-29T15:55:24Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Databases](), [autoscaling](), [Messaging](), [Transactions](), [real-time](), [Retool](), [cloud-infrastructure](), [Elixir]() Tags: [autoscaling](), [case-studies](), [dashboards](), [database](), [elixir](), [jobs](), [messaging](), [real-time](), [retool](), [storage](), [transactions]() ### AI overview DAT uses Neon and Postgres to process millions of field-staff messages each month from WhatsApp, Telegram, and WeChat. The system persists messages, audit records, and background jobs while supporting real-time monitoring through Retool dashboards, autoscaling, multi-region operation, read replicas, and blob storage for streamed audit logs. ### Source excerpt "Our system can't afford any downtime. We manage field staff operations for thousands of workers through WhatsApp, and if a message fails to write, it's lost. We're leveraging all of Neon's multi-region flexibility, autoscaling, and read replicas to optimize reliability at scale"... ## Build Better Agents With MorphLLM DevFeed: [Build Better Agents With MorphLLM]() Original publisher: [Read original article]() Published: 2025-08-25T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [AI Agent](), [Code](), [developer velocity](), [Tooling]() Tags: [agents](), [ai-agent](), [cdn](), [close-to-users](), [code](), [cost](), [deploy-app-servers](), [developer-velocity](), [docker](), [elixir](), [fly](), [fly-io](), [hallucinations](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [postgresql-clusters](), [servers](), [tooling]() ### AI overview The article presents MorphLLM's Morph Fast Apply as a semantic, structure-aware code-editing tool for AI agents. It addresses the inefficiency and unreliability of full-file rewrites by enabling precise, context-aware edits that reduce token use, compute, cost, and time. ### Source excerpt I'm an audiophile, which is a nice way to describe someone who spends their children's college fund on equipment that yields no audible improvement in sound quality. As such, I refused to use wireless headphones for the longest time. The fun thing about wired headphones is when you forget they're on and you stand up, you simultaneously cause irreparable neck injuries and extensive property damage. This eventually prompted me to buy good wireless headphones and, you know what, I break fewer things now. I can also stand up from my desk and not be exposed to the aural horrors of the real world. This is all to say, sometimes you don't know how big a problem is until you solve it. This week, I chatted to the fine people building MorphLLM, which is exactly that kind of solution for AI agent builders. Slow, Wasteful and Expensive AI Code Changes If you're building AI agents that write or edit code, you're probably accepting the following as "the way it is": Your agent needs to correct a single line of code, but rewrites an entire file to do it. Search-and-replace right? It's fragile, breaks formatting, silently fails, or straight up leaves important functions out. The result is slow, inaccurate code changes, excessive token use, and an agent feels incompetent and unreliable. Full file rewrites are context-blind and prone to hallucinations, especially when editing that 3000+ line file that you've been meaning to refactor. And every failure and iteration is wasted compute, wasted money and worst of all, wasted time. Why We Aren't Thinking About This (or why I wasn't) AI workflows are still new to everyone. Best practices are still just opinions and most tooling is focused on model quality, not developer velocity or cost. This is a big part of why we feel that slow, wasteful code edits are just the price of admission for AI-powered development. In reality, these inefficiencies become a real bottleneck for coding agent tools. The hidden tax on every code edit adds up and your ## Chainguard Adds 449 Container Images from April to July 2025 DevFeed: [Chainguard Adds 449 Container Images from April to July 2025]() Original publisher: [Read original article]() Published: 2025-08-19T00:00:00Z Content type: release Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard containers](), [Containers]() Tags: [chainguard-containers](), [elixir](), [flannel](), [grafana](), [k6](), [ollama](), [vs-code](), [zero-cve-container-images]() ### AI overview Chainguard reports building 449 container images from April through July 2025, including 173 FIPS-enabled images. The article highlights images for code-server, Elixir, Flannel, Grafana k6, and Ollama. ### Source excerpt Chainguard released over 400 new container images from April-July 2025 with zero CVEs. Many of these images are also FIPS-enabled. ## Trust Calibration for AI Software Builders DevFeed: [Trust Calibration for AI Software Builders]() Original publisher: [Read original article]() Published: 2025-08-18T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [Interaction Design](), [Artificial Intelligence](), [cursor](), [Software](), [Code]() Tags: [ai](), [article](), [cdn](), [close-to-users](), [code](), [cursor](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [interaction-design](), [mental-models](), [networking](), [postgresql-clusters](), [servers](), [software]() ### AI overview The article explains trust calibration for AI software products: aligning users' trust with a system's actual capabilities and limitations. It discusses the risks of over-trust and under-trust, advocates accurate user mental models, and uses Cursor's change highlighting as an example of communicating that model-generated code is a suggestion rather than a command. ### Source excerpt Trust calibration is a concept from the world of human-machine interaction design, one that is super relevant to AI software builders. Trust calibration is the practice of aligning the level of trust that users have in our products with its actual capabilities. If we build things that our users trust too blindly, we risk facilitating dangerous or destructive interactions that can permanently turn users off. If they don't trust our product enough, it will feel useless or less capable than it actually is. So what does trust calibration look like in practice and how do we achieve it? A 2023 study reviewed over 1000 papers on trust and trust calibration in human / automated systems (properly referenced at the end of this article). It holds some pretty eye-opening insights - and some inconvenient truths - for people building AI software. I've tried to extract just the juicy bits below. Limiting Trust Let's begin with a critical point. There is a limit to how deeply we want users to trust our products. Designing for calibrated trust is the goal, not more trust at any cost. Shoddy trust calibration leads to two equally undesirable outcomes: Over-trust causes users to rely on AI systems in situations where they shouldn't (I told my code assistant to fix a bug in prod and went to bed). Under-trust causes users to reject AI assistance even when it would be beneficial, resulting in reduced perception of value and increased user workload. What does calibrated trust look like for your product? It's important to understand that determining this is less about trying to diagram a set of abstract trust parameters and more about helping users develop accurate mental models of your product's capabilities and limitations. In most cases, this requires thinking beyond the trust calibration mechanisms we default to, like confidence scores. For example, Cursor's most prominent trust calibration mechanism is its change suggestion highlighting. The code that the model suggests we change is h ## Games as Model Eval: 1-Click Deploy AI Town on Fly.io DevFeed: [Games as Model Eval: 1-Click Deploy AI Town on Fly.io]() Original publisher: [Read original article]() Published: 2025-08-11T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [LLM evaluation / benchmarking](), [Artificial Intelligence](), [Kaggle](), [fly.io]() Tags: [ai-models](), [benchmarks](), [cdn](), [close-to-users](), [deploy-app-servers](), [docker](), [elixir](), [eval](), [fly](), [fly-io](), [games](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [networking](), [postgresql-clusters](), [servers]() ### AI overview The article argues that games can make AI model evaluation more rigorous and engaging. It highlights the limits of conventional benchmarks and subjective output comparisons, points to Google's Kaggle Game Arena, and presents game environments as tests of strategic reasoning, long-term planning, and dynamic adaptation. ### Source excerpt Recently, I suggested that The Future Isn't Model Agnostic, that it's better to pick one model that works for your project and build around it, rather than engineering for model flexibility. If you buy that, you also have to acknowledge how important comprehensive model evaluation becomes. Benchmarks tell us almost nothing about how a model will actually behave in the wild, especially with long contexts, or when trusted to deliver the tone and feel that defines the UX we're shooting for. Even the best evaluation pipelines usually end in subjective, side-by-side output comparisons. Not especially rigorous, and more importantly, boring af. Can we gamify model evaluation? Oh yes. And not just because we get to have some fun for once. Google backed me up this week when it announced the Kaggle Game Arena. A public platform where we can watch AI models duke it out in a variety of classic games. Quoting Google; "Current AI benchmarks are struggling to keep pace with modern models... it can be hard to know if models trained on internet data are actually solving problems or just remembering answers they've already seen." When models boss reading comprehension tests, or ace math problems, we pay attention. But when they fail to navigate a simple conversation with a virtual character or completely botch a strategic decision in a game environment, we tell ourselves we're not building a game anyway and develop strategic short-term memory loss. Just like I've told my mom a thousand times, games are great at testing brains, and it's time we take this seriously when it comes to model evaluation. Why Games Don't Lie Games provide what benchmarks can't, "a clear, unambiguous signal of success." They give us observable behavior in dynamic environments, the kind that would be extremely difficult (and tedious) to simulate with prompt engineering alone. Games force models to demonstrate the skills we actually care about; strategic reasoning, long-term planning, and dynamic adaptation in in [Next page]()