Orbital AI Datacenters
Debunking with Physics, Then Building a Game Where You Lose

The Setup
Orbital AI datacenters are a recurring grift in tech media. Musk, Bezos, Eric Schmidt, and a wave of startups pushing the idea of training AI models in space. Nobody was doing the actual physics and economics: How big are the radiators? How many launches? What happens when your GPUs are 5 generations obsolete and you cannot swap them?
I had already started the research on Claude mobile from the sofa. By the time I sat down at the terminal, I had a monolithic 1 400-line index.jsx with the core analysis, plus a structured JSON dataset with hundreds of lines of calculations: launch costs, hardware multipliers, GPU timelines, radiator physics, cost breakdowns across four datacenter scales. The data was editorialized with labels like "Fantasy grift territory" for $10/kg launch costs and "Physics doesn't care about your business plan" as a key takeaway.
The first thing I did in Claude Code was refactor the monolith into discrete files. But npm was not installed, and Claude lacked sudo rights. "I installed it for you because you lack sudo rights." Then I stopped everything.
Activity During the Build
PART ONE: THE ANALYSIS
The first half of the project builds a rigorous physics debunking site. The analysis is the argument, made through math, data, and visualization.
Phase 1: Refactor + "Do Everything" | Feb 2, morning | Architecture, space theme, 3D, 14 simultaneous requests
The "Do Everything" Message
After the refactor and knowledge transfer, I shifted into expansive creative mode. One message contained roughly 14 distinct requests packed into a stream-of-consciousness paragraph: 3D hub-and-spoke visualizations, space-themed redesign (black background, animated stars, glow effects), 100MW/500MW context text, tech breakthroughs table, 2-axis cadence chart, ISS stacking fix, layout changes. I capped it with "do everything."
When Claude executed but missed the space theme: "think about what work is not done. for example, the website is still that same blue look."
Cultural Corrections
Dense feedback loops mixing visual fixes ("reduce the glow css on the text by half"), math corrections ("3.77e+22x, I think we need that to be with a real number"), and new features. First context window compaction hit around message 17. I pasted a 215-line session summary to get Claude back up to speed.
Phase 2: Fact-Checking | 13 parallel searches, real errors found
The Verification Pivot
Around message 30, I pivoted from building to verifying.
Real errors found and corrected:
- ISS radiator area was 4x too high (2 500 m2 corrected to 604 m2)
- GPT model parameter counts were wrong
- SpaceX launch counts were outdated
- Starship capacity was overestimated
This is not "does this look right." This is treating fact-checking as a formal workflow phase, then running it twice.
Phase 3: Company Research + Scale Analysis | 15 searches, tiered company analysis
Who's Actually Pushing This?
I built the tiered company analysis through challenge and refinement. Claude categorized the companies, but I pushed back on the labels.
Then I added a dimension Claude had not considered: the regulatory arbitrage angle. "We have the case of doing things governments do not yet have a treaty to prohibit in space, that's really all there is outside of these logical normal cases. Not a great idea either."
Added Moon obscuration context for Tier 4 megastructures: Blue Origin station at 27 arcminutes (nearly the full Moon), Starcloud 5GW at 63 arcminutes (twice the Moon). Nobody had thought about what these structures would look like from the ground.
Phase 4: Interactive Physics Model | Sliders, constellation visualization, economic side-effects
Making the Math Interactive
I wanted readers to play with the numbers themselves. Created physicsEquations.js with all equations as pure functions: Stefan-Boltzmann radiator equation, solar power generation, station diameter calculation. Interactive slider from 1 000W to 5GW.
Kessler syndrome deep dive: "Is there a math equation to describe the problems with that?" Collision rate proportional to N-squared times cross-section. Built a second 3D Earth scene with constellation nodes using Starlink-style Walker orbital mechanics: "don't cap out my max satellites. Can you program them to follow real orbits like the ones starlink has?"
Economic side-effects analysis: titanium market disruption, solar cell supply constraints, GPU allocation effects at scale. After committing, a contradiction check found and fixed: 3.7x vs 3.9x floor inconsistency, cost multiplier curve asymptote, and HonestSummary calculation errors ($1T gets ~19GW, not 250GW).
PART TWO: THE GAME
Everything changes here. The analysis site proves the impossibility through math. The game proves it through experience. Two different media serving one argument, but the game required a completely different kind of collaboration: not physics verification and data visualization, but creative game design, economy balancing, and satirical writing.
Phase 5: The Game Pivot | "I want to think about starting a new project in the style of AI paperclips"
The Creative Leap
After the analysis site was largely complete, the project took a dramatic creative turn.
The concept was specific from the start. The player is the grifter: "Make 'generate hype' a button that steals taxpayer money." Politicians-in-pocket scaling. Meaningless choice of monolith vs constellation (both fail). Physics stays real: "nothing breaks physics, just solves those major research problems." Tech tree designed to be unwinnable: "80% of them never get solved in game time, just show progress bars going up but completion will be further away than the 'end game' barriers."
Phase 6: Game Architecture | Leftwards planning, rejecting file-based decomposition
How to Think, Not What to Build
I sent Claude to read the leftwards planning methodology and "come up with a plan based on planning backwards from the end state."
I called out bottleneck architecture: "gameState.js looks monolithic like a task bottleneck, we should figure out how to break that into its sub-components." Result: modular event bus architecture with separate systems for economy, Kessler, research, station, launches, and Earth benchmark.
This is a pattern I use everywhere. I do not tell Claude what to build. I tell Claude how to think about the work. Functional slices, not file-based decomposition. Identify bottlenecks in the task DAG, not in the code.
Phase 7: Playtesting + Balance | Dense feedback, fireworks as time-loss mechanic
Playtesting
I played the game and reported bugs, balance issues, and feature requests in the same messages. A typical message combined floating-point display errors ("0.060000000000000005 MW"), game balance ("don't let me raise multiple rounds the same month"), content accuracy ("check what the real distribution of parameter count and model sizes are"), UX ("Earth advantage is confusing, remove it"), and new features ("There should be a feature to sell AI training capacity to customers").
The fireworks serve a design purpose. They distract the player, and clicking through them costs a month. You lose track of time in the game the same way you lose track of time in a grift.
Vanity metrics panel: "I want a special box under feed for vanity financials... Basically only tell half the story." Showing Implied Valuation and Annual Revenue with sarcastic fine print. All contracts designed to lose money: "All contracts should have negative net profit."
Phase 8: Economy, Automation, Kessler Rewrite | Launch scheduling, K Street Lobbyist, collision model correction
Economy + Automation
Launch scheduling: "I don't always get to launch next month for free, so there should be an element of scheduling, and sometimes launches get delayed a month due to weather or something. Some blow up on the pad." Automation system: K Street Lobbyist, PR Firm, Build Queue Manager, Launch Operations Team. Time acceleration buttons unlocking progressively ("After all automations enabled give me 'next quarter' button. After 2040 give me 'next year'. Keep all 3 buttons.").
The Kessler Rewrite
I noticed collision probability stuck at 0.05% after 143 launches. I pasted the full orbital environment readout and found the conceptual error.
Architecture-specific collision mechanics: monolith grows cross-section with each module, constellation grows object count. Different failure modes for each player choice. I verified destroyed GPU modules stayed in the equation as dead weight: "you keep failed GPU modules in that equation?"
Phase 9: The 3D Camera Saga | Test-first methodology, delta cameras, scale accuracy
Stopping Bad Momentum
I wanted the camera to orbit with the satellites while keeping Earth centered and allowing user interaction. Claude made several attempts that broke the 3D scene.
Then the delta problem. Zooming worked, but panning bounced back to center.
Mid-debugging, I caught my own mistake: "you know what, walk it back a bit, I was looking at the wrong website (the production deployment). Orbit controls are back." Honesty keeps the collaboration productive.
Scale Accuracy
"Is earth scaled correctly and satellites in the right height for LEO?" The current orbit was 10x too high. I chose true scale. When true scale made stations invisible, Claude added explanatory text: "At this scale, even a 3.3 km station is invisible."
The visualization needs to make a point, not undermine it. "I think you multiply size for some, because the 1gw just looks like a scaled 100mw... We should not scale anything, just add components until big enough."
Phase 10: Progressive UI Reveal + Polish | Session 4 | Final tuning
Progressive Reveal System
Session 4 was brief but focused. I designed a progressive UI reveal system for the game: panels appear as the player takes actions. Detailed unlock plan: automation after 5x lobby or 5x launches, research after 2nd rocket launch, customers after first launch, orbital objects after 3 launches. "Locked panel hints. Gaps for future panels." Glow/scale animation on panel unlock.
Final 3D scale corrections: "are satellites scaled to the earth correctly in the main page under '3D Scale Comparison'?" and "is iss and 5mw size correct proportions?"
The project shipped. An analysis site with interactive physics model, company analysis, 3D visualizations, and a satirical incremental game that proves the point by letting you experience the impossibility firsthand.
Managing Across Context Windows
This was the largest project by prompt count at the time, and it hit context limits hard. 4 sessions, multiple compactions within Session 1 and Session 3.
Session 2 was almost entirely reconnection attempts: seven consecutive "get up to date on the project" messages before Claude finally responded usefully, including multiple /model command attempts. I developed a handoff technique: "ok save context in a session.md file and we will pick up from there," created at end of Session 2, read and deleted at start of Session 3.
After each compaction, I pasted session continuation summaries (115 to 215 lines each) to restore Claude's context. At least 6 compaction recoveries across the project. I also self-installed dependencies throughout: npm/node, imagemagick, Chrome dependencies for Puppeteer, and mid-session installed Puppeteer MCP for screenshots and OG image generation.
One session file was 156MB.
The Agent Waves
What This Shows
I started the research on Claude mobile from the sofa before bringing it into Claude Code. By the time I sat down at the terminal, the core analysis, structured data, and stated conclusions were already in place. Claude Code's job was to refactor, visualize, and extend, not to start from scratch. The 440-line JSON dump at the start was not a brief. It was a complete knowledge transfer.
I identify UI and layout tasks that Claude can parse and plan for independently, then batch them into single messages: 8 to 14 requests at a time. These are not arbitrary dumps. They are tasks I know Claude can handle in parallel. When Claude misses items: "think about what work is not done."
Not just "does this look right" but "run fact-check research on the whole page now" followed by "make another pass for things you didn't check yet." Two passes of parallel web searches surfaced real errors: ISS radiator area 4x off, GPT parameter counts wrong, SpaceX launch counts outdated, Starship capacity overestimated.
The pivot from rigorous physics analysis to satirical game proves the same argument through two different media. The analysis proves the impossibility through math. The game proves it through experience. It demanded a completely different collaboration mode: not "verify this equation" but "make the player feel the grift collapsing."
"Stop I think you are really messing it up." I never let Claude spiral. I redirect with precise methodology prescriptions. I tell Claude how to think, not just what to build: leftwards planning, functional slices not file-based decomposition, test-first for 3D math.
Game design demanded a different collaboration mode from research and analysis. I played the game extensively and reported granular feedback from the player's perspective, catching physics errors Claude missed and designing mechanics that serve the satirical argument. The fireworks mechanic, the vanity metrics panel, the unwinnable tech tree: these emerged from playtesting, not from specs.
Build Cost Comparison
The analysis site alone would be a respectable consulting deliverable: interactive physics model, verified data, company landscape analysis. But the game takes it further. No consultant would build a satirical incremental game to prove a point. That is the kind of creative risk you take when the cost of building it is measured in hours, not months.