Chrome Extension
Meta just entered the AI coding agent race, and I spent real money testing it the same day it shipped. I built five separate apps with Muse Code, Meta's new terminal coding agent, running on its new model, Muse Spark 1.2, and I am giving you my honest read on every one of them. You will see what worked, what broke, exactly how much I spent, and everything you need to know about installing, pricing, and prompting this tool yourself, all checked against Meta's own documentation.
Key Takeaways
What I Built With Muse Code And Muse Spark 1.2
I want to walk you through every app before I hand you my opinion, because the evidence matters more than the verdict. Each one came from a detailed prompt, not a one-line request, and each one taught me something different about where this tool holds up and where it does not.
App 1: The Multi-Page Front-End Website (3 out of 5)
My first build was a multi-page front-end website, and my first impression was genuinely good. The design language matched my prompt, the cursor effects were in place, and the page structure followed what I asked for.
Then I started clicking around. A parallax effect I specifically requested came out broken on first load, though a page reload fixed it. A counter widget on the page was also messed up and did not behave the way I wanted.
I also caught an inconsistency I had not asked for: two different fonts were used across the site, one on a section I had not specified a typeface for. The rest of the build held up fine. The blog page, the contact page, and the pricing page all worked, though the pricing page's FAQ section should have been centered and was not.
Deliver: complete multi-page static site — shared.css + shared.js + 6 HTML pages + per-page JS. CDN only (Three.js r128, GSAP + ScrollTrigger, Lenis, Lucide, Google Fonts). Build brief (hand all of this to the model; run at xhigh): Concept & theme: "Atlas" — a company that builds autonomous coding-agent tooling. Aesthetic: technical but premium; a "control room / mission-map" vibe (fitting the Atlas name + the agent/event-log identity of the model itself). Distinct from prior packs — propose a cool slate + a signal-orange or aurora-green accent, full dark+light. Fonts: a strong display face + a clean grotesk body + a mono (real Google Fonts). 6 pages, all sharing nav/footer/cursor/theme/page-transitions: index.html (Home) — 11+ sections: 3D hero (a rotating globe/atlas of connected agent-nodes, real Three.js, mouse + scroll reactive, disposed on navigation); logo marquee; product pillars; a pinned scroll interlude where an "agent event log" streams + a task graph assembles as you scroll (the model's signature feature, visualized); feature blocks; stats; integrations; testimonials; blog teasers; CTA. product.html — sticky scroll-spy feature deep-dive; tabbed capability explorer; a "how the agent works" stepped SVG diagram that draws on scroll; spec table; CTA. agents.html (or solutions.html) — a use-case selector (tabs: Refactors, Migrations, Repo-scale builds, Debugging) that swaps content; customer-story spotlight; ROI band. pricing.html — monthly/annual toggle animating prices; 3 tiers (middle featured w/ rotating gradient border); comparison table; FAQ accordion. blog.html — featured post; category filter that live-filters a 3-col grid; newsletter. contact.html — validated demo-request form + an animated SVG "network beacon" visual; offices; "what happens next" timeline; confetti on submit. Shared systems (in shared.js): Lenis smooth scroll + progress bar; a custom cursor unique to this pack (propose a small reticle/crosshair that locks on hover, since the theme is "atlas/mission-map"); theme toggle persisted in localStorage; [data-reveal] scroll-entrance system; magnetic buttons; tilt cards; and page-transition veil so moving between the 6 pages feels seamless. Signature moment: the home pinned interlude that visualizes Muse Spark 1.2's actual identity — a streaming event log + a parallel-subagent task graph assembling on a 300vh pin. This is both on-brand and a genuine scroll-choreography test. Quality bar: real Three.js WebGL (60fps, dispose on transition, static fallback); all 6 background patterns; every tab/toggle/filter/accordion/carousel/form wired; both themes; fully responsive with a mobile overlay menu; reduced-motion respected; accessible (semantic HTML, focus states, aria labels). Delivery: output shared.css + shared.js in full first, then all 6 pages + js/ files, no truncation, ending with a validation checklist.
Between the responsiveness issues, the font mismatch, and the design inconsistency across pages, I would not ship this straight to a client. I am giving this one a 3 out of 5.
App 2: Gridlock, A Puzzle Game (4 out of 5)
My second build was Gridlock, a puzzle game, and my honest first reaction was that it looked more like a landing page for a game than an actual game. Clicking Continue took me to a real dashboard, and from there the experience improved.
I want to flag something I noticed here that goes beyond this one app. Muse Code's visual output has a strong sameness to it across different projects, the same kind of standard design pattern you start to recognize the more you use Claude Code, Codex, or ChatGPT for the same kind of task. That is simply how these models are trained: on patterns, not on what makes a specific brand feel distinct, unless you specify that in your prompt.
The gameplay itself worked for the most part. Undo and Restart both functioned correctly, the hint system worked, and the map selection screen correctly locked maps behind my current level. But when I tried to complete a level using the Next Turn and Finish buttons, the finishing logic never triggered.
Deliver: ONE self-contained gridlock.html. Everything embedded. Fonts via CDN only. Build brief (run at high): Concept: a grid-based delivery puzzle (think a friendlier Mini Metro × Sokoban). Each level is a city grid with warehouses (sources), houses (destinations), roads, and obstacles. The player places/routes autonomous delivery trucks that must pick up packages and deliver them within a turn/energy budget. Solve by planning efficient routes — no reflexes, pure logic. Core systems: Grid world (tiles: road, wall, warehouse, house, one-way arrows, toll, charger) Trucks with limited range that follow player-drawn or player-programmed routes Turn-based resolution: each turn, trucks advance along their routes, pick up/drop off Package queue + demand: houses request specific packages; deliver before a deadline Pathfinding helper (A* on the grid) for a "suggest route" hint + to validate routes Scoring: deliveries completed, efficiency (fewer moves/energy), on-time bonus 12+ handcrafted levels of rising complexity + a level-complete → next flow Win = all demands met within budget; lose = missed deadlines / out of energy Rich UI (the polish test): animated grid, smooth truck movement + turning, route preview lines, package icons, demand tickets with countdowns, an energy/turn meter, level map/selector, a clean HUD, animated menus (main / level select / how-to / results), a satisfying "level solved" celebration, undo/restart, a hint button. Audio: synthesized SFX via Web Audio (pickup, deliver, truck move, success, fail). Persistence: localStorage for level progress, best scores per level, settings. Structure (single file, sectioned): Grid, Tile, Truck, Package, Level, Pathfinder (A*), TurnResolver, UI (screen manager), HUD, AudioEngine, Storage. Verify: trucks follow routes and resolve per turn; A* suggest/validate works; demands deadlines tracked; scoring + efficiency computed; all 12 levels solvable + progression saves; undo/restart/hint work; menus animated; 60fps. Output the complete single HTML file, no truncation. The turn resolver + A* pathfinding are the critical logic — they must be correct.
"It didn't add the finishing logic to it. I don't know why."
That is a real gap. A puzzle game without a working win condition is not a finished puzzle game, no matter how good the interface looks. Between the strong dashboard, the working hint and map systems, and that one missing piece of core logic, I am giving Gridlock a 4 out of 5.
App 3: The 3D Traffic Intersection Simulation
My third build was a flow simulation of regular traffic at a road intersection, and this is where I found the pattern that shaped my entire opinion of Muse Spark 1.2. The visual side of the simulation looked convincing: a functioning intersection with red and green lights, a heat map, customization options, and charts tracking traffic behavior.
Then I zoomed in to check whether the actual driving logic was correct. It was not.
"Yeah, there's a red light and still crossing the road. So this should not be like that."
I have tested a similar traffic simulation brief with Moonshot's Kimi K3 model on this channel before, and Kimi K3 handled the same kind of rule correctly on that test. Seeing Muse Spark 1.2 break its own red light rule was a direct, visible gap between the two.
The bug was not limited to cars. When I clicked the settings to add more pedestrians, I watched a pedestrian cross the street while the light was green for vehicle traffic, which is exactly backward from how a real intersection works.
Deliver: self-contained flowsim.html (Three.js r128 + GSAP + Google Fonts via CDN). Build brief (run at xhigh): Concept: a 3D four-way (extensible to more) urban intersection where cars, trucks, and pedestrians move according to traffic-signal timing the user controls. The user tunes the signal plan and watches throughput, average wait time, and congestion respond in real time — a legitimate tool for reasoning about intersection design. The 3D scene: a stylized-but-clean 3D intersection (roads with lane markings, crosswalks, traffic lights on poles, sidewalks, a few buildings + trees for context), rendered with Three.js. Nice materials + soft shadows + a pleasant sky. Orbit + zoom camera, plus preset views (top-down "planner" view, driver-eye, cinematic orbit). Vehicle agents (the simulation core): Cars/trucks spawn at each approach at a configurable rate, choose a route (straight/ left/right), follow their lane, and obey signals + car-following rules (don't collide; slow for the car ahead; stop at red; go on green; yield on turns). A car-following model (e.g. intelligent-driver-model-lite): acceleration based on gap speed of the leader; smooth, believable motion; queues form at red lights. Pedestrians cross on walk signals; vehicles yield. Turning vehicles follow curved paths through the intersection. Signal system (the thing the user controls): A configurable signal plan: phase order, green/yellow/all-red durations per phase, cycle length. Standard 4-phase (NS through, NS left, EW through, EW left) with a pedestrian phase. A control panel to edit phase timings live and watch the effect. Optional "adaptive" mode: signals extend green for the busier approach (a simple actuated-control demo) vs fixed-time — compare the two. The rich data dashboard (real-world value): Live metrics: throughput (vehicles/min through the intersection), average + max wait time per approach, current queue lengths per lane, total vehicles, ped crossings. Live charts (CSS/SVG or lightweight): throughput over time, wait-time by approach. Congestion heat: color approaches red/amber/green by queue length. Scenario presets: "Rush Hour", "Balanced", "Heavy Left Turns", "Pedestrian Heavy". Controls: spawn rates per approach, sim speed (0.5×–8×), pause, reset, fixed vs adaptive signals, and the full signal-plan editor. An "efficiency score" summarizing how well the current plan handles the current demand, so the user can iterate toward a better plan — the actual planning use-case. Structure: scene/lighting/roads setup; Vehicle agent (spawn, route, car-following, turning); Pedestrian agent; SignalController (phase state machine, fixed + adaptive); IntersectionModel (spawn rates, lane assignment); Dashboard (metrics + charts + heat); camera controller (orbit + presets); simulation loop with speed control. Verify: cars spawn, follow lanes, queue at red, proceed on green, turn along curves, don't collide; peds cross on walk; the signal plan editor changes behavior live; fixed vs adaptive differ measurably; metrics (throughput, wait, queues) update live + match what you see; scenarios load; heatmap + charts work; efficiency score responds to plan changes; 60fps with dozens of vehicles. Output the complete file, no truncation. The car-following model + signal state machine + the live metrics loop are the critical systems — they must produce believable, responsive traffic that actually reacts to the signal plan (that's what makes it a real tool, not an animation).
The customization side genuinely impressed me. The rush hour toggle correctly increased vehicle volume, the heat map rendered properly, and the charts tracked the simulation in real time. But a traffic simulation that does not reliably enforce traffic rules is failing at its one job, even while its supporting features work well. I did not assign this one a numeric score on its own, because the real finding here is bigger than one app, and I want to walk you through it next.
App 4: Shipyard, A SaaS Release-Notes App (4 out of 5)
My fourth build was Shipyard, a SaaS app that turns commit logs into release notes a real user would actually want to read. I described it as somewhat like a clone of GitHub's release flow, and I built the entire thing in one shot, with no follow-up iteration prompts.
The landing page structure was, in my own words, top-notch. The accordion sections worked, the login and signup flow worked, and Muse Code even built one-click demo logins for three different account tiers: free, pro, and team.
I tested the free tier first. I had demo project data already in place, and I clicked Generate Release with Muse Spark. It got stuck for two to three minutes and never actually generated anything.
"The error handling is not there. It should show that in the front end that you are a free user, you need to upgrade."
That is a real product gap, not a coding failure. The feature was correctly gated behind a paid plan, but the app never told me why it failed. I confirmed this by switching to the pro account, creating a new project, adding a deploy, and clicking Generate Release again.
Deliver: full Node/Express/Postgres app — landing page, auth with sample logins, and the complete product. AI via the Meta Model API (or OpenRouter meta/muse-spark-1.2).
Build brief — Phase 1 (architecture, schema, sample logins, landing):
Stack: Node 18+, Express, EJS, PostgreSQL (pg), bcryptjs, express-session, connect-pg-simple, Lucide, vanilla CSS, date-fns. AI via Meta Model API (https://api.meta.ai/v1, model muse-spark-1.2) or OpenRouter (meta/muse-spark-1.2), Bearer META_API_KEY / OPENROUTER_API_KEY.
What it does: teams connect a project; paste (or webhook-in) their deploy/commit logs; Shipyard uses Muse Spark 1.2 to turn raw logs into clean, categorized release notes and a human-readable deploy timeline, hosted on a public changelog page.
Schema: users, projects (name, slug for public page, accent color), deploys (project_id, version, raw_log, status, env [prod/staging], deployed_at), releases (project_id, version, ai_title, ai_summary, categories JSONB {added/fixed/changed/ removed}, body_markdown, status [draft/published], published_at), subscribers.
Sample logins (seed these; password shipyard2026), shown as one-click tiles + listed on the login page:
demo@shipyard.app / shipyard2026 (Pro) — "Demo User", 2 projects w/ full history
sarah@shipyard.app / shipyard2026 (Team) — "Sarah Chen", 1 active project
free@shipyard.app / shipyard2026 (Free) — "Free User", 1 small project
Demo data (make it alive): for the demo user, a "Nimbus API" project with ~8 deploys and ~5 published releases (realistic version history, categorized notes, a cached AI summary each), plus a couple of drafts to generate live; a second smaller project; subscribers rows. Sarah + free get smaller seeded sets.
Landing page (/) — a real marketing page: nav; hero ("Turn deploy logs into release notes your users actually read" + CTA + an animated changelog mockup); how-it- works (connect → deploy → auto-notes); features grid; a live-ish sample changelog strip; pricing (Free / Pro $19 / Team $49, monthly-annual toggle); testimonials; FAQ; footer. Polished, animated on scroll, responsive.
App features: dashboard (project cards); project view (deploy history + release list); generate-release flow (paste/select deploys → Muse Spark 1.2 produces a categorized, titled, summarized changelog as structured JSON, streamed into an editable review screen → publish); public changelog page (/c/:slug, themed, subscribe form, RSS); settings (API key, model, project settings). Light-mode-first, Inter + JetBrains Mono, Lucide.On the pro account, it worked immediately. The changelog it generated matched my instructions closely, and publishing the release worked without issue. For a model this new to frontier-level coding work, a fully functional core feature with one missing error state is a strong result. I am giving Shipyard a 4 out of 5.
App 5: The Python Hand-Drawn Diagram Digitizer (4 out of 5)
My fifth and final build was a Python app I call a cartographer: you feed it a hand-drawn diagram, and it transforms that drawing into an editable digital diagram, using the Muse Spark 1.2 API directly. I selected flowchart mode and tested it first on clean demo data before trying the real test: a genuinely messy hand-drawn flowchart I sketched myself.
I uploaded the image and clicked Digitize This Diagram, and the result surprised me.
"Each and every part of the flow diagram, and even the spellings, even the connected dot from the no, yes to no. So each flow and node is connected as per our hand-drawn image."
Every decision branch in my messy drawing, including a "yes" path and a "no" path that I had drawn slightly ambiguously, mapped correctly to the finished digital flowchart. That is a genuinely hard computer vision and reasoning task done well.
My complaints here are about the app's user experience, not the underlying model. I had to add my Muse Spark API key through an environment variable or an export command instead of through a settings screen inside the app itself. I also wanted a diagram-type selector, since the app defaulted to flowchart mode with no way to switch to something like a mind map or org chart from the interface.
Deliver: full Python desktop app. Launch python main.py, window opens immediately.
Build brief (run the model at high; app calls the API for vision):
Stack: Python 3.11+, customtkinter 5.2.x, Pillow, requests, json, threading, math, pathlib (stdlib). AI via Meta Model API (https://api.meta.ai/v1, model muse-spark-1.2) or OpenRouter (meta/muse-spark-1.2); key from META_API_KEY / OPENROUTER_API_KEY. Send the photo as a base64 image (OpenAI-compatible vision format).
Flow:
User uploads or drops a photo of a hand-drawn diagram (flowchart, mind map, org chart, system architecture, ER diagram).
App sends the image to Muse Spark 1.2 with a system prompt to extract a STRUCTURED graph as JSON: { nodes:[{id,label,shape,x,y}], edges:[{from,to,label,directed}], type }. (Ask it to infer positions + shapes + arrow directions + text labels.)
App renders the returned graph as a clean, editable diagram on a canvas.
User can edit: move nodes (drag), rename labels, add/delete nodes + edges, change shapes/colors, re-layout (auto-layout button), then EXPORT (PNG, SVG, and the JSON, plus a Mermaid/Graphviz text export — a nice "digitize to code" touch for devs).
UI (rich): left = source image preview + "Digitize" button + history; center = the editable diagram canvas (pan/zoom, grid, snapping); right = properties panel (selected node/edge label, shape, color) + export panel. A clean, modern customtkinter theme. Loading state while the model reasons ("Reading your diagram…"). Handle multi-diagram history (re-open past digitizations).
Editing engine: nodes as draggable shapes (rect/rounded/ellipse/diamond), edges as arrows that stay attached to nodes as they move, label editing inline, an auto-layout (simple force-directed or layered) to tidy messy extractions.
Demo/no-key behavior: ship one bundled sample photo + its pre-extracted JSON so the app demonstrates the full editor without a key; only the "Digitize" (vision) call needs the API. Everything else (edit, layout, export) works offline.
Structure: main.py (app + panels), vision.py (Muse Spark 1.2 image→graph, threaded), diagram.py (graph model + auto-layout), canvas_editor.py (render + drag + edit), export.py (PNG/SVG/JSON/Mermaid), settings.py, requirements.txt.
Verify: photo uploads; vision call returns valid graph JSON; diagram renders; nodes drag with attached edges; labels editable; add/delete works; auto-layout tidies; exports produce correct PNG/SVG/JSON/Mermaid; sample works with no key.
Output all files complete, no truncation. vision.py (the multimodal extraction) and canvas_editor.py (editable diagram) are the critical files.The core capability, turning a rough hand-drawn sketch into an accurate, connected digital diagram, worked close to perfectly. The missing settings panel is a real gap, but it is a UX gap, not a reasoning failure. I am giving this one a 4 out of 5 as well.
The One Bug I Kept Running Into
I want to pull this out into its own section because it showed up in two completely different apps, and that pattern matters more than any single bug. Gridlock's finishing logic never triggered. The traffic simulation broke its own red light rule for both cars and pedestrians. Both failures happened at the model's highest reasoning setting, not a lower, cheaper one.
That tells me something specific about Muse Spark 1.2 in its current form: it renders convincing interfaces and convincing supporting systems, but it does not reliably carry a defined rule all the way through to enforcement, even when I described that rule clearly in my prompt. I want to be fair here. This is a brand new model on its first coding-focused release, and Meta's own evaluation methodology states plainly that competitor benchmark numbers in its own reporting may not reflect those other models running at their best. I am holding Muse Spark 1.2 to the same evidence standard I hold everyone else to, and on these two tests, the logic did not hold.
What Muse Code And Muse Spark 1.2 Actually Are
Let me step back from my own builds and ground you in the facts, since a review only means something if the numbers behind it are accurate.
Muse Code: Meta's New Terminal Coding Agent
Meta released Muse Code in beta on August 5, 2026, describing it as a terminal coding agent that can plan changes, write code, and validate results across large repositories, using multiple persistent subagents that stay active through an entire session instead of spinning up fresh for every task. Meta CEO Mark Zuckerberg has publicly framed Muse Code as capable of completing full software engineering tasks across large repositories, not just single-file edits.
The runtime design is genuinely interesting from an engineering standpoint. Muse Code keeps a local, append-only event log of every model call, tool run, approval, and edit, which Meta says makes the system replay-exact and restart-safe, meaning it can resume a task precisely where it left off after a crash. Right now, Muse Code only installs on macOS and Linux. Meta has not published a native Windows installation path in its launch materials.
Muse Spark 1.2: The Model Behind It
Muse Spark 1.2 is a coding-focused update to Muse Spark 1.1, and Meta says it significantly scaled up training compute on coding tasks specifically, while expanding the diversity of its training environments. The model was co-trained directly with the Muse Code toolset, which Meta says helps it perform its best when the two are paired together, exactly the setup I used for all five of my apps.
Meta also describes an interesting self-improvement loop behind this release: it used Muse Spark 1.1 to generate challenging coding environments and instruction-following templates, then had that same model grade candidate solutions against those requirements, producing training data for Muse Spark 1.2. Meta credits this loop for the newer model's improved ability to follow complex, multi-part instructions.
Specs At A Glance
| Spec | Detail |
|---|---|
| Release date | August 5, 2026 |
| Context window | 1,048,576 tokens (roughly 1 million) |
| Input modalities | Text, images, and, per Meta's own MP4-to-website demo, video |
| Output modality | Text only |
| Reasoning | Mandatory across every effort level |
| Effort levels | Minimal, low, medium (default), high, xhigh |
| Standard input pricing | $1.25 per million tokens |
| Standard output pricing | $4.25 per million tokens |
| Contributor input pricing | $0.10 per million tokens |
| Contributor output pricing | $0.20 per million tokens |
Source: Meta AI Research, Introducing Muse Code and Muse Spark 1.2, OpenRouter, Muse Spark 1.2, MacRumors, Meta's New Mac Coding Agent
Benchmarks That Matter
Meta's own launch materials show real, specific gains over the previous model. On Terminal-Bench 2.1, a benchmark for agentic coding and terminal use, Muse Spark 1.2 paired with Muse Code scores 82.9%, up from 76.2% for Muse Spark 1.1. On DeepSWE 1.1, a benchmark for agentic software engineering, it scores 59.3%, up from 53.0% for the previous model.
Here is how that stacks up against the competition, based on Meta's own published comparison:
| Model + agent | Terminal-Bench 2.1 | DeepSWE 1.1 |
|---|---|---|
| Claude Opus 5 + Claude Code | 86.7% | 65.0% |
| Muse Spark 1.2 + Muse Code | 82.9% | 59.3% |
| GPT-5.6 Terra + Codex | 81.8% | 64.8% |
| Grok Build | 81.6% | Not published in this comparison |
Source: Meta AI Research, Introducing Muse Code and Muse Spark 1.2, Kingy AI, Muse Code Benchmarks
I want to flag Meta's own caveat here, because it is refreshingly honest for a launch document: Meta's evaluation methodology states that its agent tools and system prompts for competitor models may not be tuned to those models' strengths, so the competitor numbers in its own comparison may understate what those other tools can actually do. I appreciate that level of transparency, and I am applying the same caution to my own reading of this table.
Independent evaluation backs up the general picture, too. Artificial Analysis scored Muse Spark 1.2 at xhigh effort at 57 on its Intelligence Index, which it says places the model well above the median score of 33 for models in a similar price range, while pricing it as competitively priced against that same peer group.
Muse Code's Effort Levels
I want to correct something from my own testing here, because I said something in the moment that was not quite right, and I care more about being accurate than about being consistent with what I said on camera. I mentioned using the xhigh effort setting because I wanted to avoid a higher "ultra" tier with steeper pricing.
That tier does not exist. Meta's own documentation lists exactly five effort levels: minimal, low, medium, high, and xhigh, with medium as the default and xhigh as the actual ceiling. There is no sixth "ultra" level above it. I likely carried that term over from testing Claude's Opus models on this channel, where an "ultra" naming convention does show up. For Muse Code specifically, xhigh is genuinely the top of the range, and that is exactly what I used for every one of these five builds.
Reasoning stays active across all five levels, which is a real difference from some other coding tools that let you disable reasoning entirely at the lowest setting. Higher effort levels mean more processing time before you get a result, so xhigh is the setting to reach for when you are asking for something as demanding as a full app build, not a quick single-function fix.
Muse Code's Pricing: Standard Vs Contributor Tier
This is the part of my testing that actually changed how I feel about recommending this tool. Generating all five apps you just read about cost me around $10 total, on the Standard tier, at the xhigh effort setting.
| Tier | Input price | Output price | Cached input | Rate limit |
|---|---|---|---|---|
| Standard | $1.25 / 1M tokens | $4.25 / 1M tokens | $0.15 / 1M tokens | 3,000 requests/min, 4,000,000 tokens/min |
| Contributor | $0.10 / 1M tokens | $0.20 / 1M tokens | $0.002 / 1M tokens | 60 requests/min, 2,100,000 tokens/min |
Source: MacRumors, Meta's New Mac Coding Agent, OpenRouter, Muse Spark 1.2
The Contributor tier is genuinely dramatic: roughly 12 times cheaper on input tokens and about 21 times cheaper on output tokens than Standard. The tradeoff is exactly what it sounds like. Choosing Contributor pricing means Meta can use your prompts and completions to train its future models, while Standard pricing keeps your code out of that training pipeline.
I did not use the Contributor tier for any of these five apps, because client and demo work is not something I want inside anyone's training data, mine included. But for personal projects or throwaway experiments where that tradeoff does not bother you, the Contributor tier changes the economics of this tool completely.
Even accounting for that discount option, my honest reaction to $10 for five demo apps on Standard pricing is that it is expensive relative to other coding models I have tested and reviewed on this channel, including Kimi K3, which delivered comparable or better results on a similar traffic-simulation logic test at a noticeably lower price. If Meta wants Muse Code to compete seriously with Claude Code and Codex on cost, not just capability, the Standard tier pricing is the lever I would want to see move.
How I Installed And Set Up Muse Code
Getting started took one command in my terminal, on macOS or Linux.
curl -fsSL https://dev.meta.ai/install.sh | bash
That command installs a launcher Meta calls muse, and once it is installed, you run it from inside the repository or project folder you want to work in. Source: Meta AI Research, Introducing Muse Code and Muse Spark 1.2
Muse Code's Prompting Guide: The Official Bundled Skills
Muse Code ships with three built-in skills that shape how you should actually brief it, and I used all three across my five builds.
/plan turns your task into an approval-gated plan. Instead of jumping straight into code, Muse Code lays out its intended approach first, so you can catch a wrong interpretation of your prompt before anything gets built.
/grill stress-tests that plan. This is the skill I would recommend leaning on for anything with real risk attached, since it is designed to surface weak assumptions, missing edge cases, and gaps in the plan before execution starts.
/goal works the agent toward a specified completion condition. This is what keeps a long, multi-step build like my SaaS app or my traffic simulation pointed at a clear finish line instead of drifting.
Source: MacRumors, Meta's New Mac Coding Agent, Meta AI Research, Introducing Muse Code and Muse Spark 1.2
Demo Prompt: How I Would Brief Muse Code Next Time
Based on everything I learned across these five builds, especially the two logic bugs, here is the prompt structure I would use going forward.
You are building [enter your app or game name here], a [describe your app category here]. Here is the complete specification: [paste your full feature list, screens, or rules here]. Every rule I describe, including anything about win conditions, permissions, or physical logic like traffic signals, must be enforced in the actual behavior of the app, not just represented visually. Before you finish, explicitly test and confirm that each stated rule is enforced, and tell me which rules you verified and how. Use /plan first, run /grill on anything involving a rule or a gated feature, then use /goal to complete the build. Flag any place where a feature is restricted by a plan or permission tier, and add a visible message explaining the restriction to the user.
That last line exists directly because of what happened with Shipyard's free-tier error handling gap, and the instruction to explicitly verify rule enforcement exists directly because of Gridlock and the traffic simulation.
5 Best Practices For Prompting Muse Code
I pulled these from Meta's own documentation and combined them with what actually worked across my testing.
/plan before any meaningful build. Catching a misread of your prompt at the planning stage is far cheaper than catching it after a full build finishes./grill on anything with a rule attached. Win conditions, permission gates, and physical logic like my traffic light rule are exactly the kind of thing that benefits from a dedicated stress-test pass.My Honest Verdict
Muse Code is a genuinely capable first swing from Meta at the coding agent space, and the parts of it that are pure engineering, like the persistent background agents and the restart-safe event log, are legitimately well designed. Four of my five apps landed at a 4 out of 5, and the hand-drawn diagram digitizer in particular handled a task I expected to trip it up.
But the repeated logic-enforcement gap across two separate apps is not a small thing to me, and I would not ship any of these five builds to a real client without a manual pass to verify every rule myself. Combine that with Standard tier pricing that ran me about $10 for five demo apps, and my recommendation right now is to treat Muse Code as a serious tool worth testing on your own projects, not yet as an automatic first choice over Claude Code, Codex, or Kimi K3 for logic-heavy work.
Frequently Asked Questions (FAQs)
What is Muse Code?
Muse Code is Meta's beta terminal coding agent, released August 5, 2026, for macOS and Linux. It plans, writes, and validates code across large repositories using persistent background subagents, and it runs on Meta's new coding-focused model, Muse Spark 1.2.
How much does Muse Spark 1.2 cost?
On the Standard tier, Muse Spark 1.2 costs $1.25 per million input tokens and $4.25 per million output tokens. The Contributor tier drops that to $0.10 per million input tokens and $0.20 per million output tokens, in exchange for letting Meta use your prompts and code to train future models.
Does Muse Code work on Windows?
Not officially. Meta's launch materials only cover macOS and Linux installation through a single terminal command, and no native Windows install path has been published.
What effort levels does Muse Code support?
Muse Code supports five effort levels: minimal, low, medium, high, and xhigh, with medium as the default. There is no "ultra" tier above xhigh, and reasoning stays active at every level.
Is Muse Spark 1.2 better than Claude Opus 5 or Kimi K3 for coding?
On Meta's own published benchmarks, Muse Spark 1.2 paired with Muse Code scores below Claude Opus 5 paired with Claude Code on both Terminal-Bench 2.1 and DeepSWE 1.1. In my own testing, Kimi K3 also handled a comparable traffic-simulation logic test more accurately than Muse Spark 1.2 did.
What are Muse Code's built-in skills?
Muse Code ships with three default skills: /plan, which turns a task into an approval-gated plan, /grill, which stress-tests that plan for weak assumptions, and /goal, which works the agent toward a specified completion condition.
Final Thoughts
I went into this test expecting either a rushed, half-working launch or a genuine Claude Code competitor, and what I got sits somewhere in between. The interface quality, the multimodal input handling, and the hand-drawn diagram app impressed me. The repeated failure to enforce clearly stated rules, twice, at the model's highest reasoning setting, is the one issue I would want Meta to fix before I trust it with anything logic-heavy for a client.
If you want to test Muse Code yourself, run it on a small, verifiable task first, and explicitly ask it to confirm every rule it implemented, the same lesson I am taking from this test into my next one. I keep testing every new coding model this same way on this channel, and I share the exact prompts and comparisons behind reviews like this one over at promptslove.com if you want to see the full process.
