Benchmark calibration update, 2026-10-26: AGI Ranker v3 re-scores every model on six tests from four independent evaluators, with no estimates. Every score and rank changed. See what changed
AGI RANKER ← Back to the leaderboard

AGI Score Methodology

Every test, weight and rule behind the AGI Score, publicly documented. The same rules run on the leaderboard, where your browser recomputes every figure before showing it. Data: v3/board.json and models.json (CC BY 4.0).

How the score is built

1
Six tests, four independent evaluators
The AGI Score is built from six tests in five parts. Each test has one evaluator, named below, and a result counts only from that evaluator. We do not run tests ourselves, and we do not mix evaluators within a test.
Part Test Evaluator Share of the AGI Score
Agency 35%Terminal-Bench 4.0 (Mini-SWE-agent harness)Vals21.9%
LiveBench Agentic CodingLiveBench13.1%
Reasoning 29%ARC-AGI-2 (Semi-Private set)ARC Prize20.7%
LiveBench global averageLiveBench8.3%
Knowledge 15%Humanity’s Last Exam (2,158 text-only questions)Artificial Analysis15.0%
Visual 11%MMMU-Pro (ten-option questions, pass@1)Artificial Analysis11.0%
Language 10%LiveBench global averageLiveBench10.0%
Knowledge and Visual rest on one test each (Humanity’s Last Exam and MMMU-Pro). One test is a narrower measurement than a part deserves, and we would rather say so than hide it; adding a second takes a signed methodology change and a calibration release. LiveBench’s global average appears in two parts: it is two sevenths of Reasoning and all of Language, 18.3% of the AGI Score in total. Evaluator shares: LiveBench 31.4%, Artificial Analysis 26.0%, Vals 21.9%, ARC Prize 20.7%, so no evaluator carries a third of the score. LiveBench figures come from its release of 2026-06-25.
2
The scale: 0 to 100
Each test scores from 0 to 100: one hundred times the result the evaluator publishes. Each part is the weighted mean of its tests, and the AGI Score is the weighted sum of the parts. Nothing else enters: no curve, no adjustment for how crowded a test is at the top, no pull toward the middle. A part, a tab and a custom weighting are shown on a 0 to 10 scale, one digit and two decimals (the same measurement divided by ten), so the AGI Score is the only figure shown with two digits and none can be mistaken for it.
AGI Score = Σ part weight × Σ test weight × (100 × published result)
part weights 35 / 29 / 15 / 11 / 10; within Agency 5/8 and 3/8, within Reasoning 5/7 and 2/7
100 = AGI is the line the AGI Score measures distance to: a perfect score on all six tests. No human has been measured on these tests under the same conditions, so 100 is a target set by our definition of AGI, not a measured human level. A score cannot exceed 100. Our definition, in full: “AGI is an artificial intelligence that surpasses the best human on every purely brain-based intellectual task with no involvement of a physical body.”
3
What counts as a result

Read directly from the evaluator. A result counts only as the evaluator publishes it, for this exact model, on this exact version of the test. LiveBench publishes its two figures as components, so we apply LiveBench’s own formula to them (the global average is the mean of its seven category means; Agentic Coding is the mean of its JavaScript, TypeScript and Python tasks), and only when every component is published.

Never counted: a value converted from another evaluator, adjusted, estimated, or copied from another model or another test; a figure relayed by a third-party site; and a lab’s own report of its model. Lab announcements tell us where to look, never what to score.

One setting per model. Effort settings are not separate models. For each evaluator we take the setting the provider names as the model’s own, or else the highest effort setting the evaluator lists, never the one that scores best. If that setting has no result, the test is missing: a lower setting never stands in. A row that does not say which setting it ran does not count.

The model alone answered. Some providers offer a refusal fallback: when the model declines a request, another of the provider’s models can answer in its place. A result counts for the model alone when the evaluator states that the fallback was off (for that result, or in a standing statement of how it runs every model), when the evaluator marks every run that used it and this run carries no mark, when it shows the fallback never activated, or when it publishes a recount that scores every task the fallback helped with as a failure.

With refusal fallback. When some of a model’s results come from runs with its provider’s fallback on, or from runs that do not say, and nothing else sets them aside, the model is scored as “model with refusal fallback” on its results as published. That label goes wherever the model is named, and each of its results says how it was served. It comes off in the release after every one of the six tests has a result from the model alone. A fallback to another company’s model never counts.

Still published. A result counts while the evaluator still publishes it. When an evaluator revises a value, the revision enters in an evidence release, never silently.

4
One board: ranked, at least, early results
Every model on our roster is on the same board, in one of four states.
RankedAll six tests measured. An AGI Score and a rank.
At leastOne or two tests missing. “At least X”, no rank, and each missing test named with the reason.
Early resultsThree or more tests missing. The results it has, with no score and no position.
HeldA recorded ruling holds the model. The reason, and no figure.

What “at least” means. At least X is the AGI Score the model would have even with 0% on every missing test. It is a fact about the evidence, not an estimate of the model. It is never called an AGI Score and never carries a rank. The one comparison it supports: a model at “at least X” is certainly ahead of every ranked model listed below it. It says nothing about the models above it. We publish no ceiling, range or “could reach” figure, because each of those would assume a value for a test nobody has published. With three or more tests missing, a minimum says too little to place a model honestly, so it shows as early results.

Ranks count fully measured models only. A rank is a position among the models measured on all six tests.

Why it works this way. Our earlier method scored a model with a gap on the tests it had. That is the same as filling each gap with the model’s own average elsewhere, so a model could rise by being measured less. Now a missing result can only hold a model back, and each missing test is named with the evaluator that would complete it, for example “Terminal-Bench 4.0: not yet tested by Vals”.

Holds. A model is held only by a recorded ruling, with its reason, who ruled and when. A held model shows the reason and no figure.

5
The tabs

Agency, Reasoning, Knowledge and Visual each show one part of the AGI Score on its own, from that part’s tests, under the same rules: a rank needs every test in the part, and “at least” counts a missing test as 0%. They are not the AGI Score.

Custom weights, set with the presets and sliders in the Explorer on the main page, let you choose the five part weights yourself; the leaderboard then shows them under a Custom tab. They use the same results and the same rule for missing tests, so nothing is estimated, but they are yours alone: a custom board is shown on 0 to 10, it is not the AGI Score, and it changes no official rank.

Agents (planned for v3.1) will rank models on AutomationBench, from Zapier, and Terminal-Bench Science, from Vals, at equal weight, with a rank only when both are measured. The Agents tab is outside the AGI Score and never changes it.

6
Checks before anything is published

No derived values. Before every release, a check rebuilds the board from the published data and refuses to publish if any figure rests on a converted, estimated or filled value, if a score is missing a test, or if an “at least” figure carries a rank. Every changelog entry states the count it found: “Derived values scored: 0”.

Recomputed in your browser. The page recomputes every figure from the published board data before showing it. If it cannot reproduce them exactly, it shows no figures at all.

Coverage review. Ninety days after v3.0, and every ninety days after that, we check each test against the models released at least sixty days earlier. Any test missing for more than a third of them gets a written review within thirty days. Keeping the test is a valid outcome; replacing it takes a signed methodology change and a calibration release, never an automatic switch.

Rules we hold ourselves to

Value view: how value for money is derived
The value view pairs each model’s score for the selected area (Overall is the AGI Score; Coding, Reasoning and Knowledge are the same figures as those tabs) with an estimated API cost, so capability can be weighed against price. Only models measured on every test in that area are shown: an “at least” figure is a floor, not a score to set against a price.
Estimated cost is a blended price per 1M tokens across four token classes (new context, cache writes, cache reads and output) at a typical mix for that workload, using each lab’s published list prices. The coding mix is measured from real agentic coding sessions across three vendors: about 97.6% of tokens are context read back out of cache and only 0.24% are output, which is why the cached-input rate dominates a coding bill. How broad that measurement is, precisely. It covers three vendors and three coding agents, but weighted by tokens the sample is about 87% a single agent, so read it as one workload measured carefully rather than an average across the field. Measured per agent, the share of new context ranges from about 1.8% to 7.1%: the agents differ more than the vendors do. We apply one mix to every model on purpose: every Coding test runs every model under one fixed harness, and a per-vendor mix would price each model against a different workload. The other workloads are stated assumptions, not measurements. Where a lab publishes no cached-input rate we leave the model out of a cached workload rather than estimate one. Some providers also bill cache storage by the hour; because a blended per-token price has no time dimension, a model charging hourly storage for the caching mode we price is left out too, rather than have us invent how long a cache is held. No model is currently affected: every provider we verified charges nothing to hold a cache in the mode we price. Prices are the public rate you would actually pay today at the base context band. That includes published limited-time promotions, which are labelled on the card with the date they end. We absorb a promotion only when the provider publishes both the discounted rate and the period: a discount visible on one account but not quotable, or one with no stated end, stays at list and the reason is recorded against the model. Volume, subscription, batch and data-sharing tiers are still excluded. One thing the base band does not settle is how long a cache is kept: some providers charge more to hold a cache for an hour than for five minutes. That is a property of the workload rather than of the model, so we take the tier the workload actually needs: for coding, measured, that is the one-hour tier, because an agentic session holds its context far longer than five minutes and a five-minute cache would simply expire and be rewritten. For the workloads whose retention we have not measured we keep the base tier rather than guess one. Long-context surcharges, applied only where we could measure them. Most providers charge roughly double once a single prompt crosses a threshold (200K tokens at xAI and Google, 272K at OpenAI, 512K at MiniMax; Claude Haiku 5.5 charges five times as much over 100K), and the whole request is repriced when it does. What that costs depends on how often a workload crosses the line, which is a property of the coding agent, not of the model, so it has to be measured per vendor. We have measured it for Grok 4.5 (38.4%) and Grok 4.6 (44.6%) from real billing records, and their coding costs here include that uplift. Grok 4.3, Grok 4.7, MiniMax M3, Gemini 3.1 Pro, Claude Haiku 5.5 and the OpenAI models also have a surcharge and are priced without one, because we have no usage of them to measure and will not invent a figure: their true coding cost is higher than shown by an unknown amount. Anthropic’s other models, the Gemini Flash models and ChatGPT 5.5 Pro have no surcharge at all, which we verified rather than assumed. It is an estimate of typical cost, not a measured per-task bill.
Value for money is the extra capability a model delivers over the weakest option shown, per estimated dollar: (score − lowest score in view) / cost. We subtract that floor on purpose: a score has no true zero, so raw score per dollar would over-reward the cheapest model no matter how capable it is. Subtracting the floor measures the extra capability you actually buy.
Each area surfaces three picks: Top (highest capability), Budget (cheapest to run), and Best value (the most extra capability per dollar). The ranking shows the picks rather than a raw value number, which is ambiguous to read in isolation.
Two update clocks: evidence and calibration
This board separates updating the models being measured from changing the measuring instrument. Evidence releases are frequent: they may move only the models that received new results, and every change traces to a named result. Calibration releases are scheduled, labelled “Benchmark calibration update” with their own date, and are the only releases that may change the tests, their weights or the scale, which can move every model at once. The check described above refuses a change to the tests in any other release. v3.0 is a calibration release.
Why: changing the instrument is sometimes the right call, for example when a test stops taking new models, but arriving unannounced inside a routine data update it reads as instability rather than method. Announced and labelled, it reads as what it is: a deliberate recalibration, explained in the changelog with before and after.
Active-roster governance
Current rule (from v3.0): a model joins the board when its evidence passes our admission check, and every model that passes is listed. To pass, a model needs a confirmed identity and at least two of the six tests measured under the rules above, from at least two different evaluators (LiveBench’s two tests count as one evaluator). There is no limit per lab, no family quota and no score or rank cutoff: a model’s score never decides whether it is listed. Effort settings never create separate rows. Passing the check makes a model eligible; adding it is a deliberate, recorded decision, and once listed it takes whichever of the four board states its evidence supports.
Models already on the board when this rule was adopted stay listed even where they would not pass it today, because admission governs entry, not removal. A model leaves the board only when its maker withdraws it or it can no longer be scored. Adding or removing a model is always a deliberate, recorded decision. The earlier rules are documented in the version history and in the archived v2 methodology.

What changed and when: the version history. The methodology before v3.0: the archived v2 methodology.