Gacha Pull Planner

A gacha probability simulator can tell someone their odds. That's the easy part, run the Monte Carlo simulation, report the numbers. What it usually can't tell them is what to actually do with those odds. Given where they stand right now, is a different strategy worth switching to, and what would that switch actually change? A raw probability output answers "what are my chances," not "what should I do next," and those are fundamentally different questions.

A full-stack tool. A backend running Monte Carlo simulations over configurable pull strategies and parameters, with a React frontend for interacting with it, along with an AI agent for scenario planning and interpreting results.

• Simulation engine, modeling pull outcomes across strategies with adjustable parameters rather than fixed presets.
• Visualization for how each run went.
• Stats for both successful runs and failed runs, showing what the runs had in common.
• An overall deterministic, non-AI read on the statistics.

• Run comparison, letting a user change a parameter and see the result against their prior run rather than a fresh, disconnected number.

• An interpretation agent, called on top of the simulation to explain results and, on a re-run, explain what changed and why it matters.

• User-adjustable advanced settings, originally hardcoded, later exposed as configurable parameters to make the app game-agnostic.

The first version of the interpretation agent read a single simulation result and explained it using AI. That was solving the wrong problem and was mostly restating the obvious. What users actually need help with was deciding what to do next, and a single snapshot can't answer that.

My core product sense is this. A number by itself isn't an answer. The answer is what changed, and what that means for what to do next.

So the agent was rebuilt around comparison instead of description. The system surfaces deterministic, results-based suggestions, and when a user acts on one and re-runs, the agent interprets the delta between the two runs, not the result in isolation. That's a materially harder interpretation problem than describing one number, but it's the one that actually matches what the user needed.

I built the simulation and comparison logic myself. For the frontend, I wrote specs and technical contracts and directed Claude Code to implement against them, reviewing and modifying the output rather than accepting it as delivered, including a refactor when I decided static parameters should be user-adjustable instead of hardcoded.

Reporting a result is the beginning of the problem, not the end of it. Any system that hands someone a number, a score, a probability, a status, faces the same next question. Compared to what, and what should change because of it. The useful version of an AI-assisted tool isn't the one that describes state most accurately. It's the one that helps someone decide what to do differently.

I used the same instinct, don't just report the current state, surface what changed and what it implies, in the Data SITREP, which tracks entities over time and flags drift rather than showing a snapshot.