Building AltiVerse: A Local-First Alternate-Reality Simulator and fully opensource
I’ve been building an open-source project called AltiVerse.
Github: https://github.com/LeoTheAIDev/Altiverse
The idea started with a question:
What if you could take one decision, fork it into several alternate versions, and watch how each one plays out?
Not as a prediction engine. Not as a magic AI oracle. More like a structured way to think through second-order effects.
For example:
What happens if a school bans phones?
What changes if a company moves to a 4-day work week?
How do 8-hour and 12-hour hospital shifts affect burnout?
What happens if an office goes fully remote instead of hybrid?
AltiVerse lets you create scenarios like these, fork the decision into multiple realities, and watch each one evolve as a small simulated world.
What AltiVerse does
AltiVerse takes one decision and creates 2–4 alternate realities from it.
Each reality has the same baseline setup, but a different policy.
For example, in a school scenario, one reality might confiscate phones at the door, while another lets students self-regulate. The same students exist in both worlds, but their outcomes can diverge over time.
Each simulated person has traits, moods, relationships, stress, burnout, rule-breaking tendencies, friendships, rivalries, and changing wellbeing.
The goal is to make the consequences of a decision easier to explore visually.
Instead of only seeing a spreadsheet of metrics, you can watch the worlds run side by side, click on individual people, and compare how they are doing across different branches.
Why I built it
Most decision-making tools are either too abstract or too static.
A spreadsheet can show numbers, but it does not show how the same individual might experience two different policies.
A written report can explain tradeoffs, but it usually hides the messy interactions between people.
I wanted to build something more dynamic: a small “living” simulation where decisions create visible consequences over time.
AltiVerse is not trying to tell you what will definitely happen. It is trying to help you ask better questions:
Who benefits from this policy?
Who gets hurt?
When do the different realities start to diverge?
Which metric changes first?
Does the average hide a group that is struggling?
Are there second-order effects that would be easy to miss?
The core idea: same people, different realities
One important design choice is that the same person exists across every reality.
So if there is a student called Maya in the phone-ban scenario, Maya exists in both branches:
Maya under strict phone confiscation
Maya under student self-regulation
That makes comparison more personal. You are not just comparing averages. You can inspect how one individual changes across different policies.
This also makes the UI more interesting. Clicking on a person opens a cross-reality card where you can compare mood, wellbeing, relationships, and generated thoughts across timelines.
Tech stack
AltiVerse is built with:
Vite
React
TypeScript
localStorage
a deterministic simulation engine
an optional OpenAI-compatible LLM layer
There is no backend.
There is no telemetry.
It runs offline.
The whole project is local-first by design.
Deterministic simulation
The simulation engine is deterministic.
That means the same setup with the same seed produces the same world every time.
This was important for a few reasons:
Debugging is easier.
Users can replay a run and get the same result.
Different realities can branch from a shared baseline.
You can reseed the simulation to explore variations without changing the whole scenario.
The engine uses a seeded pseudo-random number generator. Each branch gets a derived seed, so realities can evolve independently while still being reproducible.
This creates a useful balance: the world feels alive, but it is not random in a way that makes it impossible to inspect.
Local-first architecture
I wanted AltiVerse to run without accounts, servers, or setup friction.
The app stores runs, presets, history, and configuration in localStorage.
That means:
no login
no database
no backend
no server costs
no uploaded data
no telemetry
For a project like this, local-first felt like the right architecture. The scenarios people create could involve schools, workplaces, hospitals, or other sensitive contexts. Even if the data is fictional, it still felt wrong to require a backend.
Optional LLM layer
The simulation does not require AI.
The deterministic engine can run fully offline without a model. But AltiVerse also has an optional LLM layer for generating prose.
The LLM can help with:
creating a scenario from a short description
writing in-character thoughts
generating daily headlines
answering questions as a simulated person
explaining metric changes
producing a final report
The app speaks to any OpenAI-compatible /chat/completions endpoint.
That means it can work with:
Ollama
LM Studio
llama.cpp
OpenAI
OpenRouter
Groq
Together
other compatible providers
If you use a local model, nothing leaves your machine. If you use an online provider, the request goes directly from your browser to that provider.
There is no AltiVerse backend in the middle.
UI challenge: making simulation understandable
The hardest part was not just building the engine. It was making the simulation understandable.
A lot is happening at once:
multiple realities
many agents
rooms
movement
metrics
daily events
relationships
divergence over time
causal chains
reports
The UI has to show enough to feel alive without becoming unreadable.
The main studio view shows the alternate realities side by side, with synchronized time controls. Users can play, pause, step through days, scrub the timeline, and inspect people or metrics.
I wanted the user to feel like they are watching several small worlds evolve from the same starting point.
Reports and exports
At the end of a run, AltiVerse can generate a report.
The report includes:
an executive summary
metric comparisons
in-character interviews
causal explanations
a recommendation
export to Markdown or PDF
Again, the recommendation is not meant to be treated as truth. It is a structured summary of what happened inside that simulation run.
The value is not “the app knows the answer.”
The value is “the app helps you see tradeoffs more clearly.”
What I learned
A few things stood out while building this.
First, deterministic systems are extremely useful for interactive simulations. Reproducibility makes the project easier to test, debug, and explain.
Second, local-first design works well for experimental tools. Not every project needs a backend immediately.
Third, LLMs are often more useful as a narrative layer than as the core engine. In AltiVerse, the model is not responsible for the simulation logic. The model writes and explains, but the deterministic engine decides what happened.
Fourth, visualizing second-order effects is hard. Averages are easy. Showing individual experience, group effects, divergence, and causality at the same time is much harder.
Try it
The project is open source and MIT licensed.
You can run it with:
npx github:LeoTheAIDev/Altiverse
Or clone it:
git clone https://github.com/LeoTheAIDev/Altiverse.git altiverse
cd altiverse
npm install
npm start
GitHub:
https://github.com/LeoTheAIDev/Altiverse
What I’d like feedback on
I’m still figuring out what AltiVerse is best described as.
It could be:
a simulation toy
a local-first AI demo
a policy-thinking tool
a visual decision-making tool
a research prototype
a strange game-like dashboard
I’d love feedback on:
Is the concept clear?
Does the UI make the branching-world idea understandable?
What scenarios would be most interesting to simulate?
Should the project lean more toward research, education, civic tech, or entertainment?
What would make you want to contribute?
The project is still early, but I think there is something interesting in the idea of making decisions visible as branching worlds instead of static pros and cons lists.