A second lookdev, deliberately without erosion. This one is only about navigation, streaming and what generation actually costs while you move. tiles.py is the store: disk-cached int16 tiles, a single background worker, and a priority queue re-sorted by distance from the view on every request, so walking somewhere new abandons the old prefetch order instead of finishing it. WHY IT IS SHAPED THIS WAY, all from measurements in this session: ONE worker, one generation in flight. A tile is a multi-second 85-92% GPU burst. This is the whole contention mitigation, and it is why the page says "one tile generates at a time, by design" rather than trying to look fast. Tiles are generated in ANY order with no knowledge of neighbours. Legitimate only because decomposition-independence was MEASURED: one 512 request vs four 256 quadrants with a cold cache differ by max 1 m, and the step across a join equals the step inside a tile. ONE ramp for every tile, never per-tile. A per-tile ramp makes the map a patchwork that reads as terrain discontinuity -- the same misread as upstream issue #19, and the same bug this repo shipped in the other page yesterday. /api/tile.png NEVER blocks on the GPU. It returns 204 and queues. A request path that waits would stall panning for seconds, and the point of the page is to feel what streaming is like. Disk cache, not the 100 MB in-memory LRU upstream uses. A 256 tile is 128 KB of int16, so ~500 x 500 km is about 340 MB. FIRST THING THE PAGE REVEALED, which is the optimisation lead: At 180 km across, 312 tiles are visible and each 7.68 km tile lands on ~40 screen px -- so it was queueing 343 tiles of full 30 m/px detail to draw them at thumbnail size. Tiles below 48 on-screen px are now neither requested nor faked; the HUD says "too small, not requesting". That band is exactly where the coarse stage belongs: 7.7 km/px, already a separately-indexable InfiniteTensor (world_pipeline.py:1425), just not exposed over HTTP yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>