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 13

Schedules, goals and mission control

Work that runs on a clock, work you hand over whole, and one screen that tells you which of it needs you.

Scheduled prompts

A schedule is an ordinary session prompt on a clock. Same agent, model and reasoning level you would pick by hand; it just dispatches itself. The everyday uses are the small reviews nobody remembers to do: a weekday morning brief of commits, open pull requests and what needs attention; a Friday digest of the week; a recurring check of CI runs and dependency alerts.

  1. Create one from the workspace it belongs to

    Schedules live per workspace, in <workspace>/.mirasim/schedules.json — so they belong to the project, review like code, and travel with the repository.

  2. Write the prompt exactly as you would type it

    There is no separate schedule language. Presets cover the common cadences — daily at 9, weekdays at 9, Mondays at 9, hourly, every 30 minutes — or write a plain 5-field cron expression in local time. The minimum interval is 10 minutes.

  3. Watch it, pause it, or run it now

    Each schedule shows its next and last run and its run history, with a link straight into the session a run dispatched. Pause it without deleting it; trigger a run immediately when you want to test it.

Where schedules and goals start
The schedules surface in the workspace rail, and the composer control that turns a prompt into a scheduled task.

SchedulesThis workspace's scheduled prompts: what runs, when it next fires, and what happened last time. — this control is not on the captured screen.

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

Goals: handing over a whole piece of work

A session is a conversation. A goal is a piece of work with a completion condition, handed to an agent to orchestrate: it splits the work into tasks, dispatches them, drives itself forward, and comes back to you when a call actually needs making. Start one with `/goal` in the composer, describing the objective and what would make it done.

The Goal Room is where you watch it. On one side is the master conversation you shape the goal in; on the other, the contract that conversation produced — the outcome, its testable acceptance criteria, scope, boundaries, explicit non-goals, decisions and assumptions, and whatever is still unresolved. The spec is read-only there, synced from the chat, so there is exactly one place a goal gets changed.

The phases a goal moves through
Aligning
The orchestrator is turning your conversation into a testable outcome and an execution map.
Review → Confirm start
When the outcome, evidence and boundaries are locked, you confirm a specific revision. That confirmation is what authorizes agent work to begin.
Running
Tasks execute against the published map, with a mission graph and board, live status per task, and the critical path called out.
Needs you
Only decisions that change scope, safety, permissions, or an irreversible outcome block progress. It says how many workers a pending decision is blocking.
Acceptance → Complete
Criteria are verified against evidence, not assertions: each node carries its artifact, its verification and the worker record behind it.

Every task node opens onto its evidence — the artifact it produced, whether it was verified, its dependencies and dependents, and the actual work record of the agent that did it. Where a record is missing or unreadable, the room says which and why rather than showing an optimistic summary. You can also add a note about any task, which goes back into the master conversation so the orchestrator continues with that context.

Mission control

When several sessions and goals are in flight, the workbench is the wrong view — you do not want to read five transcripts to learn that one of them stopped. Mission control is one screen for all of it: how many tasks are active, how many need you, how many need attention, how many finished today.

  • Per task: what it is doing right now, its plan, how long it has been on the current step, and an event trail — run started, plan step, sub-agent started or failed, asked you a question, stalled, finished.
  • Liveness in plain words: active just now, active N ago, quiet for N — so a stuck task looks different from a slow one.
  • System notifications when a task finishes, fails, stalls, or needs you, so you can leave the window.
  • Tasks started outside the app show coarse status only, and say so — tasks started here show full live detail.

When nothing is running it says so plainly instead of inventing activity: all quiet, nothing running.

The attention inbox

Mission control answers "what is happening". The inbox answers the narrower and more useful question: what needs me? Each item carries the verb for what you owe it — answer, align, decide, fix, resume, accept — and how long it has been waiting. Ordinary sessions that finished, got stuck, or need a call show up here too.

Clear an item by marking it read, which removes it from your to-dos and leaves the session untouched, or archive it. The promise the inbox makes is the reason to trust it: if it is not here, you do not need to care.

Something wrong or missing on this page? Tell us