Skip to main content
Mythos keeps every project in a private GitHub repository it manages — one repo per project. Each build and each edit lands as a real commit with a real message, so your project has a full version history you can browse and roll back. Connect your GitHub account and export to your own GitHub anytime: you get a clean repository that is yours to clone, edit, and host anywhere. (Mythos keeps its own internal build copy.)
Cost: the repo and its commits are part of building and editing. A new project costs 3 credits, an edit 2. There is no separate charge for Git. See Credits & pricing.

Why this matters

  • A real history. Every change is a commit, so you can see exactly what the agent did and when.
  • Roll back safely. Reverting to an earlier commit creates a new commit that restores the old state — it never rewrites history, so you can always undo the undo.
  • Take it with you. The code is standard React/Next.js in Git; after a one-time GitHub connect you can export it to your own GitHub account.

How commits work

1

First build creates the repo

When you create a project, Mythos creates its private repo and seeds it, then commits the scaffold, the AI’s code, and any generated images.
2

Each edit is a commit

Every later edit commits only the files that changed, with a descriptive message.
3

Browse and roll back

Use the project history to review past commits and revert to any earlier point. A revert is a new commit, so nothing is lost.
4

Export to your own GitHub

Connect your GitHub account once. Mythos creates a private repo under your account and pushes the project into it. From then on, every later build auto-mirrors to that repo, so your copy stays in sync.

Where your repo lives

Mythos creates and manages each project’s repo in a Mythos-controlled GitHub organization — separate from your personal account — so the agent can commit to it on every build. When you connect your GitHub account, Mythos also creates a private repository under your own account or organization and keeps it mirrored: that copy is fully yours to clone, edit, and host anywhere.
The repo name is derived from your project’s name (transliterated to Latin, so Cyrillic and accented names still produce a readable slug). Reverting and editing inside the workspace keep the repo in sync; the exported mirror reflects the project’s current state.

What’s in the repo

A normal React (Vite) or Next.js project: your components, your Tailwind styles, the public assets, and — once you connect Supabase — the integrations/supabase/* client and a committed .env holding your project URL and public anon key.
The committed .env contains only public values (your Supabase URL and anon key), which are safe to store in the repo. Your Supabase service role key and any other private secrets are never committed. Do not add private keys to the repo or to prompts.

Limitations & good to know

  • Binary files (images, fonts) are committed too, encoded for Git — your file tree shows them alongside code.
  • Revert never destroys history. A rollback is always a forward commit; earlier commits stay reachable.
  • Name collisions are handled automatically. A reserved or empty slug falls back to the name project; if a chosen name is already taken on GitHub, Mythos appends a short slice of the project ID to keep it unique.

Troubleshooting

ProblemFix
My exported repo is missing recent changesThe mirror runs on each build. Run one more build (or edit) to re-trigger it. If it stays behind, contact support — Mythos can re-push the latest state.
I can’t export yetExport needs a one-time GitHub connect. Connect your GitHub account first, then the export repo is created and kept in sync.

FAQ

Yes. Every project repo is private, and so is the exported mirror in your own GitHub account.
Yes — connect your GitHub account once. Mythos creates a private repo you own and keeps it mirrored on every later build, so you can clone and host it anywhere.
Deleting a project deletes its managed repo. An exported copy in your own GitHub account is separate and is not affected.
No. A revert creates a new commit that restores an earlier state; the newer commits stay in the history, so you can revert the revert.