Ep 1152 Tool 6:49 w/ Jessica & Cathy

Start building with Muse Ember, our smallest, most efficient model

Jessica and Cathy dig into Meta’s new Muse Ember model: a tiny, cheap, multimodal workhorse aimed at high-volume agent tasks. Cathy’s skeptical about benchmark hype and “subagent” branding; Jessica argues the Pygments migration and 10k-photo demo show a real, shippable pattern: big planner, small doers. They land on a practical takeaway: Ember matters if you’re actually running lots of agents and care about cost per workflow, not if you just want a single smart chatbot.

Embed this episode

Paste this on any site — the player is a self-contained iframe with no cookies or trackers.

<iframe src="https://sandrise.io/exploring-next/embed/1152"
  width="100%" height="180" style="max-width:640px;border:0;border-radius:12px;overflow:hidden"
  title="Exploring Next — Episode 1152 audio player"
  loading="lazy" allow="autoplay" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Embed & API docs →
Script GPT-5.1 Voice Cartesia TTS

Transcript

Jessica So Meta’s pitching Muse Ember as this tiny, cheap agent workhorse, and I’m trying to decide if that’s actually a big deal or just another small model with good marketing.

Cathy My first reaction is it leans pretty hard on the “cheapest Intelligence Index 36” story. Matching Claude Haiku’s score at roughly a third of the per-task cost sounds great, but that’s one composite benchmark, not proof it’s the new default for everything.

Jessica Right.

Cathy And the whole “purpose-built subagent” framing makes me twitch a bit. Every lab wants you to believe their small model is the perfect sidekick. The question is whether Ember actually changes what you can do in an agent harness, or if it’s just a slightly cheaper cog.

Jessica I mean, Cathy, the Pygments demo is more than a vibe. Sixteen Rust ports of real lexers, all matching three hundred eighty‑three test inputs and sixty‑two real files, and they finish within about six minutes of each other? That’s a real, end‑to‑end migration with checks, not just toy unit tests.

Cathy Sure, the Pygments run is the strongest part for me. Wonder plans, Ember does the grunt work, and they report about one hundred fifty‑eight million input tokens on Ember versus four point four million on Wonder for around three dollars ninety‑six total. That’s an actual costed workflow, not just a cherry‑picked chat transcript.

Jessica Exactly. And that split is the product point: the plan goes to the big model, the bounded file work goes to lots of small Embers in parallel. That’s the same “one planner, many doers” pattern we keep talking about, but they’re finally showing it with numbers.

Cathy I like the pattern. I’m just cautious on the claims around price‑performance. They say Ember sits on the efficiency frontier of the Artificial Analysis leaderboard, and beats every GPT‑6 Luna setting on intelligence per dollar. That’s cool if you believe that one index captures what your agents do all day, but real workloads are messier.

Jessica Yeah, and for anyone listening while coding: we read the launch posts for this, we did not go re‑run Artificial Analysis or re‑price every competitor, so if you’re going to bet real money on an exact cent value, please double‑check Meta’s docs.

Cathy Thank you. The other thing is, the story only makes sense if you’re actually running a lot of calls. Ten cents per million input and fifty cents per million output up to two hundred thousand tokens is nice, but if you’re doing one‑off chat you’ll never notice the savings over whatever small model you already have.

Jessica Totally. This is for people who look at their bill and see “agents did the same tiny decision ten thousand times.” That’s what the photo example screams to me: caption, rename, and album‑sort ten thousand images for about one dollar fifty‑nine, with only about fifty cents of that on Ember.

Cathy And all multimodal. Ember can take text, images, audio, and video, so the agents can read screenshots, parse scanned invoices, summarize meeting recordings, or describe sequences in a clip without swapping models. That’s actually a nice simplification for a harness.

Jessica Yeah, that’s the part I get excited about. Today you’ve got people gluing a vision model to a text model to an ASR model. Here you just say, my worker runs on muse‑ember one point zero, here’s a screenshot plus a bug report, go debug. Less routing code, less context‑passing weirdness.

Cathy The counterpoint is that you still need a real orchestration layer. Muse Code gives you tools to edit files, run tests, and coordinate agents, but you’re responsible for the harness logic. They even call out flags like double dash agents and double dash yolo to auto‑approve shell commands, which is powerful but also a little terrifying if you point it at the wrong folder.

Jessica Yeah, when the doc literally says “run it only in the sample folder, with a key you’re comfortable giving to an agent,” that’s your hint this is not plug‑and‑play for your production monolith.

Cathy Exactly. What I do like is that they’re honest about role separation. Muse Wonder never opens the source in that Pygments run. It builds a map, writes briefs, adjusts the shared Rust engine when it finds a missing post‑filter, and supervises when a worker accidentally runs git in the main checkout. Ember just owns a file or a shard and grinds.

Jessica Which is so aligned with that thing we keep coming back to: output versus delivery versus value. Wonder’s doing the delivery and guardrails, Ember’s spitting out diffs and captions fast enough that you can afford to throw away bad ones.

Cathy On speed, the third‑party quotes are interesting. One partner says Ember hit a p ninety‑five latency of about two point two seconds on their coding quests, four to thirteen times faster than leading open‑weight models they tested, with roughly one‑third fewer output tokens. If that holds up, it’s a genuine latency win for agent workloads where you’re fan‑out limited.

Jessica And that’s not just nice for UX, it’s economics. If your planner model is waiting on a hundred subcalls, shaving even a second from each tail adds up. Suddenly using a more expensive planner might be fine because the cheap workers aren’t the bottleneck.

Cathy Right. My unresolved worry is still generality. They show Box’s complex work eval, they show AutomationBench and Terminal‑Bench four point zero, they show code and photo workflows. Those are all friendly to bounded, repetitive tasks. If your agent is doing fuzzy, long‑horizon reasoning itself, Ember might not be your tool.

Jessica I think Meta’s actually clear on that, though. The line is basically: use Ember for repeated, bounded work, pair it with Spark or Wonder when you need deeper planning and orchestration. So if someone tries to use Ember as their only brain for a research agent, that’s kind of on them.

Cathy Fair. And they did ship a pretty clean on‑ramp. If you already have something on the OpenAI S D K, they’re basically saying, generate a key on dev dot meta dot ai, change your base U R L, and set model to muse‑ember one point zero. That’s minimal friction for trying it as a drop‑in small model.

Jessica Yeah, that’s the thing I’d actually test next: take an existing harness where you already have a “cheap model” tier, point that tier at Ember, and watch three things for a week: total cost per workflow, p ninety‑five latency, and how often the planner has to redo work because the subagent messed up.

Cathy If those three move in the right direction, great, keep it. If not, you’ve learned something real about your workload shape. Either way, it’s nice that Meta’s giving a concrete, cheap knob to turn instead of just another giant flagship model.

Jessica Yeah, for once the interesting story is the small one, not the shiny top‑end. I’ll take that.