Muse Ember API Pricing, Context Limits, and the November 9 Bench Notes

Meta put Muse Ember on the Meta Model API on November 9, 2026. The @AIatMeta post at 18:04 UTC states the list price in one sentence: $0.10 per million input tokens and $0.50 per million output tokens, and points at the research blog through https://go.meta.me/muse-ember. The blog page is dated the same day. It names the model id muse-ember-1.0. It also prints a second price card that the tweet does not carry: cached input at $0.004 per million tokens, a 1 million token context window, up to 512,000 output tokens, and a higher rate once a prompt passes 200,000 tokens.

That second card is the one an agent bill will actually hit if the prompt is large. The headline rate covers prompts up to 200,000 tokens. Above that line, the same page lists $0.30 per million input tokens, $0.012 per million cached input tokens, and $1.50 per million output tokens. A team that dumps a repository into the 1 million token window is not paying the number in the tweet. It is paying the long-prompt row, on the input dump and on whatever the model writes back.

This piece stays inside those two pages, plus the evaluation report the blog links, plus the one official post. It does not treat partner quotes as lab scores, and it does not fill gaps the pages leave blank.

What the pages say the model is for

The blog’s opening paragraph calls Muse Ember the smallest and most efficient model in the current Muse line, built for complex reasoning execution and for work agents repeat: tool calls, coding subtasks, routing, extraction, and long document parsing. It is a hosted model on Muse Code and the Meta Model API. The availability section says it supports the Responses API. The same section says Muse Ember, Muse Spark, and Muse Wonder are available on Google Cloud and on Oracle Cloud.

The portfolio sentence is the useful one for anyone who already bought a Muse SKU. Muse Wonder is described as the model for the hardest problems. Muse Spark is described as the model for coding and agentic workflows. Muse Ember is described as the model for repeatable coding and agentic tasks at scale, at about $0.14 per Artificial Analysis task. The comparison table on the same page puts Muse Spark 1.3 at an Intelligence Index of 37 and a cost per Intelligence Index task of $2.39, against Ember’s 36 and $0.14. Spark 1.3’s listed token price in that table is $1.25 per million input tokens and $4.25 per million output tokens.

The September note on this site logged Muse Spark 1.3 when it arrived in the same week as Claude Fable 5.1 and Gemini 3.8 Flash: Anthropic, Google, and Meta in the same week. Ember does not replace that note. It adds a cheaper sibling with a published token price and a published long-prompt surcharge. The September piece was about which version numbers changed a subscription page. This one is about which row on an API invoice changes when a subagent runs all day.

Muse Image, the generator covered in the July Muse Image note, is a different product. Ember’s blog does not describe image generation. It describes text, image, audio, and video as inputs the model can read, so an agent can work from screenshots, charts, scanned documents, voice memos, meeting recordings, and video without a separate model. Input is not the same slot as a drawing tool.

The blog also says Ember is the first model trained using Muse Wonder Full, and that more efficient models are in training. That is a roadmap sentence. It is not a spec for a model id you can call today. The callable object on November 9 is muse-ember-1.0, with the two price cards below.

Two price cards, and a multiplication of each

The tweet and the blog agree on the short-prompt meter: $0.10 per million input tokens and $0.50 per million output tokens. The blog adds the cache rate and the long-prompt rate. The footnote is explicit that the $0.10 / $0.50 card is for prompts up to 200,000 tokens. Longer prompts move to $0.30 / $0.012 / $1.50.

These figures are list prices on the page, not a measured invoice from a customer. Multiplying them is still worth doing, because the 1 million token window makes the boundary easy to cross without noticing.

Take a short call: 50,000 input tokens and 2,000 output tokens, under the 200,000 line, with no cache. Input is 0.05 times $0.10, which is $0.005. Output is 0.002 times $0.50, which is $0.001. The sum is $0.006. If a later turn reuses that same 50,000 token prefix from cache, cached input is 0.05 times $0.004, which is $0.0002, and the 2,000 output tokens are still $0.001. The cached turn sums to $0.0012. The saving is real only when the prefix repeats. A fresh repository does not repeat.

Take a long call: 250,000 input tokens and 2,000 output tokens. The input has crossed 200,000, so the long card applies. Input is 0.25 times $0.30, which is $0.075. Output is 0.002 times $1.50, which is $0.003. The sum is $0.078. Same output length as the short example. The input dump, not the answer, is the bill. A loop that sends a 250,000 token tree on every uncached turn pays that input row every time. Cache on the long card is $0.012 per million, which is three times the short-card cache rate and still far below the uncached long input rate. The page does not say how cache hits are counted, or whether a prompt that mixes a cached prefix with a new suffix is billed on the long card for the whole request once the total passes 200,000 tokens. That billing detail is absent. The two published cards are not.

The $0.14 figure in the Spark comparison is a different unit. It is a cost per Artificial Analysis Intelligence Index task at list pricing, rounded in the comparison table. It is not the tweet price. Mixing a token rate with a task cost produces a nonsense invoice. Use $0.10 and $0.50, or the long card, when the question is “what does this call cost.” Use $0.14 when the question is “what did Meta say this benchmark mix cost on November 9.”

The efficiency sentence, and the chart under it

The blog claims Muse Ember delivers more intelligence per dollar than Claude Haiku 5.5 or GPT-6 Luna at any reasoning setting. The specific comparison is that it matches Haiku’s best score at about a third of the cost and beats every Luna setting. It also says no model on the full Artificial Analysis leaderboard scores higher for less per task. The chart caption says Muse Ember costs are estimates at proposed pricing. The footnote says Artificial Analysis results are from Intelligence Index v5, as published November 9, 2026, with cost per task using each model’s list pricing.

The points printed on that chart are specific enough to check the “about a third” phrase without taking the slogan on faith.

Muse Ember is plotted at $0.116 per task with a score of 33.9, and at $0.136 per task with a score of 35.8. Claude Haiku 5.5 is plotted at $0.092 with 24.6, $0.159 with 29.6, $0.248 with 34.3, and $0.411 with 36.2. GPT-6 Luna is plotted at $0.073 with 21.4, $0.104 with 23.3, and $0.152 with 27.8.

Haiku’s highest printed score is 36.2 at $0.411. Ember’s higher printed score is 35.8 at $0.136. Divide 0.136 by 0.411 and the ratio is about 0.33. One third of $0.411 is $0.137, which sits next to the $0.136 point. That is the arithmetic behind “about a third.” It is a comparison of those two plotted points. It is not a claim that 35.8 equals 36.2. It is not a claim that every Ember setting beats every Haiku setting. Haiku’s cheapest printed point, 24.6 at $0.092, costs less than either Ember point and scores lower. A buyer who only needs that lower band is not looking at the sentence Meta highlighted.

The Luna points on the printed chart top out at 27.8 in the table that accompanies the chart. The prose says Ember beats every Luna setting. The page’s prose is broader than the three Luna rows printed beside the chart. A reader should treat “every Luna setting” as Meta’s summary of the Artificial Analysis chart, and treat the three printed Luna rows as the numbers this article can repeat without guessing at a fourth point that was not in the table.

The chart caption’s phrase “estimates at proposed pricing” also limits how far the $0.116 and $0.136 points should travel. The tweet and the blog agree on $0.10 and $0.50 as the live list price. They do not print a revision log that ties those token rates to the chart’s task costs. If the proposed price used to draw the chart differed from the price in the tweet, the points need a refresh the page does not provide. Use the token card for contracts. Use the task-cost chart as a November 9 snapshot, labeled as an estimate in Meta’s own caption.

Scores at max, and who ran the harness

The evaluation table is labeled at max reasoning. The footnote says all models in that table run at max reasoning effort. That matters, because the chart above it shows several effort settings, and the table below it does not. A team that will run Ember on a cheaper effort setting cannot read the table as its expected score. The blog does not publish a score table for medium or high. It publishes the chart points above, and the max table below.

At max, the blog lists these results for Muse Ember, Claude Haiku 5.5, and GPT-6 Luna.

AutomationBench-AA, end-to-end business workflows: 37.8, 13.9, and 20.2. The evaluation report says this is Artificial Analysis’s run of Zapier’s private set of 657 business-workflow tasks across simulated SaaS applications such as Gmail, Salesforce, and Slack. Agents complete each workflow through the applications’ APIs. Deterministic checks inspect the final state. The metric is pass@1, which Artificial Analysis calls Tasks Completed: every objective met and no guardrail violated. The source line is Artificial Analysis, dated November 9, 2026, strict pass@1. A 37.8 against 13.9 and 20.2 is a large gap on a private set. Private sets cannot be re-run from the blog alone. The number is citable. The tasks are not attached.

Agents’ Last Exam: 61.6, 57.0, and 57.1. The blog footnote calls this a Meta internal evaluation on the Linux subset. The report says the lab used ALE v1.0 and its Linux task split, dropped five of 105 tasks for every model because input data exceeded the evaluation environment’s storage limit or scripts returned no score, and graded each remaining task with its native script. Partial credit runs from 0 to 1. The few LLM-judged checks use GPT-5.5. Every model ran in a common internal agent loop. The report says the official leaderboard instead compares agent products such as Codex and Claude Code. The primary metric is the mean task score. This is not the public product leaderboard. The gaps, 61.6 against 57.0 and 57.1, are small next to the AutomationBench gap. A small gap inside a shared internal loop is a different kind of result from a large gap on a private external set.

Personal Superintelligence Index: 46.8, 36.1, and 37.0. The report says PSI is an internal composite of eight evaluations: Agents’ Last Exam, AutomationBench, FocusBench, JobBench, OfficeQA Pro, GDP.pdf, GDP.xlsx, and VBT. The blog footnote lists the same family, with OfficeQA Pro and GDP.xlsx named in the report’s method section. An internal composite can be useful to the lab that built it. It is not a number a second lab has reprinted on this page. The components are not equally external. AutomationBench-AA and GDP.pdf are attributed to Artificial Analysis. FocusBench and VBT are described as internal. Averaging them into 46.8 does not make the internal parts external.

Terminal-Bench 4.0: 40.9, 39.2, and 16.4. The blog footnote is the line to read before the ranking. Ember’s result uses mini-swe-agent. Haiku’s uses Claude Code. Luna’s uses Codex. The report adds that the set has 66 harder tasks in isolated terminals, with executable verifiers on the final container state. Ember’s number is Artificial Analysis’s run in mini-swe-agent. Haiku’s number is Anthropic’s self-reported Claude Code result from the Claude Haiku 5.5 system card. Luna’s number is the Codex result on the Terminal-Bench leaderboard. A 1.7 point gap between 40.9 and 39.2, produced in three different harnesses, with one score self-reported by the vendor being compared, is not a clean model ranking. It is a published-harness snapshot. The gap is smaller than the method difference. Luna’s 16.4 on that row is far lower, and it is also a different harness. The report does not claim the three numbers were produced by the same agent loop.

Coding Agent Index-AA: 46, 37, and 31. The report says Artificial Analysis Coding Agent Index v2.0 combines Terminal-Bench 4.0, SWE-Atlas-QnA, and FrontierCode v1.1, each run inside a coding agent: Muse Code for Ember, Claude Code for Haiku, and Codex for Luna. The source is Artificial Analysis. Same pattern as Terminal-Bench. The agent product is part of the score. A buyer comparing model weights, rather than model-plus-vendor-agent, cannot treat 46 against 37 as a weight-only result.

FrontierCode 2.0-AA: 27.2, 34.9, and 25.2, with Haiku marked as the best result. The report says FrontierCode 2.0 comes from Cognition, grades whether a maintainer would merge the change, and that Artificial Analysis runs a private 132-task set. The metric is accuracy. This is the row that keeps the launch from being a sweep. On the mergeability set Meta chose to print, Haiku leads by 7.7 points. Ember still leads Luna on that row, 27.2 against 25.2. A routing policy that sends every hard patch to Ember because the Intelligence Index is tied would be ignoring the one external coding row where the cheaper model loses by a margin larger than the Terminal-Bench gap.

GDP.pdf-AA: 22.8 for Ember, 22.8 for Luna, and 20.8 for Haiku, with Ember and Luna tied for the best printed result. The report says GDP.pdf comes from Surge and evaluates professional work grounded in supplied PDF material. Artificial Analysis runs its own version: each model receives the PDF’s extracted text plus page images, answers without tools, and a judge checks every rubric criterion separately. The metric is all-pass, the share of answers that meet every criterion. The absolute scores are low. A tie at 22.8 is a tie on a hard professional-document set, not evidence that either model is finished at that job. Haiku’s 20.8 is close. None of the three is in a range where a 2 point gap should decide a document workflow by itself.

OSWorld 2.1: Ember 69.5 partial and 33.8 binary, Haiku 68.9 partial and 27.8 binary, Luna 50.5 partial and 17.0 binary. The chart in the blog body shows the partial scores. The table prints both. The footnote says OSWorld 2.1 uses partial-credit reward and that the run is a Meta internal evaluation. The report says the set is 108 long-horizon computer-use workflows on a live Ubuntu desktop, operated through screenshots and mouse and keyboard actions. Each task’s evaluator awards partial credit on the final machine state. Model-based checks are judged by Claude Sonnet 4.6. Every model ran in a common internal framework rather than each provider’s computer-use product. Binary scores, the share of tasks with full credit, are much lower than partial scores for all three. A demo that quotes 69.5 without the 33.8 is quoting the generous metric. The partial gap between Ember and Haiku is 0.6 points. The binary gap is 6.0 points, 33.8 against 27.8. Which gap you cite changes the story. The page prints both. A fair summary prints both.

PerceptionBench with tools: 80.6, 78.6, and 62.8. The report attributes the benchmark to Moonshot AI: 3,000 verified questions with short, uniquely determined answers, across counting, localization, depth, OCR, and perception-related hallucination. Meta ran all 3,000 in a common internal framework where the model can inspect the image in a sandbox with a file viewer. The official judge named in the report is gpt-oss-120b. The metric is pass@1. The blog labels the row “with tools.” A no-tool number for Ember is not on this page. Luna’s 62.8 is the large gap on this row. Ember and Haiku are 2 points apart, 80.6 against 78.6, inside a tool-using sandbox Meta configured.

Artificial Analysis Index: 36, 36, and 28. Ember and Haiku tie. Luna sits 8 points lower on this printed row. The report says Intelligence Index v5.0 combines AA-Briefcase, AutomationBench, GDP.pdf, FrontierCode 2.0, Terminal-Bench 4.0, Terminal-Bench-Science, CritPt, AA-Omniscience, and HLE-Diamond. The source is Artificial Analysis. The index tie is the number that matches the “about a third of the cost” story, once you pair it with the chart prices rather than with the tweet’s token rate. A tie at 36 does not survive contact with FrontierCode 2.0, where Haiku leads. The index is an average. The row that loses is still a row.

Method notes that change how far a score can travel

The report’s general rules belong next to the table, because they move agent scores even when the headline number looks clean.

Truncated responses are graded as-is. Refusals receive zero and stay in the denominator. They are not dropped. Samples lost to infrastructure or grading errors are not scored. Those rules can move a mean on a long agent task, where truncation and refusal are common. The page does not publish how often Ember truncated or refused on each set. The absence is a limit on how far the table can travel. It is not, by itself, a hidden failure. A hidden failure would be a number the page invented. This is a number the page omitted.

Internally generated competitor runs are described as best-effort. Prompts, tools, and runtime may not be optimally tuned for proprietary models. That sentence covers the internal rows: Agents’ Last Exam, PSI components run in-house, OSWorld, PerceptionBench. It does not erase Artificial Analysis rows, which the report attributes to Artificial Analysis. It does mean a 4 point internal gap is a reason to retest, not a reason to delete the other vendor from a shortlist on the afternoon of the post.

A few component benches inside PSI have their own method lines, and they are easy to miss because the blog prints only the composite.

JobBench, as described in the report, contains 65 professional tasks across 35 white-collar occupations. Each task asks for a practical work product and is scored against task-specific rubrics by a Grok 4.3 judge, in the OpenCode harness used on the official leaderboard. The metric is mean reward. That judge choice is part of the score. A lab using a different judge will not reproduce the reward even if the agent output is identical.

OfficeQA Pro V2, from Databricks, is described as 90 questions on the U.S. Federal Accounts of Receipts and Expenditures, 1,435 documents spanning 1793 to 2024, graded by the official scorer with a 0 percent tolerance. The report says the agent works in a bash sandbox with the cited documents staged as parsed text, plus a browser tool with benchmark sites blocked. The metric is pass@1. A 0 percent tolerance scorer is strict. A near miss is a miss.

GDP.xlsx, from Surge, is described as 70 tasks in 13 domains, graded against expert rubrics. The report says Gemini 3.8 Flash grades each rubric on the final response, as in the official harness, while Meta’s agent loop replaces the official OpenHands loop. The judge model and the agent loop are both part of the number. Neither is Ember.

Verifiable Browsing Task is described as an internal web-browsing evaluation: list-style questions written as realistic requests, answered with browser search, open, and find tools. FocusBench is described as an internal evaluation of personal agent tasks across housing, travel, IT, and finance, including work through blockers across multiple turns. Neither has an outside leaderboard link on this page.

None of those component details replace the published PSI scores of 46.8, 36.1, and 37.0. They explain why a second team should not expect to hit 46.8 by calling muse-ember-1.0 once and eyeballing the answer.

What a buyer should not collapse

Three distinctions are doing the work in this release. Collapsing any of them changes the purchase.

First, external rows and internal rows are not the same evidence. AutomationBench-AA, the Artificial Analysis Index, Coding Agent Index-AA, FrontierCode 2.0-AA, GDP.pdf-AA, and the Ember Terminal-Bench run are attributed to Artificial Analysis, with the Haiku and Luna Terminal-Bench numbers coming from other published harnesses. Agents’ Last Exam, the Personal Superintelligence Index, OSWorld 2.1, and PerceptionBench with tools are Meta’s own runs, even when the underlying benchmark has an outside author. The report is plain about this. A gap on an internal row is a gap inside Meta’s harness. Weight the Artificial Analysis rows higher until an outside lab reprints the internal numbers. Do not average the columns into one win rate. The FrontierCode loss and the AutomationBench lead would cancel in a naive average and hide both facts.

Second, the token price and the task price answer different questions. $0.10 and $0.50 tell you the meter for a short prompt. $0.30 and $1.50 tell you the meter once the prompt passes 200,000 tokens. $0.14 tells you what Meta said Artificial Analysis’s task mix cost at list pricing, and the chart caption says Ember’s chart costs are estimates at proposed pricing. The tweet and the blog agree on $0.10 and $0.50. They do not print a revision log for the chart estimates. Contracts should cite the token card. Benchmark memos should cite the chart and the date.

Third, the long-prompt surcharge is not a side note on a model sold with a 1 million token window and a 512,000 token output cap. The blog’s own pitch is that Ember can take a full codebase or document set in a single call. That pitch points at the over-200,000-token card. Cache at $0.004, or $0.012 on the long card, only helps when the prefix repeats. A one-shot dump of a new repository does not repeat. A subagent that re-sends the same system prompt and the same file tree on every turn does. The invoice depends on which of those two loops you actually run. The output cap of 512,000 tokens is a limit, not a target. A 512,000 token completion at the long output rate would be 0.512 times $1.50, which is $0.768 before input. The page does not say that length is typical. It says the cap exists. Planning as if every call hits the cap would invent a bill the page does not claim.

Partner sentences, kept as partner sentences

The blog quotes five companies. None of those quotes is an Artificial Analysis row.

Box, through Yashodha Bhavnani, VP of AI Products, says that on the Box AI Complex Work Eval, Muse Ember can score a contract against a company’s negotiation playbook clause by clause and land on an overall risk rating, or screen candidates against a detailed brief and flag borderline alternates. The quote calls it a fast, efficient foundation for agents doing real work on enterprise content. No pass rate is in the quote. The eval name is Box’s, not Artificial Analysis’s.

Cline, through founder Saoud Rizwan, describes Ember as a lightweight model for developers who want a fast, low-cost model, and for teams cutting cost by running it as the subagent in a harness. The quote says it is purpose-built for subagent work such as coding and document analysis. No score is attached.

Oracle, through Konstantinos Papamiltiadis, SVP of Global Partnerships, says early testing showed an encouraging ability on complex engineering tasks, and that Oracle sees potential for engineering teams. The sentence does not name a benchmark, a harness, or a date range beyond the launch post.

Cloudflare, through CTO Dane Knecht, says Ember ran up to 30 percent faster at the tail than the comparable model Cloudflare tested, and handled broad multi-repo investigation tasks. The quote does not name the comparable model. “Up to 30 percent” is Cloudflare’s comparison, not a number from the evaluation report. Tail latency without a named baseline and without a percentile is a direction, not a spec.

You.com, through inference lead Chak Pothina, says Ember completed every coding quest in their testing with the lowest latency of any model they tested: a p95 of 2.2 seconds, about 4x to 13x faster than leading open-weight models, and with 36 to 48 percent fewer output tokens. That is the most numeric partner sentence on the page. It is still a partner sentence. The open-weight models are not named. The quest set is not linked. A procurement note can record it as a vendor claim from You.com, dated by the November 9 post, and then ask which models sat at the 4x end and which sat at the 13x end. Until those names are public, the range cannot be checked from this page.

None of these quotes say an outside newsroom ran the product. This article does not add that claim. Partner quotes are deployment signals from companies named on the launch page. They sit beside the table. They do not replace it.

Safety language, and what it does not include

The safety section says Muse Ember was evaluated under the Meta Superintelligence Scaling Framework before release, including chemical and biological risks, cybersecurity risks, and loss-of-control risks. Across the categories assessed, the evaluations found the model remained below the framework’s high-risk thresholds. The page says a small model received the same core safety training and testing as the line it sits in. It also says the lab evaluated behavior when the model acts for a user: whether it respects user intent, handles sensitive information appropriately, resists instructions hidden in web pages, documents, or tool outputs that try to redirect it, and seeks human input before high-impact actions.

That paragraph names categories. It does not publish threshold values, refusal rates, or attack-success rates. A security review that needs those rates will not find them on this page. The useful fact is the scope: the lab says it ran the small model through the same framework categories, including resistance to instructions hidden in tool outputs, and says the result sat below its high-risk line. The missing fact is the measurement. Defense planning still starts from the buyer’s own traces, on the buyer’s own tools, not from a threshold that was not printed.

The cybersecurity category in a scaling framework is not a how-to. The page does not publish attack procedures, and this article does not add any. The operational point for a team wiring Ember into a browser or a document tool is the sentence Meta did print: hidden instructions in pages, documents, and tool outputs were in the evaluation scope, and human input before high-impact actions was in the evaluation scope. Whether that behavior holds on a given connector is a test the buyer still has to run. The launch page does not substitute for that test.

The same afternoon, a different lab, a shorter post

The Meta price post is timestamped 18:04:17 UTC on November 9. Fifty-three minutes and 43 seconds later, @claudeai posted at 18:58:00 UTC, as a reply to its own earlier status. The text says Fable 5.2 and Mythos 5.2 are a step above Opus 5.5 in almost all the capabilities Anthropic evaluated, that testers found clearer communication than past Fable and Mythos models, and that the models generate outputs up to 30 percent faster than Fable 5.1 and Mythos 5.1.

That status does not include a price, a model id, a context length, a cache rate, or a link to a spec page. This article does not import a price for Fable 5.2 from other accounts posted the same week. The only Fable 5.2 sentences used here are the ones in that official post. Relative speed against 5.1 is not a token rate. A step above Opus 5.5 “in almost all the capabilities we evaluated” is not a table. The capabilities are not listed in the status.

The contrast with Ember is operational. Meta’s cited post and blog give a buyer a meter, a long-prompt surcharge, a model id, a context window, an output cap, and a footnote on who ran each harness. Anthropic’s cited post gives a relative claim against Opus 5.5 and a speed claim against 5.1. Those are different kinds of evidence. A team refreshing both vendors in the same week should not put them in the same column of a spreadsheet. One column can hold a price. The other, on the evidence cited here, cannot.

What to put on the evaluation sheet this week

A practical read of the November 9 pages looks like a form, not a winner’s paragraph.

Record muse-ember-1.0 as the API id, not “Muse Ember” as a nickname that might later point at a second checkpoint. Record two price cards, not one: $0.10 input, $0.004 cached input, and $0.50 output up to 200,000 tokens; $0.30 input, $0.012 cached input, and $1.50 output above that line. Record the 1 million token input window and the 512,000 token output cap as limits, not as a recommendation to fill them. A limit is not a default. Record that the API surface named on the page is the Responses API, on Muse Code and the Meta Model API, with availability also stated for Google Cloud and Oracle Cloud.

Split the score sheet into Artificial Analysis rows and Meta-internal rows. On the external side, write down the index tie at 36 with Haiku, the FrontierCode result of 27.2 against Haiku’s 34.9 and Luna’s 25.2, the AutomationBench pass@1 of 37.8 against 13.9 and 20.2, the GDP.pdf tie at 22.8 with Luna, and the Coding Agent Index of 46 against 37 and 31, with the harness names attached. On the internal side, write down Agents’ Last Exam at 61.6, PSI at 46.8, OSWorld partial 69.5 and binary 33.8, and PerceptionBench with tools at 80.6. Mark the harness note on Terminal-Bench before copying 40.9 into a slide. Do not average those columns.

If the workload is a subagent that repeats tool calls on a stable prefix, the cache rate and the $0.14 task-cost snapshot are the relevant Meta claims, and they should be checked against a week of your own traces at the effort setting you will actually pay for. The max table is not that setting unless you select max. If the workload is a single dump of a large repository past 200,000 tokens, start from the long-prompt card and from the FrontierCode row, where the cheaper model did not lead. If the workload is computer use, quote both OSWorld numbers, 69.5 and 33.8, or quote neither. If the workload is clause-level document review, the Box quote names a task shape and does not name a pass rate. Keep it in the partner column.

The blog’s closing hope, personal superintelligence at a price that scales, is a goal statement. The checkable object is smaller and more useful: an id, two price cards, a date, a chart caption that says “estimates,” and a footnote that names the harness. That is what November 9 actually put on the page.