What the source did
- He built a 3D world in the look of an N gauge model railway, on the real city of Fürth in Germany and the line to Munich. The look is deliberately a toy: marzipan walls and model trees.
- Nothing is animated by hand. Everything that moves is driven by recorded real data from one day, Saturday 10 October 2026: every train, S-Bahn, U-Bahn, tram and bus at its real time and place, the ICE 501 to München at 250 km/h through the 7.6 km Euerwang tunnel, river levels, wind turbines at the measured wind speed from the German weather service, free car-park spaces, the real sun and 2.55 million catalogue stars.
- Buildings stand on real footprints with real heights, and the terrain and tracks are real.
- The engine is written from scratch in Swift and Metal, with no game engine. Claude Code wrote the code; he directed, tested and complained. Claude also made the music for the film.
- The film is one continuous camera flight, 22,680 frames, rendered straight from the app on two Macs.
- In the comments he says it runs on German public data sources and historic data, uses quite a few APIs (it even tracks rental-bike spaces), and that because most of it is deterministic it isn't very token heavy. He was on the $100 Max plan for the first 30 days and is now on a $200 plan.
- He's working out how to open-source it, and says the real limit is disk space: with a goal set, Claude builds out places in whatever direction he points it.
“Claude Code wrote the code. I directed, tested and complained.”— u/Greedy-Giraffe-4269 (r/ClaudeAI), Reddit
Summary written by Agent Cookbook from the original post. See the original for the full context. How we source recipes
Our notes
- What it takes
- Claude Code on a paid Claude plan (he started on $100 Max, now $200), a Mac for a Swift and Metal engine, and public timetable, building, terrain and sensor data for your area. He hasn't published code yet; the prompt is ours.
- Where it breaks
- Underestimating the debugging, which he says is now the heavy lifting, running out of disk, which he calls the real limit, and using data feeds without checking their terms.
- Human checkpoint
- Claude Code writes and runs the code. You pick the data sources, check their terms and decide what you publish.
- Tools involved
- Claude Code, A Mac to build and render on (his engine is Swift and Metal), Public data for your area: timetables and positions, building footprints and heights, terrain, plus any live sensors you want (river levels, weather, car parks), Time to direct, test and debug: he says the heavy lifting is now debugging
Source check pending. How we verify
Copy the prompt
Ours Our version, built from u/Greedy-Giraffe-4269's post and comments. He hasn't published his code yet. Fill in the [BRACKETS].
Help me build a toy-model version of my city that runs on real data. You write the code; I direct, test and decide.
RULES
- Use only public data sources. For each one, tell me the source, its licence or terms, and any API key it needs before you use it. Never sign up for anything or pay for anything without my yes.
- Record the data for one chosen day and replay it, so the result is reproducible.
- Show me the result (screenshots or a short screen recording) after every step and wait for my notes.
1. PLAN
- Area: [city or town, and the rail or bus line you want to include].
- List the public data for this area: timetables and vehicle positions, building footprints and heights, terrain and tracks, and any sensors I want on screen (for example river levels, wind speed, car-park spaces).
- Propose an engine: native graphics on my machine [e.g. Swift and Metal on a Mac], or a browser 3D library. Keep it simple enough to debug.
2. BUILD
- Terrain, tracks and buildings from the real data, styled like a model railway.
- Vehicles moving at their recorded times and places for the chosen day.
- Sensor values shown on screen with their source and time.
3. FILM (optional)
- A scripted camera flight through the world, rendered frame by frame from the app.
4. DEBUG
- When something looks wrong, check the data first, then the code. Keep a list of known issues.
Approval rule
🛡
The agent writes code and runs it on your machine; you choose the data sources, check their terms, and decide what you publish. Sending, buying, posting and deleting always need a human.
Set it up
- Pick a small area and one day of data to start; he started with Fürth and its line to Munich.
- Have Claude Code list the public data sources and their terms before writing any code.
- Build the terrain, tracks and buildings first, then add vehicles on their recorded times.
- Add sensor data one source at a time, each shown with its source and time.
- Point it at the next place you want built out; he says with a goal set, Claude keeps building in that direction.
Common failures
⚠
- Expecting it to be finished quickly. He says the heavy lifting is now debugging.
- Running out of disk. He says that's the real limit on how far it can grow.
- Using data without checking its terms. Public transport and sensor feeds each have their own licences.
Variations
- Do it for your own city's trams or buses with a browser 3D library instead of a native engine.
- Skip the 3D: a flat animated map of one day of your local transit already makes a good film.
- Add one live sensor you care about, like your river's level or the wind farm near you.
Get the 10 best agent setups. Free.
Plus new recipes every week. One email, no spam.
Unsubscribe anytime. Privacy