Kimi K3.1 Pro vs. GPT-6 Astra vs. GPT-6.1 Sol vs. Claude Fable 5.1 vs. Claude Opus 5.5

Benchmarks, specifications, API costs, speed, access, and the practical tradeoffs behind Moonshot's newest frontier model.

Research snapshot: October 23, 2026. This is a comparison of published evidence, not a five-model hands-on test. Provider claims, independent measurements, and our calculations are identified separately. All prices are in US dollars unless stated otherwise.

Kimi K3.1 Pro has a credible claim to frontier performance, especially for work that involves tools, files, and many consecutive actions. Its launch makes choosing a model more interesting than comparing the largest number on a leaderboard.

Among these five models, Claude Opus 5.5 leads Artificial Analysis' overall Intelligence Index. Kimi comes next, ahead of Claude Fable 5.1, GPT-6 Astra, and GPT-6.1 Sol. The ordering changes across individual tests. Kimi leads several agent-work measurements; the other models retain substantial advantages in parts of scientific reasoning and factual knowledge. Artificial Analysis leaderboard.

The hardest commercial comparison for Kimi is Sol 6.1. Both advertise $2 per million uncached input tokens and $10 per million output tokens. Yet Artificial Analysis' evaluated workload costs about $2.11 per task with Kimi and $0.72 with Sol. Token consumption and caching can outweigh identical headline prices. Kimi results, Sol results.

Our assessment is that K3.1 Pro belongs on the shortlist for demanding coding and knowledge-work agents. It needs a workload-specific reason to displace Sol as an economical default, and its stronger agent scores do not establish a general scientific-reasoning advantage over Astra or Opus.

This comparison concentrates on the five models named in the title. For the wider model field and deployment discussion, see our Kimi K3.1 Pro guide. For a closer look at repeated requests and cache duration, see our Kimi cost breakdown.

In this comparison

1. The five models at a glance
2. Independent benchmarks across all five models
3. What Moonshot's launch benchmarks add
4. Specifications and model controls
5. API pricing, including caching
6. Speed, latency, and paid acceleration
7. Availability and subscription access
8. Integration details that can change a result
9. The open-weight question remains conditional
10. Kimi against each rival
11. Which model should you test first?
12. Evidence that could change the verdict

The five models at a glance

This table uses Artificial Analysis Intelligence Index v4.3.2. OpenAI models are evaluated at max; the Claude entries are max with the evaluator's default fallback configuration. Kimi's entry is the reasoning model evaluated by Artificial Analysis. The cost column describes the index workload, not an arbitrary prompt or a completed client project.

Scroll sideways to see every column.

Sources: Artificial Analysis model pages for Kimi, Astra, Sol, Fable, and Opus. Provider rate details appear below.

The rounded scores hide small differences: Fable and Astra both display 53 without having identical underlying results. The index is a weighted summary. A three-point lead does not mean a model is three percent better at every task, and dividing an index score by dollars does not produce a reliable measure of business value.

The table also excludes models outside the requested five. It should not be read as a complete market ranking.

Independent benchmarks across all five models

Artificial Analysis provides a useful comparison because it publishes results across a common evaluation program. That improves consistency, but model settings, fallback behavior, token consumption, and the work environments still matter. These are results from configured model systems, not measurements of an abstract model detached from its tools.

Agent work, software engineering, and professional deliverables

Higher is better in every row. Elo ratings and percentages have different units and cannot be averaged directly.

Scroll sideways to see every column.

Sources: the five Artificial Analysis model pages linked above; evaluation definitions and implementation.

Kimi's results are particularly encouraging for agents that must complete sequences of useful actions. It leads these five entries on AutomationBench-AA and Terminal-Bench 4.0. Those tests are closer to an agent completing a workflow than to answering a single multiple-choice question.

The SciCode row supplies a useful counterweight. Scientific programming can reward different abilities from general terminal work. A model that handles repository navigation, command execution, and recovery well can still be less reliable when translating a scientific specification into correct code.

Professional deliverables show another split. Kimi is close to Opus on GDPval-AA, while Opus has a larger lead on AA-Briefcase. The GDPval-AA confidence intervals retained in the source snapshot overlap: Kimi spans 1,820–1,872 and Opus 1,840–1,892. That supports cautious language about their ordering on that test. It does not establish equivalence across the whole suite. GDPval-AA results in the Kimi record, Opus record.

A high Elo score also needs a reference population. It records relative performance under a judging procedure. It is not a percentage of professional jobs a model can replace.

Reasoning, documents, context, and factual knowledge

Scroll sideways to see every column.

Sources: Artificial Analysis records for Kimi, Astra, Sol, Fable, and Opus.

Kimi's factual-knowledge result is its clearest weakness in this comparison. Its lower hallucination rate coexists with lower accuracy. The hallucination metric divides incorrect answers by all non-correct responses: incorrect answers, partial answers, and questions not attempted. It is not the percentage of every answer that contains a false statement. A model can abstain more often and obtain a better hallucination figure while answering fewer questions correctly. AA-Omniscience definitions.

That distinction matters for research assistants. A system that refuses to guess can be useful, but users still need a way to retrieve missing facts and verify cited evidence. Conversely, a model with stronger closed-book accuracy can produce confident errors. The operating procedure matters alongside the model choice.

The document and long-context results support evaluating Kimi on large information-processing jobs. They do not show that it reliably reasons over every token in a million-token prompt. AA-LCR uses roughly 100,000-token inputs, while GDP.pdf uses its own document preparation and grading rules. Differences of a fraction of a point should not carry a purchasing decision by themselves. Document and long-context evaluation details.

The practical distinction is between capacity and effective use. A model may accept an entire archive but miss a conflicting clause, misread a table, or fail to connect two facts. Testing those failures directly is more informative than comparing advertised windows.

How much confidence to place in these rankings

Several details should travel with any screenshot of these tables. The index combines ten evaluations. Terminal-Bench 4.0 is run in mini-swe-agent, over 66 tasks with three repeats per task. AutomationBench-AA reports completion of objectives with guardrail violations affecting credit. SciCode is scored at the subproblem level. These measures answer different questions. Artificial Analysis implementation.

We retain the Claude fallback labels because removing them would change the description of the evaluated setup. We do not assume that a fallback means a second chance on every failed task, or that it has identical behavior across providers. The configuration needs to be reproduced when comparing results.

No statistical significance claim is made for the aggregate ranking. The small lead on one document test is weaker evidence than a consistent advantage across a set of tasks that resembles your own work. Results also age: a provider can change serving behavior, a benchmark can revise its grader, and an agent can improve while the underlying model name stays the same.

What Moonshot's launch benchmarks add

This vendor-published compilation mixes Kimi tests and external competitor results. Sol 6.1 is absent; a dash means missing evidence.

Scroll sideways to see every column.

Source: Moonshot release and footnotes. Settings: Kimi max; competitors max, with fallback. Kimi's terminal tests use Claude Code. Some competitor scores are published maxima from different setups. Keep this table separate from the independent results.

The results suggest a useful hypothesis for a buying test: Kimi's relative strength may be greatest in some extended software workflows, while advanced scientific work and complete-program reconstruction remain harder. That hypothesis needs replication on unseen tasks.

Sol deserves its own evidence rather than a value copied from the older GPT-6 Sol. OpenAI's Sol 6.1 launch reports gains on DeepSWE, AutomationBench, computer use, and scientific workflows. It uses OSWorld 2.0's offline set and an AutomationBench version that differ from some tests above. Those figures belong in their original evaluation contexts. OpenAI's Sol 6.1 announcement.

The differences are commercially important. A repository repair, a scientific investigation, and a full application reconstruction all involve code. Treating them as a single capability can hide the reason an expensive model succeeds where a cheaper one stalls.

Specifications and model controls

The names used here are the providers' actual model names: GPT-6 Astra, GPT-6.1 Sol, Claude Fable 5.1, and Claude Opus 5.5. Kimi K3.1 Pro Highspeed is an additional serving option discussed separately.

Scroll sideways to see every column.

Sources: Kimi API guide, Kimi model analysis, Astra specifications, Sol specifications, Fable specifications, Opus specifications.

The superficially similar context numbers are not a meaningful product differentiator by themselves. OpenAI separately specifies a 922,000-token maximum input, leaving capacity for output. Kimi's large configurable completion setting is a request control, not verified evidence of a million-token answer following a million-token prompt. Actual input, reasoning, and output accounting must fit the relevant endpoint's limits.

Opus 5.5 also documents a 300K-output beta on the batch endpoint. That is separate from its standard interactive output limit; the same exception was not verified for Fable 5.1. Opus model capabilities.

Reasoning settings also prevent a clean comparison between default experiences. Kimi starts at maximum effort in its documented API configuration, while Sol and Opus default to medium. A buyer comparing default settings may be comparing substantially different compute budgets. The word max itself does not guarantee equal compute across providers.

Images, video, files, and tools

All five evaluated model records support text and image input and text output. Kimi additionally documents video-file input in its API guide and in Kimi Code. The Artificial Analysis comparison used here identifies text and image support; its scores are not an independent video benchmark. Kimi vision examples, Kimi Code model configuration.

OpenAI lists audio and video as unsupported native modalities for Sol 6.1, while its tool-enabled API can call separate services, including image generation and code execution. Claude's model cards describe text-and-image input with text output. Native output and tool access are different capabilities. Sol model interface, Claude model overview.

A coding agent producing a 3D model, spreadsheet, or slide deck may generate code and invoke external programs to create the final file. Its success depends on those programs, available packages, permissions, and verification. A compelling finished artifact does not establish that the language model has a native 3D or video-generation decoder.

For an integration, the relevant questions are concrete: Can it read the file types you use? Can it call the required tools? Does it return valid structured data? Can the application recover after a timeout without duplicating work? Those questions often determine whether a benchmark advantage survives deployment.

API pricing, including caching

These are direct-provider standard rates per million tokens. They exclude tax, separately priced tools, storage, regional premiums, and third-party routing charges. OpenAI's base rates in this table apply up to the short-context threshold discussed next.

Scroll sideways to see every column.

Sources: Kimi inference pricing, OpenAI pricing, Anthropic pricing.

Kimi's base input and output prices are 80% below Astra and Fable and 50% below Opus. They match Sol. These are price ratios for the specified token categories; they do not establish equivalent savings per successful task.

Caching changes the comparison. Fable's cache reads are far cheaper relative to its own uncached input price than Astra's. Sol has the lowest cache-read price in this group. Kimi Highspeed preserves the standard model's cache-read rate, even though new input, output, and cache writes cost more.

Kimi's caching documentation also prevents a common billing error. Cache reads, cache writes, and the uncached remainder are separate input categories. A cache hit is not charged both a read and a fresh write. The initial write and later reuse should be modeled separately. Kimi context-caching rules.

Long context can change the price ordering

For Astra and Sol, prompts above 272,000 input tokens trigger higher rates for the full request: input and cache rates double, while output rates increase by 50%. Kimi documents flat rates across its supported context length. Anthropic includes the full 1M context at standard rates for Fable 5.1 and Opus 5.5. OpenAI pricing, Kimi API pricing FAQ, Anthropic long-context pricing.

Scroll sideways to see every column.

The threshold applies to the request's input length, not merely the small new message appended at the end of a long conversation. A long cached prefix still belongs in a workload estimate. Small prompts and large document jobs can therefore produce different value judgments even before model quality enters the calculation.

Three reproducible token-cost examples

The following figures are arithmetic examples using the published rates. They are not measured model runs. They assume exactly the same billed token counts across providers, standard processing, no tool fees, and no regional surcharge. Real tokenizers and reasoning lengths differ.

Scroll sideways to see every column.

Calculation: each token category is divided by one million and multiplied by its rate, then the category costs are added. A separate cache creation event would need its own write cost; the warm-cache example excludes that earlier event. The examples also exclude any automatically created cache writes charged at a different rate from ordinary uncached input.

The long-document example makes Kimi's pricing advantage over Sol more visible. Whether that advantage survives actual use depends on how much reasoning each model produces, how often it rereads material, how much context can be reused, and whether the output passes review.

What the measured workload costs reveal

Using the unrounded Artificial Analysis cost data, Kimi costs about 2.92 times Sol per index task. It costs approximately 35% less than Astra, 72% less than Fable, and 65% less than Opus in that workload. These are our calculations from evaluator data, not vendor savings promises. AA model comparison.

The same evidence shows why output length belongs in cost analysis. The retained evaluation records contain about 148 million output tokens for Kimi, 60 million for Astra, 67 million for Sol, 188 million for Fable, and 260 million for Opus. These totals include reasoning and answer generation; they are not the lengths of one response. AA token-use records.

Artificial Analysis' launch article quotes a Kimi task cost of $1.98, while the live model record captured for this comparison reports $2.11. This article consistently uses the latter snapshot. The discrepancy is retained as an evidence note; we have not established its cause. AA launch analysis, live Kimi record.

For a business, the relevant denominator is accepted work. A cheap attempt that repeatedly fails may cost more once retries and human repair are counted. A costly model that produces a longer answer without improving the result may also be poor value. The comparison needs accepted outputs, not a model's self-reported success.

Speed, latency, and paid acceleration

Artificial Analysis' captured first-party endpoint measurements give the following picture. These values are a time-stamped sample, not a service-level guarantee. Kimi's live throughput had already moved from an earlier 73.5-token/second observation to 77.1 during research, illustrating why a single speed number should not be treated as permanent.

Scroll sideways to see every column.

Sources: the Kimi, Astra, Sol, Fable, and Opus records captured October 23.

The first-chunk column is not a like-for-like measure of time to a useful answer. Kimi streams reasoning before its final answer. A provider that withholds reasoning can return its first chunk much later. The long waits shown for maximum-effort configurations must not be generalized to ordinary chat or lower-effort usage.

Artificial Analysis distinguishes first token, first answer token, output speed, and complete response time. Its Kimi answer-latency calculation in the captured record uses a 2,000-reasoning-token assumption and produces about 29 seconds to the first answer token. That is a modeled display value, not a directly timed 29-second promise. The evaluator's methodology describes that fallback assumption. Speed and latency methodology.

Within the displayed throughput measurements, Opus emits tokens fastest, followed by Kimi, Fable, Astra, and Sol. That ordering says little about the time needed to finish a repository change. A faster stream can still produce more reasoning, more tool calls, or more unsuccessful attempts.

For an interactive product, measure at least two times: the wait for the first useful answer and the wait for a verified result. Also record the slow tail, such as the 95th percentile. The median can look healthy while a minority of requests keep users waiting for several minutes.

Faster serving has its own price

Scroll sideways to see every column.

Sources: Kimi Code model notes, Kimi rates, OpenAI Fast, OpenAI Ultrafast, OpenAI rate card, Claude Fast mode.

Anthropic explicitly describes its Fast gain as output-throughput improvement, with no corresponding promise for time to first token. Availability also varies by platform. The dedicated Fast-mode documentation should take precedence over an assumption that every cloud deployment exposes the same switch.

These accelerated modes were not independently tested for this article. Multiplying the standard throughput table by an advertised speedup would create a fabricated measurement. Likewise, lower reasoning effort is a separate change: it may shorten the work the model performs, while a faster serving tier changes how that work is processed.

Batch processing can reduce cost when interactive latency does not matter. OpenAI documents Batch and Flex at 50% below standard prices; Anthropic documents a 50% batch discount for the models compared here. Batch and premium speed modes should be budgeted as separate operating choices. OpenAI pricing, Claude batch pricing.

Availability and subscription access

API availability, application access, and downloadable weights are separate questions. All five have documented hosted access. A subscription can expose a restricted context, a different default effort, or a shared usage allowance that changes the experience substantially.

Kimi documents K3.1 Pro access in Kimi Code on its new Plus and higher plans. Pro and higher unlock the 1M context and Highspeed option. Legacy plan names and entitlements remain documented separately. The public pages retrieved for this comparison did not expose a reliable localized subscription-price table, so no monthly Kimi price is invented here. Kimi model access, membership rules.

New Kimi membership plans remove the weekly quota window but retain a rolling five-hour window and a monthly total quota. Legacy plans retain their earlier weekly rules. Those details make an unqualified unlimited-use claim inappropriate. Kimi Code clients share the membership allowance, while the standalone developer API uses pay-as-you-go billing. Kimi membership documentation, API billing explanation.

OpenAI's Sol 6.1 announcement lists access in ChatGPT Work and Codex for Plus, Pro, Business, Enterprise, and Edu users, alongside the API. Astra has its own app eligibility and workspace controls. Access to one model in a coding interface should not be assumed to imply identical access in every chat interface. Sol 6.1 availability, Astra access guidance.

The current ChatGPT Pro tiers are $100, $200, and $500 per month. Ultrafast is included in Pro 500; it is not included in Pro 100 or Pro 200. API Ultrafast is separately documented as broadly available to API users, so the application subscription requirement must not be applied to the API. Pro 200's temporary grandfathered allowance is scheduled to change after October 29 for affected subscribers. OpenAI Pro plans, API Ultrafast availability.

Anthropic advertises Claude Pro at $20 monthly, or $200 billed annually, and Max starting at $100 monthly. Its comparison table lists Opus access on Pro and Max; Fable uses usage credits on Pro and has a stated share of weekly limits on Max. The pricing page also advertises API-credit benefits for Max, which have their own terms. A monthly subscription should therefore be compared as a bundle of access and allowances. Claude plans.

For organizational access, Anthropic lists Fable and Opus across its API and major cloud platforms. OpenAI documents direct API access and platform-specific routes. Region, organization verification, available capacity, and workspace permissions can still affect access. This article verifies documentation, not successful account entitlement in every country or cloud region. Claude model availability, Astra availability.

Integration details that can change a result

Kimi's API is documented with structured output and tool calling, but a familiar request format does not guarantee interchangeable behavior. Its guide fixes sampling parameters, keeps thinking enabled, and requires preserving the complete returned assistant message in subsequent turns. Image input uses base64 or uploaded-file references rather than arbitrary public image URLs. It also warns that its built-in web search is being updated and is not recommended for near-term production workflows. K3.1 Pro API guide.

Kimi Code uses k3.1-pro, while the public developer API uses kimi-k3.1-pro. The Code documentation warns that a mistyped model identifier can fall back to an older model without thinking. That makes checking the actual returned model part of a fair trial. A successful response alone does not prove the intended model ran. Kimi Code configuration.

OpenAI directs tool-using Sol 6.1 requests to the Responses API. Its model documentation separates tool support from native modalities and lists structured outputs, streaming, and function calling. Existing code using Chat Completions should not assume that tool behavior transfers unchanged. Sol API documentation.

Claude Fable 5.1 and Opus 5.5 keep adaptive thinking enabled. Their documentation identifies changes around forced tool use, thinking-block continuity, and progress text between tool calls. Opus also has a changed computer-use interface on specified platforms. Applications that discard reasoning state or expect older response shapes need migration work before a capability comparison is meaningful. Fable migration overview, Opus changes.

A practical trial should log the model identifier, endpoint, effort setting, service tier, request errors, retries, tool versions, and context strategy. When two systems differ in those details, retain the difference in the result. Quietly upgrading one system's tools or retry budget can make a comparison look like a model improvement.

The open-weight question remains conditional

Moonshot says K3.1 Pro's full weights will be released by November 4, 2026. At this research cutoff, the launch evidence describes a future release and the official Moonshot Hugging Face search did not return a K3.1 repository. The final release files and license were not verified. Kimi release commitment, Moonshot's model collection.

Artificial Analysis reports a 2.8-trillion-parameter mixture-of-experts model with 104 billion active parameters. The active count describes the portion used during a token's computation; it does not imply that only that portion of the weights must be stored. AA launch analysis.

For scale, an illustrative 4-bit encoding of 2.8 trillion parameters alone would occupy roughly 1.4 trillion bytes, or 1.4 TB in decimal units. That calculation excludes scales, metadata, buffers, caches, activations, replication, and serving overhead. It is not a verified K3.1 checkpoint size or a hardware recommendation.

Self-hosting economics depend on utilization, accelerator memory, interconnect, quantization quality, inference software, operations, and license terms. A team with suitable infrastructure and steady load may evaluate those costs differently from a small company serving sporadic requests. No defensible self-hosted cost-per-token or minimum GPU count can be established here from the parameter count alone.

The distinction matters for organizations that want control over data and deployment. A promised weight release is a reason to watch the model. It is insufficient evidence for an offline deployment plan, a commercial-license assurance, or a claim that sensitive workloads can already run privately on the final K3.1 weights.

Kimi against each rival

Kimi K3.1 Pro versus GPT-6 Astra

For a developer building a general work agent, Kimi deserves a direct trial against Astra. Its independent workflow results create a plausible case for completing useful tasks with a lower inference bill. That is especially interesting when the work involves substantial input and tool interaction.

Astra remains a serious candidate for difficult reasoning. The science results and knowledge measurements make a blanket substitution hard to justify. A research system should include problems where the model must choose a correct method, detect a misleading assumption, and distinguish a justified result from an attractive but wrong explanation.

Our suggested test is to compare accepted deliverables at a fixed total task budget. Include repair time and retries. If Kimi completes the routine workload reliably, reserve Astra for the cases where its extra cost buys a demonstrated improvement. If the workload is dominated by hard scientific reasoning, reverse the order and test Kimi as a lower-cost challenger.

Kimi K3.1 Pro versus GPT-6.1 Sol

This is the closest commercial contest. Matching token prices make it tempting to choose whichever has the higher aggregate score. The measured task costs show why that shortcut fails.

Sol is a sensible baseline when tasks are numerous and budget-sensitive. Kimi needs to improve completion, reduce supervision, or handle the input more economically enough to justify its observed token consumption. A small improvement can be valuable if failure is costly, but it should be visible in your acceptance criteria.

Long input changes the economics because Sol's price increases above its threshold. A document-heavy workload should be tested separately from a short coding request. Caching also deserves its own trial: a one-off prompt does not represent an agent that reuses the same repository or project brief for dozens of turns.

Kimi K3.1 Pro versus Claude Fable 5.1

Kimi's launch gives buyers a reason to re-evaluate expensive maximum-effort Fable workloads, particularly routine agent work. Fable's strong knowledge and reasoning results remain relevant when an incomplete or poorly grounded answer would cause expensive downstream work.

The model choice should reflect whether the application needs independent reasoning, retrieval, polished deliverables, or execution across tools. Those requirements are often combined in one product but can be evaluated separately.

For a Fable customer, first identify the difficult cases that justified using it. Run Kimi on that set alongside ordinary work, and examine the failure distribution. An average score can conceal a regression in a narrow but important class of tasks. Include a lower Fable effort setting in the comparison if that is what the product would actually use.

Kimi K3.1 Pro versus Claude Opus 5.5

Opus presents the clearest challenge to a claim that Kimi is the overall best model. Its aggregate result is stronger, with substantial advantages in several knowledge and scientific measurements. It also has higher measured output throughput in this snapshot.

Kimi's case rests on agent-work strengths and cost. A buyer should determine whether Opus' stronger results produce better accepted work in the intended application, rather than paying for capability that the workflow rarely needs.

For document production, review factual correctness and presentation independently. A polished report with an unsupported conclusion should fail. A correct but awkward draft may be cheap to repair. Giving both dimensions their own scores makes the model tradeoff easier to see.

Which model should you test first?

The following recommendations are our interpretation of the published evidence. They are starting points for evaluation, not measured guarantees about your workload.

Scroll sideways to see every column.

A fair internal evaluation can be modest. Select a small, representative set of real tasks with enough variation to expose failure modes. Give each system the same source material and permissions. Define what a passing result looks like before running the models. Hide the model names from reviewers when feasible.

Keep a raw record of billed input, cache reads and writes, reasoning/output tokens, tool charges, wall-clock time, retries, and final acceptance. Compare a realistic production setting first, then a maximum-effort setting if the extra cost is relevant. Maximum effort is useful evidence of a capability ceiling; it may be the wrong default for an interactive workflow.

For coding, use tests the model did not write as the sole judge of itself. For research, check whether sources support the exact claims made. For spreadsheets, verify formulas and assumptions against source data. For computer use, verify the final application state and unintended side effects. A screenshot or fluent explanation is weak evidence of completion.

Evidence that could change the verdict

New evidence can change this comparison. Material developments belong in the relevant sections, with original measurement dates retained so readers can distinguish new results from a later check of the same source.

The useful developments to watch are independent replications, new Sol 6.1 comparisons under matching conditions, changes in Kimi's serving speed, clarification of subscription pricing, corrections to launch documentation, and any change to the weight-release commitment. A different leaderboard position without a documented methodological or numerical change deserves investigation before changing the verdict.

The key unresolved buying question is whether Kimi's advantage on agent evaluations produces more accepted work than Sol for the additional task cost. A matched trial using your own acceptance criteria would answer that more directly than another aggregate leaderboard screenshot.