Invite codes no longer gate your own accounts. Bring-your-own-account use is free for everyone; cloud Pro stays invite-only.Read the announcement
AnnouncementAugust 9, 2026

To everyone who's been following or using Mirasim:

Over the past few days, Mirasim ended up in front of a much bigger audience much earlier than we'd planned. We were still in private beta and, honestly, nowhere near ready for a wider launch.

Invite codes spread far beyond the small beta group we had planned for. In a very short window, we saw a flood of visits and test requests, along with some unusually aggressive, probing request patterns. Our capacity, reliability, and security systems weren't ready for that volume. Some of you ran into slow loading, failed requests, or Pro benefits that never showed up.

We're genuinely sorry for the rough experience. Whatever the source of the traffic, we should have been better prepared. That's on us, and our users shouldn't have to pay for it.

At the same time, you sent us a huge amount of honest, detailed feedback. A lot of issues that probably wouldn't have surfaced until a public launch showed up early. Thank you to everyone who took the time to try Mirasim, patiently share feedback, or report security issues responsibly.

Here's how access to Mirasim will work from here

Invite codes no longer limit connecting your own accounts to Mirasim — they only limit the cloud Pro service that Mirasim pays for.

Connecting and using your own accounts locally will be free for everyone. You'll be able to connect the Claude Code, Codex, and other model accounts or services you already use, then work across multiple models, Agents, and sessions in Mirasim. Mirasim won't charge for any of this. Third-party subscription or API fees will still follow each provider's own terms.

Cloud Pro access — where Mirasim covers the model usage costs to make things cheaper for users — will remain invite-only and roll out in batches as capacity allows. We'll keep sharing our progress and what opens next, so the rules stay as clear and transparent as possible.

A note on Pro benefits

  • The 1,000 beta users covered by our original promise will still receive one full year of Mirasim Pro. That promise has not changed.
  • Anyone who successfully registered during this wave after we had already passed the original 1,000-user limit will receive one month of Mirasim Pro. This is both to make up for the unstable experience and to thank you for trying Mirasim before it was fully ready.
  • If you've already registered or activated your access but your Pro benefits still aren't showing up, please don't try again. We have the records. We'll verify eligibility and apply the benefits in batches, then share the timing and start-date details.

How the rollout will work from here

Over the next week or two, we'll focus on adding capacity, fixing the entitlement system, tightening security, and working through your feedback one issue at a time. Mirasim remains open. Registration and local, bring-your-own-account access will stay available, while cloud Pro access will roll out in batches as capacity allows.

We're not trying to build yet another model aggregator. We want Mirasim to be an Agent workspace you can keep building in for the long run. Wherever the next leap in Agent capability comes from, you should be able to plug it into the same workflow, switch seamlessly, and use different Agents together. Once you've built something, you can put it in front of simulated users in a real environment and let evidence — not guesswork — tell you what to do next.

We want every leap in what Agents can do to become real leverage for everyone — so you spend less time chasing tools and more time building what you actually care about.

Models will change. You shouldn't have to start over.

Thank you for showing up before Mirasim was fully ready. From here, we'll put these promises into every fix and every update, and work to earn your trust by making Mirasim more stable and more reliable.

— The Mirasim team

Mirasim Documentation

Chapter 06

Branches, reruns and worktrees

Take one conversation two directions, run a turn again, and let parallel agents edit the same repo safely.

Forking a conversation

Any message in a transcript can become the start of a new branch. The branch inherits the full history up to that point, and the prompt you write becomes its first turn — so you can try a second approach without losing the first one or re-explaining the context.

  1. Pick the point where the paths diverge

    Usually the last message before the decision you now doubt. Choose Fork from Here on that message.

  2. Write the alternative as the branch's first prompt

    “Try this with a queue instead of a cron job.” The branch starts a real, separate session — the original keeps running and keeps its history.

  3. Compare, then keep one

    Both branches are ordinary sessions with ordinary diffs. Read both, keep the better one, delete the other. The branch carries a badge showing which session and turn it came from, and the parent lists its branches.

Re-running and editing turns

Sometimes you do not want a branch — you want the same question asked again. Re-run replays a turn, which is the cheapest way to see whether an answer was luck, or to try it under a different model. Editing your own message lets you fix the prompt that produced a bad turn instead of arguing with the result.

Worktrees: parallel agents on one repository

Two agents editing one checkout produce corrupted state and unreviewable diffs. A session can therefore run in its own linked Git worktree — a real checkout on its own branch, created by the agent and tracked by Mirasim — so each agent works as if it had the project to itself.

Worktrees are a Git feature, not a Mirasim invention, so nothing becomes opaque: `git status`, `git diff` and your own editor all still work. Merging a pane's work back is an ordinary merge; discarding it is an ordinary branch delete.

Each workspace on its own branch, with what it is ahead or behind by
The Git panel listing several workspaces, each with its current branch and its ahead/behind counts, beside the composer's workspace picker.

The Git panelEvery workspace at once: which branch it is on, how many files changed, how far ahead or behind its upstream. This is the view that tells you whether parallel work has drifted apart. — this control is not on the captured screen.

The buttons in this panel work — click them to look around.

  1. Turn the worktree switch on in the composer

    It sits beside the workspace and branch pickers, so isolation is a decision you make when you start the session — not a migration you perform later.

  2. Pick the base branch

    The agent switches to it first, or branches the worktree off it. Basing parallel work on the same known-good commit is what keeps the merges boring.

  3. Merge in order, smallest first

    Land the small, mechanical branch, then rebase the bigger one onto it. Two agents that touched the same file are a normal conflict with a normal resolution.

  4. Clean up deliberately

    Deleting a session offers to remove its worktree too. Git refuses while uncommitted changes remain — that refusal is a feature; commit or discard them first.

Something wrong or missing on this page? Tell us