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
Get helpGet Mirasim

Mirasim Documentation

Chapter 12

Skills, MCP and tools

Package your own way of working as a skill, connect the tools your stack already uses, and let agents drive a browser.

Skills: your knowledge, reusable

A skill is a named, reusable packet of instructions — how to run your tests, how your deploy works, how you like a migration written — that an agent loads when the task calls for it. Skills are how hard-won local knowledge stops living only in your head and your prompt history.

In the composer, `/` lists what is available to this session: your skills alongside the agent's built-in commands. Skills install at global scope (available everywhere) or workspace scope, where they live under `<workspace>/.mirasim` beside your project — so they diff, review and version like any other code.

Managing skills
mirasim ui-cli --port 4970 skill list                       # workspace + global
mirasim ui-cli --port 4970 skill install --source https://github.com/o/r --scope global
mirasim ui-cli --port 4970 skill create --name run-our-tests --scope workspace
mirasim ui-cli --port 4970 skill update --name run-our-tests
mirasim ui-cli --port 4970 skill remove --name run-our-tests
  1. Write it for a capable stranger

    Assume the reader knows software but not your project. The command, the order, the pitfalls, and how to tell success from failure — nothing more.

  2. Keep one skill to one job

    “Run the test suite” and “cut a release” are two skills. Small skills compose; a monolith gets loaded when half of it does not apply.

  3. Let a session draft it, then edit it yourself

    After an agent does something well — a tricky deploy, a clean migration — ask it to write up what it just did as a skill. The edit afterwards is where your judgment enters.

MCP servers

Tools reach agents through the Model Context Protocol. Add a server once — as a local command or a URL, with its own environment — and its tools become available alongside the built-ins. Servers resolve from global or workspace scope, and Mirasim shows both the ones it manages and the ones an agent brought itself.

Add, toggle and health-check a server
mirasim ui-cli --port 4970 mcp list
mirasim ui-cli --port 4970 mcp add --name gh \
  --command npx --args "-y,@some/mcp-server" --scope global
mirasim ui-cli --port 4970 mcp toggle --name gh --enabled false
mirasim ui-cli --port 4970 mcp health --name gh     # live handshake probe

Connectors

Connectors are a curated catalog on top of MCP: install one, hand it its secrets or run it remotely, and enable it per agent so a tool is not forced on every session. Installation is a real lifecycle — validate it against the live service, re-run its OAuth grant when a token expires, and deregister it cleanly, revoking and tombstoning rather than leaving a dead entry behind.

Connector lifecycle
mirasim ui-cli --port 4970 connectors list
mirasim ui-cli --port 4970 connectors install SOME_ID --mode remote --secret KEY=value
mirasim ui-cli --port 4970 connectors enable SOME_ID --agent claude
mirasim ui-cli --port 4970 connectors validate SOME_ID    # records tool count / error
mirasim ui-cli --port 4970 connectors auth SOME_ID        # (re)start OAuth, prints the URL
mirasim ui-cli --port 4970 connectors search "issue tracker"   # the official registry

Beyond the catalog, connector search queries the official MCP registry, so the long tail is reachable without leaving the app.

Extensions, where tools get connected
The Mirasim Extensions settings screen for connecting external tools, with the workbench entry points behind it.

ExtensionsThe curated catalog plus a search into the official MCP registry. Install, hand over secrets, and enable per agent — a tool is never forced on every session. — this control is not on the captured screen.

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

The CLI tools already on your machine

Agents work best in a real environment. Mirasim inventories the common developer CLIs on your PATH — git, gh, docker and the rest — and shows whether each is authenticated, so "the agent couldn't push" resolves to "gh was never signed in" rather than a guess.

What's installed, and what's signed in
mirasim ui-cli --port 4970 cli-tools    # dev CLIs on PATH + auth state
mirasim ui-cli --port 4970 clis         # agent CLIs: version / latest / update available

Browser and screen automation

Browser automation is off by default — an agent gets no browser tool at all until you turn it on. When you do, it always drives a browser running in Mirasim's own profile directory, separate from your everyday browsing, with its own saved logins for the sites a task needs. Your personal browser is deliberately left alone.

For simple things you want done in your own browser on macOS — open a link, take a screenshot, tell a running app to do something — use open, osascript and screencapture directly. That is the recommended route, and it needs no toggle.

Handing browser work to an agent that only does browsers

Driving a browser click by click eats a coding agent's context: every page it looks at arrives as another wall of text it has to carry for the rest of the session. So there is a second route. Pi GUI is a separate agent whose whole job is working a browser, and a coding agent can hand a job over to it instead of doing it itself.

The handover is a tool call — gui_task. State the outcome you want, not the steps: Pi GUI plans its own route, works the pages, and hands back what it found. It runs inside an ordinary Mirasim session, so you can watch it go and stop it. The call waits for the task to settle, up to fifteen minutes.

Every result ends with a session key. Pass it back on the next call and the follow-up continues in the same browser, with the same tabs and the same logins still open — which is what makes a follow-up like now open the second result work at all.

  • Worth delegating: reading across several pages, filling a form, walking a sign-up or checkout flow, pulling data out of a table.
  • Not worth delegating: one look, one click. Do that with the browser tools directly — handing it over costs more than it saves.

Setting PI_GUI_CDP_URL points automation at a Chrome that already exists somewhere else — a container, a remote box. Mirasim then neither launches nor manages a browser locally, and you sign in to whatever that Chrome needs on that machine.

Screen automation is a separate toggle, and on macOS both depend on real system permissions: Screen Recording to read screen content for screenshots and UI analysis, and Full Disk Access to reach protected folders like Desktop and Downloads. The Permissions page walks each one, tells you which app to grant (the app that launched Mirasim), and re-checks on demand — because macOS has no prompt at all for some of them.

Something wrong or missing on this page? Tell us