Fable 5 is the rare launch where the capability claims and the caution flags are both true. We read the launch-week reviews — named engineers, independent labs, the HN threads — and sorted them for one reader: the person deciding whether their team switches. Short version: move your hardest, longest, best-specified work onto it; leave your defaults alone; and never take its word for what it tested.
A 13 GB GPT-OSS-20B inference container: 571s → 40.65s. A 2.4 GB Llama-3.2 container: 91s → 7.4s. Same hardware, same app, only the image format and snapshotter config changed.
The obvious first move — lazy loading — made things 66% slower. The biggest single win came from a stack of hidden config knobs we had to read the snapshotter's Go source to find. The last bottleneck wasn't in containerd at all; it was the AWS EBS default write ceiling.
If you ship LLM images and your cold start is over a minute, this is for you.
If you ship a multi-gigabyte ML container — Hugging Face weights baked in, PyTorch + transformers, a FastAPI server — and you've watched the deploy take five-plus minutes from docker run to first inference, this post is the playbook we wish we had.
Linux provides a native Asynchronous I/O (AIO) API that should theoretically allow true background file operations. Yet popular frameworks like Node.js and Python's asyncio avoid it entirely, relying instead on thread pools with blocking I/O. Why? The answer reveals important lessons about API design, cross-platform compatibility, and the gap between theoretical elegance and practical engineering. The future may lie in io_uring, a modern interface that addresses many of AIO's shortcomings.