MagicPath — a shared canvas where humans and agents design in the same file
A cloud canvas where people and coding agents design together, then push real React into your repo. Credits, limits and what it will not ship.
- AI Design
- Design to Code
- Prototyping
- React
- Agentic Workflows
- Publisher
- MagicPath
- Type
- AI Design Canvas
- Pricing
- Freemium
- Reviewed
- 19 September 2026
Quick verdict
Use when
- You want to see several directions for a screen at once rather than iterating on one generated attempt
- Your design work and your code live in different tools and the hand-off between them is the actual bottleneck
- You already work with a coding agent in your editor or terminal and want it to build into a shared visual space instead of only emitting files
- The team needs to look at the same canvas while it changes, with every agent’s work visible as it happens
- You want to edit a live interface directly — drag it, resize it — rather than describing the change in a prompt and hoping
Skip when
- You need a deployed product; this exports code and stops there, and hosting is yours to arrange
- Your stack is not React, because the export is React and the round-trip assumes you can commit it
- You want predictable flat-rate billing — generation is metered in credits that reset each cycle and reviewers consistently report they run down quickly
- You need deep vector editing, asset management or a full design-system toolchain, which a dedicated design application still does better
- Your work is a single screen rather than a flow; the parallel-agent model pays off on breadth, not on one component
Try instead
If what you want is a design tool that exports code, or an open workflow you host yourself, those live here too.
MagicPath vs Figma Make vs v0 vs Lovable
Tap a dimension to focus
Pricing
Roughly even- MagicPathThis page
- Free tier granting a small daily credit allowance that resets monthly rather than accumulating
- Paid tiers from a low-cost individual plan up to per-seat team plans with a shared credit pool
- Credits meter AI generation only — manual editing, code export and library use are free
- Figma imports and exports run on separate allowances rather than against the credit balance
- External agents are billed by their own provider, not against your balance — but reviewers consistently report credits running down faster than expected on complex work
- Included with paid seats in the wider design platform, rather than sold as a separate tool
- The marginal cost of a generation is effectively absorbed by the seat you already pay for
- No separate credit arithmetic for a team already on a paid plan
- The trade is that the seat price is the price, and it is a professional tool's seat price
- Free tier with a monthly credit allowance for individuals
- Paid plans priced per user with larger allowances and higher usage ceilings
- Credits consumed per generation, with larger or iterative requests costing more
- Billing scales with how much you lean on it, and there is no canvas cost because there is no canvas
- Free tier with a daily message allowance
- Paid plans priced per month with credit allowances that reset
- Higher tiers add more credits, custom domains, more projects and team features
- Credits cover both generation and the hosted running of the app, so the metering also pays for infrastructure
Preview of MagicPath - not the live app. Confirm details on the official site.
Does this overview help you decide?
—
(—)
Learn more
Details below the decision summary—features, workflow, and scope notes.
What is MagicPath?
What it costs
- Free tier
- Yes
- Pricing summary
- MagicPath is metered in credits, and the distinctions between what does and does not consume them are the whole of the pricing model. Credits pay for AI generation inside the canvas; the cost of a request scales with complexity, so a single component is cheap and a multi-screen flow is not. Manual editing, code export, sharing and library use are free, which matters more than it sounds — you can spend a long time refining a design visually without touching your balance. Figma imports and exports run on their own monthly allowances instead of credits, and when an external agent such as Claude Code, Codex or Cursor drives the canvas, the work is billed by that provider rather than against MagicPath at all. Above the free allowance sit individual paid tiers with progressively larger monthly credit packs, then a per-seat team plan with a shared pool, SSO and admin controls, with annual billing at a meaningful discount. Two characteristics deserve emphasis because independent reviews raise them consistently. Credits reset each cycle rather than rolling over, so an unused balance is lost and a heavy month cannot borrow from a quiet one. And real-world consumption is faster than the free allowance suggests: third-party testing has measured a handful of credits for a single agent action and around ten for two generated screens, with generation taking minutes rather than seconds, which means the free tier is a genuine evaluation rather than a way to work. For an individual the metered model is reasonable; for a team the arithmetic is the shared pool against how many people are generating, and the honest advice is to instrument the cost of a real flow before committing a department to it. Current allowances and tier structures belong on the official pricing page.
Reviewed on 19 September 2026 · MagicPath — pricing
What MagicPath does
An infinite, multiplayer canvas
The workspace is a canvas rather than a chat thread, which means screens have position and can be compared side by side instead of arriving one after another in a scroll. Humans and agents occupy it at the same time, and every change is visible to everyone as it happens — the collaboration model is the product's organising idea, not a feature bolted onto a generator.
Parallel designer agents rather than one at a time
A single brief can produce several screens or variations simultaneously, because the work is distributed across agents instead of queued. This is the capability most directly responsible for the product feeling like briefing a team rather than talking to a tool, and it is what makes it practical to explore a direction rather than commit to the first plausible answer.
Real, running interfaces rather than static mocks
Everything on the canvas is working code rendering in the browser, shareable as an interactive link. That changes what a review is: instead of describing how a flow behaves, you send it and let someone use it. For anything with state — a multi-step form, a filter, an empty state — this is a materially better conversation than a screenshot.
A visual editor that works on live interfaces
Elements can be dragged, resized, duplicated and edited directly, and edits can be pushed across many designs at once — changing every instance of a component in a flow in one move. Editing a running interface rather than a static file is unusual, and it is the feature that lets a designer make a small correction without writing a prompt and waiting for a generation.
Two-way synchronisation with your repository
Canvas components push into your codebase as real React ready to commit, and components that already exist in your repository pull into the canvas to be edited visually and pushed back. This is the part that replaces the hand-off rather than automating it: the same artefact moves in both directions instead of being translated once and abandoned.
Your existing agent, working on the canvas
Codex, Claude Code and Cursor connect through an installable skill and drive the canvas directly, and because the canvas lives in the cloud they can do it with the application closed — from a terminal, a server or a phone. Each agent appears on the canvas as a worker so you can see what it is building, which is a direct answer to the black-box feeling of agentic tools.
Figma import, web capture and Figma export
A Figma frame can be pasted in and converted to working code with images, typography, colour and layout preserved, any website can be captured into the canvas as a starting point, and designs can be exported back to Figma through a third-party service. For a team whose current assets live in design files, the import path is what makes the canvas usable on day one instead of from scratch.
Shared design systems and libraries
Teams can keep components and libraries consistent across projects so that generated screens inherit the same primitives rather than inventing new ones each time. This is the feature that decides whether the output is a coherent product or a collection of plausible-looking screens, and it is also where the canvas is documented to slow down as the library grows.
How teams use MagicPath
Connect the agent you already use before anything else
The product's strongest structural advantage is that it does not ask you to abandon your editor. Install the skill for the agent you already run — Codex, Claude Code or Cursor — and connect your repository at the start. Teams that treat the canvas as a separate destination end up maintaining two workflows and a manual copy step, which is the exact hand-off problem the tool exists to remove.
Brief breadth first, then narrow
The parallel-agent model is worth its credits when you use it to explore: ask for several directions at once, put them side by side on the canvas, and discard most of them. Iterating a single design one prompt at a time uses the same metered generation to do something a conventional tool does, and it is the fastest way to waste an allowance.
Pull in the real components early
Bringing existing repository components into the canvas before generating new screens is what keeps the output coherent with the product that exists. Generating first and reconciling later produces screens that look right and do not match the codebase, which is a familiar and expensive failure — the round-trip is only an advantage if it is used in both directions.
Edit visually where you can and generate where you must
Manual editing costs nothing and generation costs credits, so the discipline that follows is simple: use the AI to create the thing you did not have, and use direct manipulation for every adjustment after that. Teams that reach for a prompt to move a button are paying for a capability they already have and adding a two-minute wait to a two-second change.
Instrument the cost of one real flow before you commit a team
Because credits are consumed by complexity and reset each cycle, the number that matters is what your actual flow costs to produce — not the free allowance and not the tier size. Run one representative project from brief to export during evaluation and count what it consumed; that figure, multiplied by the number of people generating, is the honest budget, and it is usually higher than the headline suggests.
Keep the canvas for exploration and the repository for truth
The exported code is the artefact; the canvas is where it was worked out. Treating the canvas as the source of record creates the same drift every visual tool produces, and it devalues the round-trip that makes this product distinctive. Export, commit, and let the next round of exploration start from the real components — that is the loop that compounds.
Who MagicPath is for
Product teams whose design-to-code hand-off is the bottleneck
The clearest buyer is a team with designers and engineers where the delay is between the two — screens that need rebuilding by hand from a design, components that diverge from what was designed. The round-trip addresses that specifically: the same artefact moves into the repository as React and back out for visual edits, rather than being translated once and abandoned.
Designers who are comfortable working with agents
This is not a tool for someone who wants to avoid code entirely, and it is not aimed at someone who wants to live in a prompt box either. It rewards people who already work with a coding assistant and want the design work to happen in a shared space rather than as files in a terminal — a growing group, and one the product is unambiguously designed around.
Teams exploring a direction rather than polishing a screen
The parallel-agent model is close to wasted on a single component and valuable on a flow: five candidate versions of an onboarding sequence, generated at once, arranged side by side and debated in a review. If the hard part of your work is deciding what to build, this is the shape of tool that shortens that phase.
Small product teams without a dedicated design engineer
A team of a few engineers and no design specialist can use the canvas to get coherent screens out and into the repository without commissioning design or hand-rolling the UI. The shared libraries matter here: consistency comes from the primitives the team keeps in the canvas rather than from a design system someone has to maintain.
Organisations already standardised on React
The export is React, the round-trip assumes React components, and the repository integration makes most sense when the front end is already that stack. For a React product this is a natural fit; for anything else, the generated code is a starting point to be translated, which removes most of the reason to use it.
When MagicPath is the right pick
Platform and licensing notes
- A cloud-only canvas with no self-hosted option
- Projects live on the vendor's infrastructure, which is what allows an agent to drive a canvas while the application is closed and what makes multiplayer work without anyone running a server. There is no local or self-hosted edition, so any constraint about where design work is stored or which third parties can process it is a reason to stop rather than a configuration question.
- Credit-metered generation with a resetting allowance
- Credits pay for AI generation and are priced by task complexity; manual edits, exports, sharing and library use are free, Figma imports and exports have their own monthly allowances, and external agents are billed by their provider instead. The balance resets each cycle and does not roll over. Published third-party testing has measured consumption in the range of a few credits per agent action and around ten for two screens, with a couple of minutes of generation time — treat the free allowance as an evaluation rather than a working budget.
- React is the target, and there is no deployment step
- Designs push into a repository as React, so the product assumes a React front end and a commit-based workflow. It does not build, host or deploy anything: once the code is exported, provisioning and shipping are the team's own. That is a deliberate boundary rather than a gap, and it is the clearest dividing line between this and the prompt-to-app products that also run your application.
- An agent-facing architecture with real permissions weight
- The product is designed to be driven by third-party agents through an installable skill, which typically means granting that agent access to your repository and optionally to your issue tracker. This is the access that deserves scrutiny: the canvas itself holds design work, but the agent connection reaches your source code. Scope it as narrowly as the workflow allows and review the connections after the first project rather than during it.
- Documented limits at scale
- Independent reviews report generation taking around two minutes per substantial request, credits depleting quickly during iteration, and the canvas becoming sluggish once a design system grows past a certain number of component categories. None of these are disqualifying for a focused product flow, and they are all worth knowing before migrating an organisation's whole component library onto a single infinite canvas.
- What it does not do
- It is not a deployment platform and does not host anything. It is not a replacement for a professional vector design tool: asset management, illustration and print-grade typography are outside its scope, and a design-led team will keep the dedicated application for that work. It is not a full-stack builder — no database, no authentication, no backend. And it is not predictable flat-rate software: the bill scales with how much you generate, which is a real budgeting consideration rather than a detail.