{"slug": "claude-code-s-renderer-is-more-complex-than-a-game-engine", "title": "Claude Code's renderer is more complex than a game engine", "summary": "The article compares the computational complexity of Claude Code's terminal user interface (TUI) renderer to that of Super Mario 64 (SM64), questioning whether Claude Code does more work per frame than the classic N64 game. The author notes that despite both programs rendering at similar resolutions and frame rates, Claude Code causes significantly more CPU strain on modern hardware than emulating an entire N64. Performance analysis reveals that Claude Code spends much of its time on `futex` syscalls, indicating heavy use of locking and synchronization mechanisms.", "body_md": "One of the maintainers of Claude Code said something extremely funny on the internet.\nI’m not here to dunk on this person who is clearly earnest and well-intentioned. I have thought and said far worse, far more confidently.\nBut…how silly is it? Clearly, comparing Claude Code to Grand Theft Auto 6 is not fair. The author did specify a small game engine, and even the most brittle, sun-bleached of straw men would concede that that’s not what they meant.\nBut as I walked down the hierarchy of modern games, nothing felt like a fair comparison. Modern games are just too complex to be intelligibly compared to a TUI. There must be a game which makes this comparison of Claude Code to a game engine be more correct.\nhow about super mario 64?\nSuper Mario 64. A classic in 1996 as much as it is in 2026, and a staple of the speedrunning community thanks to its tight controls, just-right number of glitches and exploits, timeless level design. And, more relevant to our purposes, it ran on a fucking N64. That’s right, baby. Check out these specs:\nThe worlds within the paintings in Peach’s Castle were bouncy, lit with life and color, and all on these meager specs. This felt like a fairer shake. Thus, our question.\nIs Claude Code doing more work in producing and rendering one of its diffed frames than Super Mario 64 did to produce and render a frame of its gorgeous-but-primitive 3D world? If so, what the heck is it doing?\napples to ubermensch\nLet’s get a few things out of the way. This comparison isn’t as much apples-to-apples as it is apples-to-theoretical-space-marine-ubermensch. In other words, not even the same species. The hardware these two programs run on could not be less alike. One kind of hardware can emulate the other, in software, like a gape-jawed matryoshka doll.\nAnd yet, von Neumann sired them both, so we can make some ill advised comparison. More importantly, it feels like these programs should be in some way comparable:\n- SM64 renders natively to 320x240, which is in the same ballpark as a terminal on my 27 inch 2K monitor\n- SM64 has a much simpler graphics pipeline than any modern game; for our purposes, we can almost treat the whole darn thing as one compute unit and compare to CC’s CPU rendering1\n- Most important, they feel vaguely comparable to me, in an abstract how-hard-is-this way.\nBoth of these programs render at similar cadences; SM64 at 30 frames per second, CC at 60. This could be misleading, though; my last published Steam game, Deep Copy\n2, locks itself to 60FPS, but most of that time is spend idling to sync with the GPU. CC has to lay out a bunch of components, diff them, and render. SM64 has to lay out a scene graph and render. CC has to call out to the network, but SM64 has to deal with constantly swapping things in and out of limited VRAM. And so perhaps we have found our example; our small game engine which is more like Claude Code than, say, sl\n.\nBut…this doesn’t feel right. CC makes the fans on my water cooled3 9950X scream, scream more than emulating an entire N64. I don’t know what it’s doing, but it sure as hell isn’t idling. And thus our first question.\nwhat the heck is claude code doing?\n▐▛███▜▌ ▝▜█████▛▘ ▘▘ ▝▝\nperf stat -p PID -- sleep 3\non itself, so that it’d be chugging away while it was measuring. An apt level of rigor. It spit out these numbers:OK. It’s using the CPU 26% of the time – not sleeping, not pegged. “It’s waiting for IO” is a reasonable theory for something you’d expect to be a couple of terminal control codes bolted onto a sophisticated HTTP API.\nWe can run strace\nto see what syscalls it’s making; for the uninitiated, the humble syscall isn’t much more than the API of the operating system. Since your program runs within the OS, everything it does that isn’t raw computation eventually boils down to a syscall. We’ll be able to see what it’s actually doing.\nthe aptly named futex\nNext up: sudo strace -f -c -p PID\nfor a reasonable period of time.\nAh…of course. futex\n. The building block of locking on Linux; it’s what you’d use to write a mutex\n, one layer lower. And Claude Code is spending 70% of its time spinning on one, like Tantalus, one must imagine, having the data in sight but pulled back at the last moment.\nWaiting on futex\nisn’t inherently bad, though. The real problem is the third entry in the table. We called sched_yield\n89,000 times. Those threads aren’t waiting, they’re spinning, and when what they want isn’t ready, they’re all trying to throw the hot potato back to each other.\nthe right way to wait\nAt this point, something’s clearly wrong. We can use ps\n(of ps aux | grep whatever\nfame) to see a flattened process tree:\nNotice the main thread and the HTTP client thread sitting in do_epoll_wait\n. This part is what you would expect for a correctly IO bound program; you do something, but it’s not ready yet, so you use an OS primitive to say that you’d like to wait until it is. There are a bunch of different flavors of this, each solving a limitation of the previous as computers scale (select\n, poll\n, epoll\n, io_uring\n).\nBut CC is yield\ning. 89,000 times. We know this is wrong because:\n- A thread doing work doesn’t\nyield\n, because it’s doing work. - A thread that’s waiting doesn’t\nyield\neither, though, because it uses one of those OS primitives.\nis this just javascript?\nLet’s be fair to CC, though. The main thread looks like it’s doing the right thing. You might think that this is an ecosystem thing; some problem in the design of Node, or Bun’s code, or V8, or whatever. I fired up amp\nto compare:\nNow that’s how you wait! Just look at the sheer difference in the number of calls. That alone tells you all you need to know, setting aside the correctness of those calls.\nwasn’t this about super mario 64?\nRight, right. We buried the lede a bit trying to figure out what CC was doing with the 4.6 billion instructions that were executed in its name; we forgot that the 4.6 billion was the number we were after in the first place.\nThis is the number of instructions that CC uses to:\n- Monitor the output of a process\n- Re-render, diff, and draw its component tree\n- Stream a response over HTTP\n- Pipe god knows what telemetry, feature flags, A/B tests4\nHow many instructions does it take SM64 to render some representative frame? Well, because I’m not Kaze Emanuar5, we’re just going to ballpark it. Take the aforementioned N64 specs, and let’s crank out something reasonable based on maxing out the hardware:\nThese numbers are surely very incorrect; SM64’s frame time is dominated (ironically) by IO. That 4MB of VRAM is hotly contested, and it even has to fit the framebuffer itself. That means a lot of swapping things in and out of memory, which means a lot of waiting around for things to be swapped in and out of memory.\nFor a real estimate, we might cut that in a quarter or even an eighth.\nbut we’re not going to do that\nBecause at this point, the numbers are flat out embarrassing. CC is using an order of magnitude more instructions on a 33ms “frame” basis than SM64 did to render a 3D world. This is about the best apples-to-apples comparison I could come up with; note that “number of instructions” in some sense is independent of the power of the hardware. An add is an add, after all.\nThis is, of course, blatantly untrue. Modern processors do stuff like executing instructions out of order, or guessing which branch your code will take to get a head start, or pipeline code. The amount of “work” that one instruction does on a modern processor is, again, almost incomparable to the N64’s.\nAnd yet, it tells us something.\nno hugging, no learning\nClaude Code is churing out an order of magnitude more instructions than SM64 did, to…diff a terminal panel’s worth of text and draw it. Of course, I get it; that simple diff is being fed by content from an HTTP server, running on top of the most sophisticated JIT ever created, running inside not a terminal but a terminal emulator, and, and, and…\nI get it. The embarrassing part is “why has no one looked into the nearly 30,000 erroneous syscalls being issues every second” in one of the most valuable programs in the world. There has clearly been a loss in systems programming; knowledge once possessed and now not. I think this is because of money. There’s a lot of money in systems programming, in genuine innovation powered by a deep understanding of how the computer beneath you works.\nThere is a lot more money in application programming. A lot. Why make a modestly successful business improving on some systems-level tech when you could moonshot a frontier model and make literally a trillion dollars? Or take a quick exit on ai.pets.com\nand buy a lake house for your just-retired folks?\nI pass no judgment upon Anthropic for being application developers. Besides, that’s what you do with all the money. You pay a billion dollars for the excellent folks at Bun to come on and fix your systems-level woes6.\nIt’s fine to say you don’t know why your TUI is so slow; it’s fine to prioritize making a trillion dollars over doing good quality systems programming. I say that without a hint of irony; I would do the same.\nBut…don’t pretend you’re building a game engine7.\nfootnotes\nWholly inaccurate on the N64, mind. It absolutely has dedicated graphics hardware, and a fairly impressive to my modern eyes ~512MB/s of theoretical memory bandwidth to its 4MB of shared memory. And, as we’ll see, thinking of SM64 as a compute bound program is blatantly false. But this actually works better than I’d hope for the sake of comparison! ↩︎\nI write small games, from scratch, and therefore small game engines. My last such was Deep Copy, a Dick-meets-Pynchon-esque romp through the hand painted lab of a dark Colonel Kurtz styled scientist (which description even the strongest, coldest-tempered of steel men would concede is ambitious at best). Let me tell you, Deep Copy didn’t do a hell of a lot more than paint textured quads onto a screen. ↩︎\nAIO, but still… ↩︎\nSerious, check out\n~/.claude/statsig.json\n. Fascinating stuff. Claude’ll pick it apart for you. ↩︎Famed hacker of SM64; basically ripped apart the engine and rebuilt it from the ground up. He squeezed a lot of performance out of the N64. Check out some of the levels he has running natively on an N64 properly pushed to its limits. It’s incredible. ↩︎\nAnd by all accounts, it seems like this is exactly what is happening ↩︎\nAh fuck. That ended up being a dunking. I apologize to anyone offended; I really do mean that I cast no judgment, and I really do mean it when I say the OP of the tweet was earnest, well meaning, and, in a meaningful sense, not altogether wrong. ↩︎", "url": "https://wpnews.pro/news/claude-code-s-renderer-is-more-complex-than-a-game-engine", "canonical_source": "https://spader.zone/engine/", "published_at": "2026-02-02 00:00:00+00:00", "updated_at": "2026-05-23 05:39:05.644770+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "artificial-intelligence"], "entities": ["Claude Code", "Grand Theft Auto 6", "Super Mario 64", "N64"], "alternates": {"html": "https://wpnews.pro/news/claude-code-s-renderer-is-more-complex-than-a-game-engine", "markdown": "https://wpnews.pro/news/claude-code-s-renderer-is-more-complex-than-a-game-engine.md", "text": "https://wpnews.pro/news/claude-code-s-renderer-is-more-complex-than-a-game-engine.txt", "jsonld": "https://wpnews.pro/news/claude-code-s-renderer-is-more-complex-than-a-game-engine.jsonld"}}