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

WritingAugust 13, 2026

Two agents, one repository

The moment you run a second coding agent on the same checkout, the two start overwriting each other. Linked git worktrees are the fix, and they are why parallel sessions are usable at all.

6 min read

What actually goes wrong#

One coding agent in a repository is a solved problem. Two is not. Both agents hold the same working tree, and neither knows the other exists: one checks out a branch while the other is mid-edit, one stages a file the other just rewrote, a test run picks up half of someone else's change. Nothing crashes — the failure is quieter and worse than that. You get a diff that no single agent intended and no one can explain.

The usual workarounds are worse than they look. Cloning the repo per agent duplicates the whole history and cuts each clone off from the others' branches. Serialising the agents throws away the reason you wanted two. Telling each agent to "only touch these files" is a rule with no enforcement behind it — the first time one of them is wrong about the boundary, you are back to the unexplainable diff.

Linked worktrees: one repository, several checkouts#

Git has had the answer since 2.5. `git worktree add` gives you another working directory backed by the same object database and the same refs — a second checkout, not a second repository. Each worktree sits on its own branch and has its own index and HEAD, so two agents editing in two worktrees cannot see each other's uncommitted work, cannot stage each other's files, and cannot move each other's branch.

What they do share is everything that is expensive to duplicate: objects, history, remotes, and every branch either of them has ever made. So the work stays mergeable. Agent A can branch from what agent B pushed an hour ago; you can review both diffs against the same base; nothing has to be reconciled across clones afterwards.

What the isolation looks like by hand
# one repository, two checkouts, two branches
git worktree add ../feature-a -b feature-a
git worktree add ../feature-b -b feature-b

# each has its own HEAD and index; the objects are shared
git worktree list

Why this is wired into sessions#

Doing the above by hand is fine for two branches and tedious for six. So in Mirasim a session can start in its own linked worktree, on a base branch you pick, and the pane you are looking at is that worktree — the file tree, the terminal, the diff and the commit you review all belong to it. Up to six panes run at once, each in its own worktree.

The part that matters in daily use is that you stop thinking about it. You are not remembering which terminal is on which branch, or which agent was told to stay out of which directory. Each pane is a place where one agent works, and the isolation is a property of the place rather than a rule the agent has to honour.

One thing worth saying plainly: parallel sessions are several agents working at once, each on its own task. They are not an orchestrator dividing one task among workers. Nothing here plans across the six panes or merges their output for you — you do that, at review time, with the diffs in front of you.