Best AI Coding Models in November 2026: 12 Compared

AI
Guide
Coding models
AI benchmarks
API pricing

Written by: Bhargav Tibadiya
Published: November 12, 2026
Reading time: 24 min read

Original visualization of the published data and weighted-profile winners. Not a new benchmark or measured task-cost test.

There is no single best AI coding model without a definition of best. A model that writes the strongest patch may be too expensive for a background job. The cheapest response can become expensive after retries. A million-token context window can be useful without proving that the model reliably understands a million tokens.

For November 2026, I compared twelve distinct models using the same independent benchmark snapshot, checked their API prices against vendor documentation, and built an explicitly opinionated value score. Claude Sonnet 5.5 comes first in the balanced version. Claude Fable 5.2 comes first when coding quality receives most of the weight. Claude Haiku 5.5 comes first when price receives much more.

Those are three answers to three different questions, not an attempt to crown three universal winners. The interesting part is how the answer changes. Sonnet's balanced score is 51.4 out of 100. That does not mean it solves 51.4% of coding tasks, and a model scoring 50 is not half as useful as a perfect model.

This is a coding-model comparison, not another comparison of Claude Code, Codex, Cursor or other coding-agent products. For that separate workflow question, see the Cursor versus Claude Code game-development guide. I did not run these twelve models against a private test repository. The benchmark results come from Artificial Analysis; the price scenarios, charts, formula and interpretation are my own weighted analysis. The data snapshot was collected on November 11, 2026, for this November 12 article. All twelve models' score-bearing comparison fields were rechecked on November 12 before publication and were unchanged.

The short answer, before the formula

If I needed one model to trial as a general coding API default from this set, I would start with Sonnet 5.5 and GPT-6.1 Sol, then bring in Opus 5.5 or Fable 5.2 for work where a harder problem justifies a higher bill. That is a proposed evaluation order, not a claim that these models were tested on my projects.

For high-volume, low-risk work, Haiku 5.5 and Muse Ember deserve separate trials. Their short-context rates are dramatically lower, but their independent coding results are also lower. The correct acceptance test matters more than a pleasingly small token invoice.

For terminal-heavy work, Kimi K3.1 Pro deserves attention even though it does not lead our composite. Its Terminal-Bench result is strong while its repository-oriented FrontierCode result is much weaker. An average can hide a useful specialization.

The close balanced scores near the top should not be read as a precise scientific ordering. This article does not have confidence intervals for the composite or evidence that a one-point gap predicts a meaningful difference in your repository.

What counts as a model in this comparison

A model is the inference system you call through an API. An agent product wraps that system with prompts, tools, permissions, memory, repository handling and an interface. Changing the wrapper can change the outcome without changing the underlying model.

I include one configuration per named model rather than filling the table with several effort levels from one family. Most rows use max reasoning effort. Gemini 4 Carbon uses High; Grok 4.7 uses Xhigh. The Claude flagship rows preserve Artificial Analysis's Default Fallback designation. Kimi's source row has no effort suffix; its official API documentation says max is the default. Treat that as a documented default, not a recovered per-run configuration log.

This selection covers twelve distinct model names. It is not every model available in November, and it is not twelve equally accessible products. Preview status, regional availability, account approval, data rules and provider capacity remain separate gates. A model that cannot be used under your organization's rules is not a candidate, regardless of its rank here.

DeepSeek V4.1 Flash was investigated but excluded from the composite because the matching snapshot lacked the complete intelligence and FrontierCode values needed by this formula. Missing evidence is not a score of zero. It is a reason not to assign a comparable rank.

What the intelligence number means

Artificial Analysis's Intelligence Index v5.0.1 spans knowledge work, coding, science and general capabilities. Those four categories each receive 25% of the index. Coding itself includes FrontierCode-AA 2.0 at 15% of the overall index and Terminal-Bench 4.0 at 10%^[1].

The index is useful as a broad capability signal, but it is not a pure programming score. It is also not independent of the coding evidence used below. Our formula deliberately gives coding extra weight and then adds the broad index. That repeats some coding information. I disclose that overlap rather than pretending the broad number is a separate, clean measurement of everything except coding.

I do not subtract raw benchmark percentages from the index to invent a non-coding score. Its normalization means that arithmetic would not be justified by the published weights alone. The safer approach is to keep the source index intact, label the overlap and test whether changing the formula weights changes the recommendation.

Two coding benchmarks, not one interchangeable percentage

FrontierCode-AA 2.0 uses 132 private, real-repository tasks, with three runs per task. Artificial Analysis describes a common Stirrup agent harness, a 500-turn cap and a judge-based rubric with blocking checks^[2]. That is useful for comparing model configurations under controlled conditions. It does not show how the same model performs inside every commercial agent.

Terminal-Bench 4.0 contributes a different view of terminal work. In this article I use only the matching Artificial Analysis 4.0 results, not a vendor's self-reported number from another harness or a newer leaderboard version. The name and version are part of the measurement.

Neither score should be interpreted as a general probability that a model will fix an arbitrary production bug. Task selection, available tools, scoring rules, reasoning effort and execution limits all shape the result. FrontierCode's rubric percentage is not interchangeable with a binary pass rate on an unrelated benchmark.

The coding evidence blend used here is 60% FrontierCode and 40% Terminal-Bench. That mirrors the relative 15:10 emphasis inside AA's coding category, but this blend is our arithmetic over published percentages. It is not an official Artificial Analysis coding index.

The raw capability table

The following is the evidence before prices or our value score. Intelligence is the published index; the last two columns are benchmark percentages. Settings are preserved because a model name without its effort level can be a misleading comparison.

Model and setting	Intelligence	FrontierCode 2.0	Terminal-Bench 4.0
Claude Fable 5.2 (Max, Default Fallback)^[3]	65	48.8%	59.6%
GPT-6.1 Sol (Max)^[3]	55	40.6%	56.1%
Gemini 4 Carbon (High)^[4]	60	40.6%	65.2%
Claude Opus 5.5 (Max, Default Fallback)^[5]	59	46.4%	59.6%
GPT-6 Astra (Max)^[5]	57	42.4%	59.1%
Claude Sonnet 5.5 (Max, Default Fallback)^[6]	55	41.7%	63.6%
Kimi K3.1 Pro^[7]	46	25.5%	67.2%
GLM-5.3 (Max)^[7]	32	21.6%	41.9%
Muse Wonder (Max)^[8]	44	27.9%	52.0%
Muse Ember (Max)^[9]	36	27.2%	40.9%
Claude Haiku 5.5 (Max)^[9]	36	34.9%	32.8%
Grok 4.7 (Xhigh)^[10]	35	28.7%	25.8%

Fable has the highest broad index in this selection and the strongest FrontierCode result among these chosen configurations. Kimi has the highest Terminal-Bench result in the table. Those statements can both be true because the tests ask different questions.

One selection detail matters: this is not an optimization over every effort setting. Artificial Analysis also reports a Fable High result slightly above Fable Max on FrontierCode. I chose a declared configuration per model, not whichever setting happens to win each individual column. Mixing a model's best score from one setting with its cheapest behavior from another would create a model configuration nobody actually measured.

API prices, not subscription prices

All prices below are USD per million tokens, before tax, for direct API usage under the stated tier. The LLM cost optimization guide explains separate ways to reduce the bill after choosing a model. They are not monthly Claude, ChatGPT, Kimi or Muse Code subscription prices. An included model in a subscription does not make the API free, and an API rate does not tell you how many agent tasks a subscription allows.

Anthropic's current pricing confirms Fable at $8/$40 input/output, Opus at $4/$20 and Sonnet at $2/$10. Haiku is $0.10/$0.50 only through 100,000 input tokens, then $0.50/$2.50 above that threshold^[11]. OpenAI lists Sol at $2/$10 and Astra at $10/$50, both with 1,050,000-token API context windows^[12]^[13].

Google's global standard Carbon rates are $4/$20. Its November promotion is presented as 50% credits back on qualifying net spend through November 30, not a permanent replacement of the gross rate. Non-global rates differ^[14]. Kimi lists K3.1 Pro at $2/$10, plus separate cache-write charges^[15]. Z.ai lists GLM-5.3 at $1.40/$4.40^[16].

Meta lists Wonder at $4/$20 and Ember at $0.10/$0.50 up to 200,000 input tokens, then $0.30/$1.50 above that threshold. Those are Standard-mode API rates, not an assumed Contributor-mode discount^[17]. Grok 4.7 lists $2/$6 at its base tier and warns that requests exceeding 200k context have different rates^[18].

Model	Input / 1M	Output / 1M	Scenario cost
Claude Sonnet 5.5^[11]	$2	$10	$0.0600
Claude Opus 5.5^[11]	$4	$20	$0.1200
Claude Haiku 5.5^[11]	$0.1	$0.5	$0.0030
Gemini 4 Carbon^[14]	$4	$20	$0.1200
Claude Fable 5.2^[11]	$8	$40	$0.2400
GPT-6.1 Sol^[12]	$2	$10	$0.0600
Muse Ember^[17]	$0.1	$0.5	$0.0030
Kimi K3.1 Pro^[15]	$2	$10	$0.0600
GPT-6 Astra^[13]	$10	$50	$0.3000
Muse Wonder^[17]	$4	$20	$0.1200
GLM-5.3^[16]	$1.4	$4.4	$0.0368
Grok 4.7^[18]	$2	$6	$0.0520

Scenario cost means 20,000 uncached input tokens plus 2,000 billable output tokens in one request. It excludes tools, cache writes, retries, discounts and taxes. It assumes the billable-output count is known; a visible 2,000-token answer can consume additional reasoning tokens. This is a common-volume price illustration, not a measured cost to complete a coding task.

Context windows: capacity, not comprehension

The source comparison pages round most of these models to 1M context; Grok is 500k. Vendor documentation is more specific for some models: Sol and Astra list 1,050,000; Kimi lists 1,048,576; Carbon lists a unified 1,048,576-token input-and-output limit^[12]^[13]^[15]^[19]. Wonder documents 1,048,576, while the Claude overview and Ember model information also put these models in the million-token class^[20]^[21]^[22].

For scoring, I use a conservative common capacity of 1,000,000 for the million-token class and 500,000 for Grok. That avoids rewarding tiny differences in whether a provider rounds or counts in binary. The raw source descriptions remain available in the downloadable dataset.

Context is a budget shared with system instructions, repository text, tool results and, depending on the API, output or reasoning. You cannot assume that a nominal one-million-token window can hold one million tokens of repository content plus an unrestricted answer. Carbon's explicitly unified budget makes that especially clear.

More importantly, a capacity limit is not a measured long-context retrieval score. This ranking gives context only 5% because we do not have a matching, independent long-context coding evaluation for all twelve configurations. Eleven models tie on the capped context contribution. That is an honest low-information result, not a reason to manufacture differentiation.

The balanced value score: every weight and anchor

The score has four parts. All transformations use fixed anchors, not the best and worst models in this selected list. Adding a thirteenth model therefore does not automatically change the other twelve scores.

Coding evidence, C: 0.60 times FrontierCode percentage plus 0.40 times Terminal-Bench percentage.
Broad intelligence, I: the published Intelligence Index, kept on its original numeric scale. A point is treated as a point for this weighted calculation, not as a proven unit of usefulness.
Price utility, P: 100 times log10(1 / R) divided by 3, clipped to 0 through 100. R is the illustrative request cost in dollars.
Context utility, W: 100 times log2(K / 32,000) divided by 5, clipped to 0 through 100. K is the conservative context capacity in tokens.

Balanced score = 0.50C + 0.20I + 0.25P + 0.05W.

The price anchors make a $1 scenario request worth zero price points and a $0.001 request worth 100. A tenfold price reduction adds the same number of price points wherever it occurs before clipping. That is a deliberate diminishing-returns treatment, rather than letting the cheapest model win simply because it is many times cheaper.

The context anchors give zero at 32k and full credit at 1.024M, with logarithmic steps between. The 1M conservative bucket lands just below full credit. Neither anchor is a scientific threshold. They are my stated assumptions that a reader can replace.

The broad index is not stretched until this small group fills a 0-100 range. Doing that would imply a relative precision the evidence does not support and would make scores depend on which other models I chose to include. The resulting composite uses the available scales directly, which is also a choice. Read it as a preference model, not a new intelligence test.

Worked example: reproduce Sonnet's score

Sonnet's coding blend is 0.60 times 41.7 plus 0.40 times 63.6, or 50.46. Its broad index is 55. The common-volume request costs 0.020 times $2 plus 0.002 times $10, or $0.06.

The price transform returns approximately 40.73. The context transform for one million tokens returns approximately 99.32. Substituting those values gives 0.50 times 50.46, plus 0.20 times 55, plus 0.25 times 40.73, plus 0.05 times 99.32. The total is 51.38, displayed as 51.4.

Every row is calculated before rounding, and ranks are assigned on those unrounded totals. Two rows displaying 49.5 can therefore have different positions. I would not make a procurement decision on that hidden decimal. The unrounded value exists for reproducibility, not to imply that the difference is meaningful.

Bar chart of the balanced value score for twelve coding models. — Our balanced ranking. Values are a weighted composite, not task success rates. The table below exposes every component.

The balanced ranking, with its components

Rank / model	C coding	I broad	P price	W context	Score
1. Claude Sonnet 5.5	50.46	55	40.73	99.32	51.38
2. Claude Opus 5.5	51.68	59	30.69	99.32	50.28
3. Claude Haiku 5.5	34.06	36	84.10	99.32	50.22
4. Gemini 4 Carbon	50.44	60	30.69	99.32	49.86
5. Claude Fable 5.2	53.12	65	20.66	99.32	49.69
6. GPT-6.1 Sol	46.80	55	40.73	99.32	49.55
7. Muse Ember	32.68	36	84.10	99.32	49.53
8. Kimi K3.1 Pro	42.18	46	40.73	99.32	45.44
9. GPT-6 Astra	49.08	57	17.43	99.32	45.26
10. Muse Wonder	37.54	44	30.69	99.32	40.21
11. GLM-5.3	29.72	32	47.81	99.32	38.18
12. Grok 4.7	27.54	35	42.80	79.32	35.44

Sonnet leads because it combines a strong coding blend with a relatively low standard rate. Opus has a slightly stronger coding blend and a higher broad index, but its fixed-volume request costs twice as much. The 25% price weight is enough to reverse their order.

Haiku's high balanced position needs care. It is third here because the formula gives meaningful credit to a very low short-context price. Its coding blend is much lower than the leading models. A third-place composite does not make it the third-best model at coding. If your job has a hard correctness floor, apply that floor before considering the composite.

Carbon and Fable are close behind, but for different reasons. Carbon combines a strong terminal result with a weaker FrontierCode result. Fable leads the broad index and chosen FrontierCode configuration but pays a substantial price penalty. Sol and Ember nearly tie after rounding while representing very different capability-price tradeoffs.

These are examples of why a single sorted list needs the component table beside it. Otherwise the reader can mistake a low price for high capability or a high general index for strong repository performance.

Each model plotted by coding evidence on the horizontal axis and illustrative request cost on the vertical axis. — Coding evidence versus fixed-volume request cost. Numbers identify the twelve models; outlined circles and line identify non-dominated choices in this selected set.

Read the cost-versus-metric plots

Move right for a higher metric and down for lower cost. The outlined circles identify actual models on the cost-metric frontier, not an empty ideal region. They are not validated pass/fail thresholds or a promise of task success. The connected line is the non-dominated frontier among only these twelve configurations: no other plotted model is at least as strong on that metric and no more expensive, with one strict improvement. A frontier point is not automatically the best model for a particular repository.

The cost axis is logarithmic and increases upward. Each point uses the same illustrative 20,000 uncached input and 2,000 billable output token request. It excludes retries, tools, cache writes and tax. Cost is not an independent variable in the value plot: price already contributes 25% to the balanced score. That view helps inspect our weighting choices; it is not independent validation of it. Tap or click any chart to open the full landscape image, then zoom or rotate it.

Each model plotted by broad intelligence and illustrative request cost. — Intelligence versus fixed-volume request cost. Broad intelligence includes coding components, as disclosed in the methodology.

Each model plotted by balanced value score and illustrative request cost. — Balanced value versus request cost. Price is already a component of value; this is a dependent view of our formula, not a new benchmark.

Change the weights and the winner changes

I reran the same data under two alternate preference profiles. No model data changes; only the weights change. Quality-first uses 70% coding, 20% broad intelligence, 5% price and 5% context. Budget-first uses 30% coding, 20% broad intelligence, 45% price and 5% context.

Model	Quality-first rank	Balanced rank	Budget-first rank
Claude Sonnet 5.5	4	1	3
Claude Opus 5.5	2	2	5
Claude Haiku 5.5	9	3	1
Gemini 4 Carbon	3	4	6
Claude Fable 5.2	1	5	8
GPT-6.1 Sol	6	6	4
Muse Ember	10	7	2
Kimi K3.1 Pro	7	8	7
GPT-6 Astra	5	9	10
Muse Wonder	8	10	11
GLM-5.3	11	11	9
Grok 4.7	12	12	12

Fable moves from fifth in the balanced table to first in quality-first. Haiku moves from third to first in budget-first, but falls to ninth in quality-first. Ember is second in budget-first and tenth in quality-first. Sonnet stays near the top across all three profiles without winning every one.

This sensitivity is more useful than declaring the formula objective. A ranking that reverses when the price weight changes is telling you what your decision depends on. It is not necessarily broken; it is exposing a tradeoff. The mistake would be hiding the weights and calling the result the definitive model ranking.

The composite's coding overlap with the broad index remains in every profile. These alternate weights are not a statistical correction for that overlap. They are an explicit test of whether different buying priorities lead to different shortlists.

Rank paths for quality-first, balanced and budget-first scoring profiles. — Sensitivity analysis over identical raw data. Fable wins quality-first, Sonnet balanced and Haiku budget-first.

Price per token is not cost per finished task

The fixed-volume scenario makes rates comparable, but models do not necessarily use the same number of tokens to finish a job. Reasoning, retries, failed tool calls, repeated context and long outputs can change the bill. Cache writes and reads can change it again.

The Artificial Analysis comparison pages also report cost-per-task and output-use fields. Those are useful separate observations under that source's workload. I retain them in the raw data rather than silently treating our $0.06 scenario as the measured cost of solving a repository task. A real coding task can contain many API requests.

A practical team should record at least total billed cost, elapsed time, reviewer time, whether the patch met prewritten acceptance criteria, and whether it introduced regressions. Cost per accepted patch is a useful operational metric only when accepted means the same thing across candidates.

Do not assume retries are independent and then calculate a neat cost-per-success ratio from a benchmark percentage. A model may repeat the same failure. A human may need to change the prompt, inspect a dependency or repair the environment. That work is part of the workflow, not free statistical magic.

The long-context price traps

Haiku's short-context rate is the most striking example. At 20k input and 2k output, the uncached scenario is $0.003. At 120k input and the same 2k output, its higher tier gives $0.065, not the $0.013 you would get by applying the short-context rate beyond its limit^[11].

Ember also changes tier. A request with 250k input and 2k output uses its $0.30/$1.50 rates, giving $0.078 before other charges. Applying its short tier would suggest $0.026, one third of that amount^[17]. These are arithmetic examples under documented rates, not observed production invoices.

For both, the million-token capacity claim can be true while the headline cheap rate stops applying much earlier. Grok's own page also flags different pricing above 200k, so its base-rate scenario must not be extrapolated to a 500k request^[18].

Caching can reverse another apparent advantage. A model with a higher ordinary-input rate may be competitive when a large stable prefix is repeatedly read from cache. But cache eligibility, expiry, write charges and repeated-prefix structure matter. Our base ranking deliberately excludes caching rather than guessing one universal hit rate.

Carbon's November promotion is a scenario, not the baseline

Carbon's official pricing page distinguishes global and non-global rates, standard and other service tiers, and temporary promotional economics. The November 50% credits-back offer can improve the effective cost for an eligible account. It is not the same as lowering the standard list input/output rates forever^[14].

If a team can actually use the full credit and its effective rates are $2/$10, the illustrative request falls from $0.12 to $0.06. Holding all other assumptions constant, Carbon gains about 2.51 balanced points and would lead this selected list. That is a conditional promotional scenario, not the baseline ranking.

This is exactly why dates belong next to price claims. The article is about November, but a team may keep a model in production into December. A decision based on a temporary credit should include what happens after the credit period, whether the credit is usable, and what region and service tier the team needs.

Google also describes Carbon as available to verified enterprise customers in selected regions^[19]. Availability can eliminate an otherwise attractive candidate before a score has any practical role.

Twelve configurations in plain language

Sonnet 5.5: the balanced starting point

Max with Default Fallback scores 41.7% on FrontierCode and 63.6% on Terminal-Bench, with broad intelligence 55. At $2/$10 per million input/output tokens and conservative 1M context, its balanced score is 51.4. It leads this formula because good coding evidence and relatively low rates work together, not because it wins every test.

Opus 5.5: a stronger quality-first candidate

Max with Default Fallback records 46.4% FrontierCode, 59.6% Terminal-Bench and intelligence 59. Standard rates are $4/$20, with conservative 1M context. Its 50.3 balanced score is second; its quality-first rank is also second. The trial question is whether the extra capability justifies twice Sonnet's fixed-volume price.

Haiku 5.5: inexpensive within the right boundary

Max records 34.9% FrontierCode, 32.8% Terminal-Bench and intelligence 36. Its $0.10/$0.50 short-context tier and conservative 1M capacity produce a 50.2 balanced score. The cheap tier ends at 100k input, however. Above that, rates are $0.50/$2.50. Its third-place value score does not erase its lower coding results.

Carbon: strong terminal evidence, conditional economics

High records 40.6% FrontierCode, 65.2% Terminal-Bench and intelligence 60. At global standard gross rates of $4/$20 and conservative 1M context, its balanced score is 49.9. Eligible November credits can change the economics. Enterprise access requirements, region and the unified input/output budget need checking before treating it as a default.

Fable 5.2: first when quality dominates

Max with Default Fallback records 48.8% FrontierCode, 59.6% Terminal-Bench and intelligence 65. At $8/$40 and conservative 1M context, it scores 49.7 balanced but wins quality-first. It is a reasonable candidate for hard tasks where a measured improvement matters more than a low common-volume request cost.

Sol: a low-rate flagship candidate

Max records 40.6% FrontierCode, 56.1% Terminal-Bench and intelligence 55. At $2/$10 with conservative 1M context, its balanced score rounds to 49.5. It shares Sonnet's standard rates, not necessarily its token use or behavior. Compare accepted patches and total bills under the same local harness.

Ember: budget strength without a quality claim

Max records 27.2% FrontierCode, 40.9% Terminal-Bench and intelligence 36. Its $0.10/$0.50 tier and conservative 1M capacity yield a 49.5 balanced score and second place in budget-first. Above 200k input the rates triple to $0.30/$1.50. Keep cheap routing behind checks appropriate to the task.

Kimi K3.1 Pro: a terminal-specific reason to test

The source row records 25.5% FrontierCode, 67.2% Terminal-Bench and intelligence 46; the vendor's default effort is max. Rates are $2/$10 with conservative 1M context. Its 45.4 balanced score hides the largest coding-column split in this table. A terminal-heavy workload may value it differently from a repository-change workload.

Astra: premium rates make the value test harder

Max records 42.4% FrontierCode, 59.1% Terminal-Bench and intelligence 57. Rates of $10/$50 with conservative 1M context yield a 45.3 balanced score. That is not a claim that Astra is worse at every coding job. It means this evidence and this price scenario demand a clear local benefit before paying the premium.

Wonder: compare the API model, not Full

Max records 27.9% FrontierCode, 52.0% Terminal-Bench and intelligence 44. At $4/$20 and conservative 1M context, its balanced score is 40.2. Meta distinguishes API Wonder from subscription-only Wonder Full. Raising API effort to max does not turn Wonder into Full, so evidence about one should not be casually attached to the other.

GLM-5.3: lower rates, lower measured evidence here

Max records 21.6% FrontierCode, 41.9% Terminal-Bench and intelligence 32. At $1.40/$4.40 and conservative 1M context, its balanced score is 38.2. Its lower input and output rates are real, but the two selected coding columns limit its position. A different deployment constraint could still justify a local trial.

Grok 4.7: base pricing is not full-window pricing

Xhigh records 28.7% FrontierCode, 25.8% Terminal-Bench and intelligence 35. At base rates of $2/$6 with 500k context, its balanced score is 35.4. The vendor flags higher-context pricing above 200k, so the base-rate example cannot be extended to the full window without another price check.

A shortlist by the job, not by brand

For an ordinary coding API trial, compare Sonnet and Sol on the same backlog slice. Their standard input/output rates are equal in this snapshot, so a local trial can focus on accepted patches, token use and review burden rather than a difference in headline rates. Do not assume equal rates mean equal total bills.

For difficult multi-file changes, include Fable and Opus. The independent evidence makes them reasonable quality-first candidates, but a team should decide in advance what improvement would justify the extra spend. A premium model that fails the same acceptance test does not earn credit for sounding more careful.

For terminal-focused workflows, include Kimi and Carbon if access permits. Kimi's 67.2 Terminal-Bench result stands out, while its 25.5 FrontierCode result warns against treating terminal strength as proof of broad repository strength. Carbon has a similar, less extreme split between these columns.

For bulk classification, bounded transformations or draft patches behind strong checks, trial Haiku and Ember. That does not mean sending them unreviewed production changes. Define which tasks are safe to route cheaply, which need escalation and which require a human from the start.

Wonder, GLM and Grok do not lead these particular composites. That is not evidence that they have no useful niche. Deployment constraints, language coverage, data handling, latency or an existing integration can matter more than a modest score difference. Those factors need their own evidence and are not secretly embedded in this formula.

A small evaluation that can overturn this ranking

Pick a set of representative tasks from your own repository before running candidates. Include a small bug fix, a multi-file change, a test repair and a task where the correct action is to ask a question rather than invent a requirement. Keep secrets and restricted code within approved services.

Write acceptance criteria and tests first. Pin the repository commit, model identifier, reasoning effort, agent harness, permissions, tools, time limit and maximum spend. Otherwise a candidate may win because it had a better environment or a larger budget rather than because the model was better for the job.

Record the whole run, including failed attempts and human intervention. Review the diff for unnecessary edits, dependency changes, weakened tests and behavior that passes a narrow test while violating the request. A patch is not acceptable merely because a model says it is done.

If the models are close, repeat tasks enough to see whether the ordering is stable. Report the distribution rather than a single favorable run. Use the same rules for retries and escalation. A useful result may be a routing policy with a cheap first attempt and a stronger fallback, not one permanent default for everything.

Three-stage proposed protocol: pin conditions, keep acceptance independent, count the whole job. — A proposed local trial protocol. This article did not perform these tests.

What this comparison leaves out

There is no direct score here for latency, security, data retention, compliance, regional routing, reliability or tool-use safety. The source pages include some speed information, but combining it with these coding tasks without a matching workload would create another misleading average.

The benchmark snapshot has sampling uncertainty, and the composite adds preference uncertainty. We lack source-provided confidence intervals suitable for propagating through this formula. Ranking twelve configurations to two decimal places is an accounting convenience, not evidence of two-decimal scientific accuracy.

The scoring also gives the broad index a direct numeric role and uses logarithmic utility for price and context. Different defensible transformations can change results. Fixed anchors avoid candidate-set normalization, but they do not make the chosen anchors inevitable. The downloadable calculation is intended to make disagreement easy.

Finally, API model aliases and vendor prices can change. Recheck the exact identifier, availability, current rates and terms before spending money or sending private repository content. This is a dated comparison, not an evergreen guarantee.

The decision I would take from the data

Use Sonnet as the balanced starting point in this selected snapshot, not as an unquestionable winner. Keep Fable and Opus in the quality-first trial. Put Haiku and Ember behind explicit acceptance checks for cost-sensitive work. Give Kimi a fair terminal-focused test rather than dismissing it because of an overall average.

The larger lesson is to separate capability, price and deployment fit before combining them. A transparent score is useful when it makes your assumptions visible and replaceable. It becomes harmful when it turns those assumptions into a claim of universal intelligence.

The raw data and calculation are linked below. Change the scenario, remove models you cannot use, set a minimum capability requirement and rerun the ranking. If the winner changes, you have learned something about the decision you actually need to make.

Download the data and reproduce the score

Download the model snapshot and computed scores. The JSON preserves exact source row names, benchmark percentages, vendor-rate scenario inputs, utility components, unrounded scores and alternate ranks. Download the calculation script to reproduce the weighted arithmetic without any API keys or model calls.

These downloads contain research data and arithmetic, not repository content or private test runs. The source dates and pricing caveats matter as much as the output. Do not strip them away when reusing a chart.

FAQ

Is this a hands-on coding benchmark?

No. It is original analysis of published independent benchmark results and vendor documentation. The formula and charts are original; the underlying model evaluations were performed by Artificial Analysis.

Is Sonnet 5.5 the best coding model overall?

It leads this article's balanced value score. Fable leads the quality-first profile, and Haiku leads budget-first. The right choice depends on your task, acceptance standard, access and actual cost.

Why does a cheap model rank above a stronger coding model?

The balanced score rewards price as well as capability. A high value rank is not the same as a high coding score. Apply a minimum capability requirement before using the value ranking if errors are costly.

Does one million tokens mean the whole repository will work perfectly?

No. It is a capacity limit, not a guarantee of comprehension or retrieval. Instructions, tool results and output may share that budget, and long-context pricing can differ from the short-context headline rate.

Are monthly coding subscriptions included?

No. The price table uses API token rates under a defined scenario. Subscription access, quotas, included usage and product-specific wrappers require a separate comparison.

Can I change the formula?

Yes. The data and calculation script expose the weights, transforms, scenario cost and context assumptions. Changing them is encouraged; the score is a weighted decision aid, not a scientific intelligence measure.