There's usually a reasonably strong correlation between thinking level and visual quality of the pelican. This is the first time I've seen that correlation appear to break - more reasoning tokens doesn't seem to produce an obviously better SVG.
Re:Our Smallest, Most Efficient Model: Muse Ember
by simonw on Monday November 09, 2026 @05:17PM
(#50433063)
I was at my dog's sniffing class for this one, but I had Codex on my Mac (controlled from Codex on my iPhone) run the test prompt with my `llm-meta-ai` plugin, which has the ability to refresh to fetch new models that Meta AI have released: https://github.com/simonw/llm-meta-ai#usage
Re:Our Smallest, Most Efficient Model: Muse Ember
by imimayj1337 on Monday November 09, 2026 @01:41PM
(#50429670)
It does pretty insane to me that only on max setting (and after waiting 27 seconds) did you actually manage to receive an SVG where the pelican's legs are straddling the bike correctly.
Re:Our Smallest, Most Efficient Model: Muse Ember
by swatcoder on Monday November 09, 2026 @01:56PM
(#50429911)
They're not. It's an illusion from the composition.
If you look at the code for each of these (and probably most across models), you can see that the drawing elements are organized by concept. Presumably, this helps accuracy by keeping attention on one concept at a time, but you end up with a stack of conceptualized objects and lose the ability to interleave things.
No doubt these could all do better with a more thorough and specific prompt that coached them away from that technique, but otherwise it's a very subtle detail that a "thinking" process needs to stumble upon independently.
Re:Our Smallest, Most Efficient Model: Muse Ember
by flir on Monday November 09, 2026 @02:12PM
(#50430186)
You could use a second prompt to z-order the objects (I tend to break down tasks and pipeline them, rather than trying to stuff everything in a one-shot prompt. Seems to work better for me, could be a holdover from the early days).
Re:Our Smallest, Most Efficient Model: Muse Ember
by serf on Tuesday November 10, 2026 @12:52AM
(#50436586)
>Fortunately, none of the stores caught onto my grandmother's preference for blueberry pie filling.
I think that's exactly it though. When a trend develops for something, the benchmark itself becomes useless both from the social-gaming side and the corporate-trainining-aiming, just general unfairness and dishonesty all around.
and to get around that people have developed personal and private benchmark suites that reflect their own workloads, much like the proposed pie-filling-cost test.
Re:Our Smallest, Most Efficient Model: Muse Ember
by viraptor on Monday November 09, 2026 @04:01PM
(#50432067)
To be fair, people have a genuine preference for images with things facing to the right. And lots of drawings will do 3 motion lines. You'd likely draw a dashed rather than solid separator too, or it would look like a random line. Lots of the AI habits are there because of choices we make.
Re:Our Smallest, Most Efficient Model: Muse Ember
by viraptor on Tuesday November 10, 2026 @07:10AM
(#50439187)
Doesn't it, or do we not know the answer? I'd ask people to start adding elements to the picture and see how quickly the fish appears.
There aren't that many associations left once we're primed with a bike and a pelican. It's like that old mental trick "What's the colour of the clouds? What's the colour of the snow? What do cows drink?"
Re:Our Smallest, Most Efficient Model: Muse Ember
by AlecSchueler on Tuesday November 10, 2026 @04:00AM
(#50437756)
> The shorter and vaguer a prompt you give to an LLM, the more it fills in further details using associations they've developed through training.
I can see that for stuff like facing right because characters in images generally do face right, and roads generally do have dashed white line separators. But putting a fish in a basket seems like a stretch of creativity—one that I would rather it not make unless prompted to—so it's surprising that every single model now seems to insist on it.
Re:Our Smallest, Most Efficient Model: Muse Ember
by dstu on Tuesday November 10, 2026 @05:06AM
(#50438179)
The models do all seem to converge in ways that, on occasion, wouldn’t seem obvious. But I suppose since they’re all products of the same core training data it’s inevitable that when they’re given the opportunity to fill in the blanks they come to the same conclusions. This seems to be true regardless of what modality you’re working with.
If there isn’t a concerted effort against it the world is going to start to look and feel ever more homogenous.
Re:Our Smallest, Most Efficient Model: Muse Ember
by ezst on Monday November 09, 2026 @02:38PM
(#50430710)
Wouldn't that be a sign that those models were trained to optimise that test case specifically, as in, by exhibiting equal or higher performance while using less power?
Re:Our Smallest, Most Efficient Model: Muse Ember
by 9dev on Monday November 09, 2026 @05:57PM
(#50433519)
At this point, even if the labs wouldn’t actively pelican-max their models, isn’t the training corpus full of pelicans already? Funny to think how one models choice of adding a red scarf in one of Simon’s earlier experiments might have led to an archetype of pelicans riding bicycles…
Re:Our Smallest, Most Efficient Model: Muse Ember
by flir on Tuesday November 10, 2026 @08:08AM
(#50439790)
Not just pelicans, but pelicans with commentary about how good they are. simonw is accidentally running the world's least efficient hill climbing algorithm.
Re:Our Smallest, Most Efficient Model: Muse Ember
by wormius on Monday November 09, 2026 @08:50PM
(#50435073)
I'm wondering if this is about size. I noticed it took me 2 scrolls on the max, 3 scrolls up the code on whatever in the middle I clicked, and then 4 scrolls up for the minimal.
I'm guessing it's optimizing for "efficient"/less verbose output?
Re:Our Smallest, Most Efficient Model: Muse Ember
by InsideOutSanta on Tuesday November 10, 2026 @05:31AM
(#50438371)
But which effort level should I use for the decider model?
(I think there's at least some evidence that it is difficult for decider models to predict the complexity of a task ahead of time with any level of reliability.)
Re:Our Smallest, Most Efficient Model: Muse Ember
by adrian_b on Tuesday November 10, 2026 @05:51AM
(#50438508)
Even now, after so many bicycles, none of them overlaps correctly the elements according to their 3D positions, so it is still very easy to distinguish the drawings done by an LLM from those done by any competent human.
Re:Our Smallest, Most Efficient Model: Muse Ember
by Starlevel004 on Monday November 09, 2026 @01:40PM
(#50429661)
Luna 6 is getting a bit long in the teeth now. It's two full months old, but it was only a slight step above Luna 5.6, which was already four months old (Imagine saying this about anything else). So I'm not too surprised that a newer small model is beating it handily. I've been hoping for Luna 6.1/2 as the next model release for a few days now.
Re:Our Smallest, Most Efficient Model: Muse Ember
by agentdev001 on Monday November 09, 2026 @01:55PM
(#50429893)
Give Terra 6.1 Low a spin in places where you'd have previously used Luna Max. Costs seem similar, due to Terra being much smarter: thus requiring far fewer tokens per task.
Looking solely at AA's intelligence index, recognizing the pitfalls with using that as a measure- Luna 6 Max > Terra 6.1 Low is 51.3% cheaper, 94.1% less output tokens, for 1.56 higher index score.
Re:Our Smallest, Most Efficient Model: Muse Ember
by Starlevel004 on Monday November 09, 2026 @02:00PM
(#50429991)
I use Luna xhigh for when I use it, Luna Max spends 40+ minutes overthinking. I've also found that Terra below xhigh will just flat out not do what it is told.
Re:Our Smallest, Most Efficient Model: Muse Ember
by agentdev001 on Monday November 09, 2026 @07:31PM
(#50434475)
Yea, this problem is really clear when you look at output tokens for xhigh vs max. I think the jump in capability from Luna xhigh to terra low is really sold by this. I would say that this is just the nature of being post Terra 6.1, pre-luna 6.1
Re:Our Smallest, Most Efficient Model: Muse Ember
by agentdev001 on Monday November 09, 2026 @07:00PM
(#50434197)
They're both great- but I feel like for folks like me that are working on company's pseudo-infinite token budget, it's really a bimodal game. Im either reaching for the best cheapest for fanned out benchmark runs, or the fastest best for everything else. 6.1 Sol ultrafast is the latter for me, so Terra doesn't really compete with it. Terra has certainly replaced 6 Luna for me, however.
(And yes Astra is a thing, but if im considering Astra, im usually opting for an Anthropic model, 90% of the time.)
Re:Our Smallest, Most Efficient Model: Muse Ember
by agentdev001 on Monday November 09, 2026 @06:54PM
(#50434119)
Im surprised, when I've worked through benchmarking things I've run into comparable costs for Luna Max vs Terra Low. Also anecdotal from me, of course.
Re:Our Smallest, Most Efficient Model: Muse Ember
by caaqil on Monday November 09, 2026 @01:41PM
(#50429683)
I'm always a bit surprised to see Meta talking about models. They have become (almost*) entirely irrelevant to the LLM race, which is weird because their AI lab used to be decent before LLM was cool.
What happened to zuck? Was the meta erse this destructive?
Re:Our Smallest, Most Efficient Model: Muse Ember
by achandra03 on Monday November 09, 2026 @01:46PM
(#50429748)
Isn't Muse Wonder at or at least very close to the frontier? Considering they essentially started from scratch after rebooting their AI efforts post-Llama 4 about a year ago it's pretty solid progress.
Re:Our Smallest, Most Efficient Model: Muse Ember
by crimsoneer on Tuesday November 10, 2026 @04:30AM
(#50437951)
This was true a year ago, but definitely not today. Their biggest models are pretty much at the frontier, and Glimmer is arguably the best non-Chinese model in the "small" weight class (see my hacky benchmark http://botbowlbench.com/)
Re:Our Smallest, Most Efficient Model: Muse Ember
by ImPostingOnHN on Monday November 09, 2026 @05:42PM
(#50433328)
If you refuse to do a job, then you have failed to do the job. If a general purpose tool, like a computer or an LLM, is refusing to do what I instruct it to do, it has failed at that instruction.
Re:Our Smallest, Most Efficient Model: Muse Ember
by anderber on Monday November 09, 2026 @02:28PM
(#50430477)
I honestly have a hard time trying to put these AI companies in some sort of moral hierarchy. They seem to all have issues... I feel like at least with open models you can have more ethical services.
Re:Our Smallest, Most Efficient Model: Muse Ember
by nicce on Monday November 09, 2026 @03:21PM
(#50431427)
Tried to use the download button from the page, but it failed miserable. First, could not press the button because had to decline cookies first. Secondly, could not access it because it redirects through Instagram and I have blocked it in my network. So I still don't know how big it is...
Re:Our Smallest, Most Efficient Model: Muse Ember
by kbrannigan on Monday November 09, 2026 @02:22PM
(#50430375)
This is starting to feel just like the early PC days. A bunch of Computer models coming out, all shapes and color, but eventually it settled around mouse keyboard, monitor
most people, use the office suite: Word, Spreadsheet , presentations, database.
I bet we're going to see the exact same thing with LLMs at specialized models instead of the everything models.
One for lawyers, coders, Accountants, Designers, etc…
Re:Our Smallest, Most Efficient Model: Muse Ember
by grim_io on Monday November 09, 2026 @02:37PM
(#50430659)
I don't think so.
Cross discipline skills are more valuable in the real world, outside of hyper specialization seen in the California tech scene. Even there, it's coming to an end.
Re:Our Smallest, Most Efficient Model: Muse Ember
by drillsteps5 on Monday November 09, 2026 @04:57PM
(#50432839)
Exactly what I was thinking. If this model will be used for coding, does it need to be fed the entire (mostly pirated) collection of works from Anna's Archive? Probably not. Maybe some, primarily computer-science oriented.
The main corpus would be a collection of thoroughly reviewed, clean, logical, well-documented, and secure code in whatever languages this thing will need to be an expert in.
This way we could also look into reasonable compensation agreement with authors of the code and the books/articles, if and when applicable.
Re:Our Smallest, Most Efficient Model: Muse Ember
by ElectricalUnion on Monday November 09, 2026 @06:42PM
(#50433998)
Unless your task happens to be completely contained in the set of your "curated works", that is, trivial and computer-sciency, the resulting model is likely to have for example absolutely no concept of common sense, society, the natural world, what humans consider artistic or of good taste. It will probrably make, say, a good and correct compiler, but fail spetacularly on anything else more complex that a toy crud.
Re:Our Smallest, Most Efficient Model: Muse Ember
by GuB-42 on Monday November 09, 2026 @06:26PM
(#50433841)
Human lawyers, coders, accountants and designers are a lot more than their jobs.
They are people with common knowledge, a lawyer has to understand carpentry to understand how to deal with how a client's roof fell off, a coder has to understand transportation for writing a travel app, an accountant has to understand medicine to to accounting for a pharmacy, a designer how to understand cooking to design a toaster. Not expert knowledge, but enough to understand that toasters are hot and need electricity.
A LLM for people working these jobs also need to have common knowledge, that's the whole point of using LLMs, you can prompt them with intrinsically ambiguous and incomplete natural language and they are supposed to fill in the gaps. And the more common knowledge they have, the better they are at it. So why settle for less? If it is an optimization problem, we already have the solution, it is the "mixture of experts", which is better at optimizing then having an "lawyer LLM", "coder LLM", etc... because it is better adapted to the internal structure of the neural network behind it.
Re:Our Smallest, Most Efficient Model: Muse Ember
by slopnt on Monday November 09, 2026 @02:23PM
(#50430386)
I use haiku and luna for support on most my SWE tasks since they are cheap and fast. I find them enough for most things if you are patient, and the fact an even cheaper model for comparable intelligence is out there now is great news!
Re:Our Smallest, Most Efficient Model: Muse Ember
by mchusma on Tuesday November 10, 2026 @09:19AM
(#50440755)
Interesting but I also think that opus is vastly better than sol. So much sol is almost unusable for me, and this is not really reflected in benchmarks. Anthropic’s issues are mostly refusals. If they did what I want I would only use codex as a double check.
Re:Our Smallest, Most Efficient Model: Muse Ember
by segmondy on Monday November 09, 2026 @02:49PM
(#50430893)
What makes it small? Anyone know the size? I don't see it anywhere. Small in relation to their current line up? Anyways, last I tried Meta was llama4. I stepped aside not because of how bad llama4 got, but also because of Zuck's move. Anyone here using Meta? I don't know anyone in my circle using it, but I'm sure folks are using it.
Re:Our Smallest, Most Efficient Model: Muse Ember
by cheesecompiler on Monday November 09, 2026 @04:05PM
(#50432120)
Sorry but why is my reaction "noise"? It's legitimate to be overwhelmed by the amount of released updates and being unable to tell the difference between them.
Re:Our Smallest, Most Efficient Model: Muse Ember
by groggo on Monday November 09, 2026 @04:10PM
(#50432203)
"Government announces AI ban to avoid further cheesecompiler burnout".
haha just kidding. I agree. That's what benchmarks are for. Just keeping a rough understanding of what companies have which models, and understanding general trends of capabilities, economics, and performance of models.
Re:Our Smallest, Most Efficient Model: Muse Ember
by syntaxing on Monday November 09, 2026 @03:32PM
(#50431618)
What does smallest mean? Even smaller than Muse Glimmer which I doubt? Though it is interesting to see US frontier labs trying to push models that outcompete deepseek flash 1017. It’s a good move from the Deepseek federal government ban. Both Inkling 2 small and this seems to try to fill that gap cost vs performance wise. But I like inkling 2 small more due to open weight even though it has a restrictive license.
Re:Our Smallest, Most Efficient Model: Muse Ember
by rsfern on Tuesday November 10, 2026 @04:28AM
(#50437936)
The open version model card says it had extra safety post-training because meta can’t prefilter prompts with a classifier model if you’re running it on your own hardware. They don’t want to get sued I guess if it comes out that someone used their model irresponsibly or something
Re:Our Smallest, Most Efficient Model: Muse Ember
by ProblemExplorer on Monday November 09, 2026 @04:06PM
(#50432136)
Meta seems to have designed Ember to be a strong "all round" great value model - it dominates most of its class on cost
The noncoding results on some reports grabbed my attention. Ember also looks like a particularly inexpensive option for some agent workflows.
On Artificial Analysis, Ember max scored 36 on the Intelligence Index at ~$0.14 per task, compared with 35 at $8 for Grok 4.7 xhigh, and 28 at $0.15 for GPT-6 Luna max. Haiku 5.5 max also scores 36, at $0.41 per task. These are AA's measured costs across its index for those specific configurations.
That puts Ember in roughly Grok's aggregate score range at about 1/55 of the measured cost, and ahead of Luna at a similar cost! [1]
The Vals finance/legal results are also particularly interesting: comparing Ember with GPT-6.1 Terra, both evaluated at "max" reasoning:
- Finance Agent v2.1: 63.83% vs 55.96%, at $0.06 vs $1.92 (!) per test. [2]
- Legal Research Bench: 49.04% vs 25.96%, at $0.06 vs $3.22 (!) per test. [3]
- HLAB-Vals-1.1: 25% vs 1.67%, at $0.12 vs $1.48 (!) per test. [4]
Those are INSANE score differences, at roughly 1/32, 1/54 and 1/12 of Terra's respective benchmark costs!
Misleadingly, their overall Vals Index scores are almost identical: 60.48% for Ember and 60.54% for Terra. Terra also scores higher on Vals' Terminal-Bench 4.0 run: 49.49% vs 39.39%. They arrive at similar aggregate scores through quite different strengths. [5][6]
For me, this reinforces the case for custom, workload specific evals. Broad benchmarks have been useful for shortlisting models but choosing between them, calls for representative tasks, explicit success criteria and measurements using the tools and reasoning settings you actually intend to deploy.
I certainly want to measure cost per successfully completed task, including retries and escalation.
Reusing a framework such as Harbor with a custom task suite seems increasingly useful here. [7] The aggregate score here gives me a starting point but the tasks I actually need done then determines my choice.
Goign by the generic benchmarks would confuse me to no end and likely burn me out.
Re:Our Smallest, Most Efficient Model: Muse Ember
by system2 on Monday November 09, 2026 @04:44PM
(#50432680)
When a statement starts with "our," I always expect bullshit. Batch pricing is two times cheaper with Haiku. Benchmarks are nearly tied. Nobody uses the dumbest models for coding either.
If you want customers to switch over, you better make the price at least half of your competitor's.
Re:Our Smallest, Most Efficient Model: Muse Ember
by doodlesdev on Monday November 09, 2026 @07:02PM
(#50434219)
Interesting to notice that the best benchmarks of the model are not on Meta's own agent harness, but instead on mini-swe-agent:
> 1. All models run at max reasoning effort. Artificial Analysis results are from Intelligence Index v5, as published November 9, 2026; cost per task uses each model's list pricing. Internal results are from Meta's evaluation suite. The Personal Superintelligence Index (PSI) is an internal composite of eight evaluations: Agents' Last Exam, AutomationBench, FocusBench, JobBench, OfficeQA Pro, GDP.pdf, GDP.xlsx and VBT. Terminal-Bench 4.0 uses each model's best published harness: mini-swe-agent (Muse Ember), Claude Code (Claude Haiku 5.5), and Codex (GPT-6 Luna). OSWorld 2.1 uses partial-credit reward; PerceptionBench is scored with tools.
Re:Our Smallest, Most Efficient Model: Muse Ember
by djacksondev on Monday November 09, 2026 @08:39PM
(#50435007)
When Muse models first started coming out I was pretty excited that Meta models were competitive again based on the benchmarks but after trying them out it feels like Meta is making benchmaxxed models that are exciting on bench cards but not really useful in real world scenarios.
To me that is the main problem with Muse models whether it's Spark, Wonder or Ember. While it reads as frontier on benchmarks it really isn't.
This is evident when you compare Dots and Muse the products as well. The model quality is clearly still far behind.
Re:Our Smallest, Most Efficient Model: Muse Ember
by alex0015 on Tuesday November 10, 2026 @01:20AM
(#50436738)
Spark was my go-to at work (technical writing and docs site) on a Cursor API plan for a few weeks because of its speed and price. I was happy with it and recommended it. Now sufficiently outclassed by Haiku 5.5 for tasks of that size.
Re:Our Smallest, Most Efficient Model: Muse Ember
by trvz on Monday November 09, 2026 @09:50PM
(#50435486)
Who cares. I'll begrudgingly run a local Facebook model if it's the best in its class, but I'll take up Java programming before sending data to their cloud.
https://tools.simonwillison.net/markdown-svg-renderer?url=ht...
There's usually a reasonably strong correlation between thinking level and visual quality of the pelican. This is the first time I've seen that correlation appear to break - more reasoning tokens doesn't seem to produce an obviously better SVG.
There's a blog post in this for sure. And a classic joke.
Btw, loved your work with Django!
If you look at the code for each of these (and probably most across models), you can see that the drawing elements are organized by concept. Presumably, this helps accuracy by keeping attention on one concept at a time, but you end up with a stack of conceptualized objects and lose the ability to interleave things.
No doubt these could all do better with a more thorough and specific prompt that coached them away from that technique, but otherwise it's a very subtle detail that a "thinking" process needs to stumble upon independently.
I think that's exactly it though. When a trend develops for something, the benchmark itself becomes useless both from the social-gaming side and the corporate-trainining-aiming, just general unfairness and dishonesty all around.
and to get around that people have developed personal and private benchmark suites that reflect their own workloads, much like the proposed pie-filling-cost test.
I'd wager a guess that your grandma baked pies.
- simple prompt for complex output (bad)
- complex prompt for simple output (bad)
- simple prompt for simple output (good)
- complex prompt for complex output (.... is this good or bad?)
There aren't that many associations left once we're primed with a bike and a pelican. It's like that old mental trick "What's the colour of the clouds? What's the colour of the snow? What do cows drink?"
I can see that for stuff like facing right because characters in images generally do face right, and roads generally do have dashed white line separators. But putting a fish in a basket seems like a stretch of creativity—one that I would rather it not make unless prompted to—so it's surprising that every single model now seems to insist on it.
If there isn’t a concerted effort against it the world is going to start to look and feel ever more homogenous.
I'm guessing it's optimizing for "efficient"/less verbose output?
(I think there's at least some evidence that it is difficult for decider models to predict the complexity of a task ahead of time with any level of reliability.)
https://openrouter.ai/stealth/crouton-alpha
* context window size
* reasoning effort levels
* max output size
* knowledge cutoff
* restricted country list
* self-reported "reasoning strength" and "internal reasoning channel" params used in other Meta models
Looking solely at AA's intelligence index, recognizing the pitfalls with using that as a measure- Luna 6 Max > Terra 6.1 Low is 51.3% cheaper, 94.1% less output tokens, for 1.56 higher index score.
(And yes Astra is a thing, but if im considering Astra, im usually opting for an Anthropic model, 90% of the time.)
They weren't, unfortunately, every time I tried. Just an anecdote, of course.
The artificial analysis graph is not very accurate.
These are both models that I could see using on a long horizon.
Javascript frameworks, circa 2016 ;)
Same. It became my workhorse after the 5.6 price drop. Still so, although it's showing its age, as you said.
What happened to zuck? Was the meta erse this destructive?
(*) Feeling charitable today
Treating the refusal as a 0 score erases the difference between lack of capability and a lack of willingness to perform.
Seriously. Moral harm is real and there is no excuse.
most people, use the office suite: Word, Spreadsheet , presentations, database.
I bet we're going to see the exact same thing with LLMs at specialized models instead of the everything models.
One for lawyers, coders, Accountants, Designers, etc…
Cross discipline skills are more valuable in the real world, outside of hyper specialization seen in the California tech scene. Even there, it's coming to an end.
The main corpus would be a collection of thoroughly reviewed, clean, logical, well-documented, and secure code in whatever languages this thing will need to be an expert in.
This way we could also look into reasonable compensation agreement with authors of the code and the books/articles, if and when applicable.
Has no one tried that?
They are people with common knowledge, a lawyer has to understand carpentry to understand how to deal with how a client's roof fell off, a coder has to understand transportation for writing a travel app, an accountant has to understand medicine to to accounting for a pharmacy, a designer how to understand cooking to design a toaster. Not expert knowledge, but enough to understand that toasters are hot and need electricity.
A LLM for people working these jobs also need to have common knowledge, that's the whole point of using LLMs, you can prompt them with intrinsically ambiguous and incomplete natural language and they are supposed to fill in the gaps. And the more common knowledge they have, the better they are at it. So why settle for less? If it is an optimization problem, we already have the solution, it is the "mixture of experts", which is better at optimizing then having an "lawyer LLM", "coder LLM", etc... because it is better adapted to the internal structure of the neural network behind it.
https://ai2027-tracker.com/predictions/china-model-gap/
Notable cache cost of 4% input, compared to Luna/Haiku's 10% of input.
haha just kidding. I agree. That's what benchmarks are for. Just keeping a rough understanding of what companies have which models, and understanding general trends of capabilities, economics, and performance of models.
The noncoding results on some reports grabbed my attention. Ember also looks like a particularly inexpensive option for some agent workflows.
On Artificial Analysis, Ember max scored 36 on the Intelligence Index at ~$0.14 per task, compared with 35 at $8 for Grok 4.7 xhigh, and 28 at $0.15 for GPT-6 Luna max. Haiku 5.5 max also scores 36, at $0.41 per task. These are AA's measured costs across its index for those specific configurations.
That puts Ember in roughly Grok's aggregate score range at about 1/55 of the measured cost, and ahead of Luna at a similar cost! [1]
The Vals finance/legal results are also particularly interesting: comparing Ember with GPT-6.1 Terra, both evaluated at "max" reasoning:
- Finance Agent v2.1: 63.83% vs 55.96%, at $0.06 vs $1.92 (!) per test. [2]
- Legal Research Bench: 49.04% vs 25.96%, at $0.06 vs $3.22 (!) per test. [3]
- HLAB-Vals-1.1: 25% vs 1.67%, at $0.12 vs $1.48 (!) per test. [4]
Those are INSANE score differences, at roughly 1/32, 1/54 and 1/12 of Terra's respective benchmark costs!
Misleadingly, their overall Vals Index scores are almost identical: 60.48% for Ember and 60.54% for Terra. Terra also scores higher on Vals' Terminal-Bench 4.0 run: 49.49% vs 39.39%. They arrive at similar aggregate scores through quite different strengths. [5][6]
For me, this reinforces the case for custom, workload specific evals. Broad benchmarks have been useful for shortlisting models but choosing between them, calls for representative tasks, explicit success criteria and measurements using the tools and reasoning settings you actually intend to deploy.
I certainly want to measure cost per successfully completed task, including retries and escalation.
Reusing a framework such as Harbor with a custom task suite seems increasingly useful here. [7] The aggregate score here gives me a starting point but the tasks I actually need done then determines my choice.
Goign by the generic benchmarks would confuse me to no end and likely burn me out.
Great times to be in!
[1] https://artificialanalysis.ai/leaderboards/models
[2] https://www.vals.ai/benchmarks/fabv2-1
[3] https://www.vals.ai/benchmarks/legal_research
[4] https://www.vals.ai/benchmarks/hlab
[5] https://www.vals.ai/models/meta_muse-ember
[6] https://www.vals.ai/models/openai_gpt-6.1-terra
[7] https://github.com/harbor-framework/harbor
If you want customers to switch over, you better make the price at least half of your competitor's.
How do we know it is small? How many bytes does it consume on-disk and in-memory?
To me that is the main problem with Muse models whether it's Spark, Wonder or Ember. While it reads as frontier on benchmarks it really isn't.
This is evident when you compare Dots and Muse the products as well. The model quality is clearly still far behind.
You can get deepseek v4.1 flash 1017 for cheaper than this from a US based ZDR provider via Openrouter.