Comparisons, benchmarks, pricing, context-window analysis, and task-specific guidance for choosing the best AI models and LLMs for coding, debugging, refactoring, testing, and code review.
Claude Sonnet 5 is a credible option for large-codebase work because Anthropic gives it a one-million-token context window and positions it for complex, multi-file coding. That capacity can keep more source, documentation, and tool history available during a task. It does not automatically reveal architecture, dependency boundaries, ownership, or the reasons behind past design decisions.
The practical question is therefore not whether Sonnet 5 can ingest a large repository. It is whether your Claude Code workflow supplies the right evidence, lets the model navigate selectively, and verifies changes against the repository’s actual constraints.
Why Large Codebases Stress Coding Models
Large repositories are difficult because relevant knowledge is distributed rather than merely long. A change that looks local may depend on a schema, generated client, build rule, feature flag, deployment contract, or convention defined elsewhere.
Repository work also contains several kinds of context:
Source context: functions, types, tests, configuration, and generated artifacts.
Structural context: imports, calls, inheritance, data flow, package boundaries, and service dependencies.
Operational context: build commands, CI rules, deployment order, observability, and rollback requirements.
Institutional context: ownership, accepted patterns, rejected alternatives, and design intent.
A model can read source without knowing which relationships matter. For example, finding every textual reference to a type is not the same as identifying every runtime consumer of the data it represents. Large-codebase work stresses retrieval, prioritization, planning, execution, and regression control at the same time.
Claude Code can reduce some friction because it lets the model inspect files, search the repository, edit code, and run commands. However, tool access changes the workflow, not the truth available inside the repository. Missing documentation and weak tests remain missing evidence.
What a Larger Context Window Can Help With
Anthropic’s current documentation lists Claude Sonnet 5 as claude-sonnet-5, with a one-million-token context window by default and up to 128,000 output tokens. Anthropic also says the model is available through Claude Code, Claude.ai, the Claude API, and supported cloud platforms.
That larger working space can help in four practical ways.
First, it reduces premature eviction. The agent can retain more of the issue, inspected files, tool results, plans, and test failures before it must compress or discard earlier material.
Second, it supports wider evidence gathering. A migration task may require reading interface definitions, several implementations, representative tests, and build configuration together.
Third, it gives long-running tool workflows more room. Planning, editing, testing, diagnosing, and revising all consume context. A larger window can preserve continuity across those steps.
Fourth, it can make cross-file comparison easier. Anthropic describes Sonnet 5 as suitable for reasoning across complex multi-file codebases and large-scale refactors. This is a vendor capability claim, not independent proof for every repository, but it is consistent with the model’s intended use.
Nominal window size still needs interpretation. Anthropic says Sonnet 5 uses a new tokenizer that can produce roughly 30% more tokens for the same text than Sonnet 4.6. A “one-million-token repository” is therefore not a stable number of files, lines, or modules across models.
What Context Windows Still Miss
A context window stores selected material for a run. It does not turn that material into a maintained model of the system.
The window does not inherently know:
which service owns a shared contract;
whether an import is architectural or incidental;
which dependency is loaded dynamically;
why a team rejected an apparently simpler design;
which generated files must never be edited;
which downstream repository consumes an API;
whether a passing unit test misses a production invariant.
More raw text can even create a selection problem. Loading broad directory trees may bury the critical interface among duplicated fixtures, generated code, vendored packages, and stale documents. Attention is finite even when capacity is large.
Long-context evaluations reinforce this distinction. They can measure retrieval or reasoning over long inputs, but accepting a long prompt is not equivalent to perfect recall, correct impact analysis, or compliance with undocumented conventions.
The safest workflow treats context capacity as room for evidence, not as proof that the evidence is complete or correctly organized.
Where Code Knowledge Graphs Fit
A code knowledge graph can act as a query layer over repository structure. Instead of repeatedly asking the model to rediscover relationships from raw files, the workflow can expose nodes such as symbols, modules, APIs, tests, owners, and documents, connected by typed relationships.
This changes the initial question from “Which files should fit in the prompt?” to “Which entities and relationships are relevant to this change?” The graph can identify a smaller evidence set, while Sonnet 5 reads the underlying code and reasons about the requested task.
A useful division of labor is:
Layer
Best use
Context window
Hold task-specific source, plans, tool output, and current reasoning
Repository search
Find exact text, filenames, symbols, and recent changes
Code knowledge graph
Query dependencies, callers, ownership, tests, and cross-module paths
Project documentation
Explain architecture, policy, and design intent
Test and build system
Verify behavior and detect regressions
Graphs have limits too. A stale graph can confidently return obsolete relationships. Dynamic calls, reflection, generated code, runtime configuration, and external consumers may be incomplete. Graph results should point the model toward source evidence, not replace source inspection.
Do not select a coding model for a large repository from its advertised context window or a single leaderboard score. Run a private pilot against work that resembles your team’s real changes.
Use a frozen repository commit and a balanced task set:
a localized bug with clear tests;
a cross-module change involving a public interface;
a refactor constrained by architecture rules;
a CI or build failure with environmental dependencies;
an impact-analysis task that does not require editing.
Record the model ID, Claude Code version, effort setting, tool permissions, network policy, starting prompt, context supplied, commands, patch, test results, elapsed time, and token cost. Repeat each task because one successful trajectory does not establish reliability.
Benchmark evidence needs similar care. OpenAI reported in February 2026 that SWE-bench Verified had contamination and flawed-test problems. In July, it estimated that roughly 30% of SWE-Bench Pro tasks were broken. Those findings do not make repository benchmarks useless; they mean teams should inspect task design and avoid treating a headline pass rate as a universal measure of codebase understanding.
Human review should focus on dependency impact, unnecessary edits, missing consumers, test adequacy, and violations of repository conventions. Architecture-sensitive or production-critical changes should require approval even when the patch passes its visible tests.
FAQ
What repo docs should be prepared first?
Prepare a short repository map, build and test commands, module ownership, architecture boundaries, public contracts, generated-file rules, and links to current design decisions. Keep instructions concise and route deeper details through linked documents so the model can retrieve them when relevant.
How should teams test large-repo behavior?
Use private tasks from the target repository, hidden acceptance and regression tests, isolated environments, and repeated runs. Include both editing and analysis tasks. Compare correctness, regression rate, review effort, diff size, latency, and cost rather than context size alone.
When should model output require architecture review?
Require architecture review when a change crosses service or package boundaries, alters a public contract, changes persistence or security behavior, introduces a new dependency, modifies deployment topology, or relies on an inferred relationship that the repository does not verify automatically.
Conclusion
Claude Sonnet 5 gives Claude Code substantially more working room and is officially aimed at demanding coding and agent workflows. That makes it useful for large repositories, but not self-sufficient.
Use its long context to hold the evidence selected by repository search, documentation, and structured code relationships. Then use tests and human review to verify the result. The decision rule is simple: choose Sonnet 5 when it improves real repository outcomes under your harness—not because one million tokens sounds large enough to contain the codebase.
GLM-5.2’s one-million-token context window and a code knowledge graph are not substitutes. The context window holds source, instructions, tool results, and reasoning for the current run. A graph stores selected repository entities and relationships so agents can query structure across runs. Large-repository workflows usually benefit from both.
The useful comparison is therefore not “Which one understands code?” It is “Which information should stay in working memory, and which relationships should remain reusable outside the prompt?”
Quick Verdict
Use GLM-5.2’s long context when a task requires reading substantial primary evidence together: multiple implementations, tests, specifications, logs, or a long coding-agent trajectory. Use a code knowledge graph when the task begins with structural questions such as which components call an API, which tests cover a symbol, or which modules sit downstream of a schema.
The two layers work best as a retrieval-and-reasoning loop:
the graph narrows the relevant entities and paths;
the agent retrieves the authoritative source files;
GLM-5.2 reasons over those files and the active task;
tests and human review verify the change;
the repository index refreshes after accepted changes.
Long context lowers the pressure to discard evidence. A graph lowers the cost of rediscovering relationships. Neither guarantees correct code.
Evaluate both layers with repeatable repository tasks. Measure discovery time, irrelevant files retrieved, missed dependencies, unsupported relationship claims, and corrections after tests. Those metrics distinguish genuine navigation gains from the simple ability to place more text inside one request.
What a 1M Context Window Can Help With
Z.ai launched GLM-5.2 on June 16, 2026 and officially documents a one-million-token context window. Its Coding Plan instructions identify GLM-5.2[1m] as the selection for enabling the one-million-token mode in Claude Code, so teams should confirm the actual model mode used in a trial.
A large window can improve a coding workflow in several concrete situations:
comparing an interface with many implementations and tests;
keeping a long issue description, repository evidence, and execution plan together;
retaining tool output across repeated build, test, and debugging cycles;
analyzing large logs alongside the relevant code;
completing long-horizon tasks without compressing the trajectory as early.
Z.ai reports results for GLM-5.2 on coding and long-horizon evaluations, including SWE-bench Pro, NL2Repo, Terminal-Bench 2.1, FrontierSWE, PostTrainBench, and SWE-Marathon. These numbers are vendor-reported results under disclosed but different harnesses. They support the claim that Z.ai designed the model for coding-agent work; they do not prove that every task used one million tokens or that the model understood every repository relationship.
The distinctions matter. Z.ai says several standard coding runs used 256K or 400K context, while its named long-horizon runs used 1M. A benchmark result belongs to its model, harness, prompt, effort setting, tool policy, timeout, resources, and dataset version—not to context length alone.
GLM-5.2 is also available as open weights under an MIT license. The official model card lists approximately 753 billion parameters and documents several serving frameworks. That makes self-hosting possible in principle, but “local” should not be confused with laptop-scale deployment.
Why Raw Context Still Lacks Structure
Raw context is ordered tokens. Repository structure is a set of typed, changing relationships.
Suppose an agent must change a request object used by five services. Loading a million tokens might include the type definition, several callers, documentation, and tests. It may also include generated code, duplicate fixtures, old migration paths, and unrelated vendor packages. The model must still identify which evidence is authoritative.
Context alone does not explicitly answer:
Which callers are reachable in production?
Which implementation owns the contract?
Which tests cover the affected path?
Which service deploys first?
Which dependency is dynamic rather than imported directly?
Which design decision explains the current boundary?
These questions require navigation and interpretation. A long window can hold the answer after it is found, but it does not ensure the correct files were selected.
Long prompts also create operational costs. Prefill latency, cache capacity, inference memory, and token billing can grow with the supplied material. Z.ai’s own architecture discussion describes the serving challenges created by one-million-token workloads. The right goal is not to maximize prompt occupancy. It is to maximize relevant evidence per task.
Code Knowledge Graphs as a Query Layer
A code knowledge graph represents repository entities as nodes and meaningful relationships as edges. Depending on the index, nodes may include files, symbols, modules, endpoints, schemas, tests, owners, commits, and design documents.
An agent can use that graph to ask focused questions before opening raw files:
Repository question
Possible graph relation
What calls this function?
symbol → caller
What breaks if this schema changes?
schema → consumer
Which tests exercise this endpoint?
endpoint → test
Who owns this package?
module → owner
Which design note explains this dependency?
component → decision document
The graph is a query layer, not the final source of truth. The agent should follow graph results to current code, configuration, and tests. This protects the workflow from stale or incomplete indexes.
Graphs are particularly useful across model changes. A repository team can switch from GLM-5.2 to another coding model without rebuilding every piece of project memory inside a new prompt. The model-specific context remains temporary; the repository relationship layer remains reusable.
Graphify’s role in this design is to provide structured code knowledge for navigation and impact analysis, while the coding model performs task-specific reasoning. This is complementary to GPT context and repository understanding, not a claim that a graph can replace source reading.
What to Verify About GLM-5.2
Verify the exact endpoint and mode before publishing or acting on a “1M context” result. Record whether the trial used hosted Z.ai access, a Coding Plan integration, or self-hosted weights, plus the model ID, serving framework, quantization, context limit, effort setting, and agent harness.
Then test the complete system on private repository tasks. A useful evaluation matrix includes:
a focused bug fix;
cross-module impact analysis;
a multi-file feature;
an architecture-constrained refactor;
a long test-and-debug trajectory.
Use frozen commits and isolated environments. Keep acceptance tests hidden from the agent, run regression tests, repeat tasks, and retain the full trajectory. Check for grader gaming as well as normal failure. Z.ai specifically documents anti-hacking controls because coding agents can attempt to read protected artifacts, fetch known solutions, or optimize the evaluator rather than solve the underlying task.
Public benchmarks deserve additional caution. OpenAI reported contamination and flawed tests in SWE-bench Verified, then estimated in July 2026 that roughly 30% of SWE-Bench Pro tasks were broken. Use public scores as directional evidence, and let audited private tasks decide workflow fit.
Measure more than pass rate: relevant files retrieved, missed dependencies, unnecessary prompt tokens, regression rate, diff quality, review effort, latency, and cost.
FAQ
What files should not be loaded by default?
Avoid loading generated output, vendored dependencies, build artifacts, duplicated fixtures, archived migrations, large binary-derived text, and broad logs unless the task requires them. Keep security-sensitive material and unrelated customer data outside model context. Use repository rules and graph filters to identify authoritative sources.
How should teams measure context quality?
Measure whether the supplied context contains the minimum sufficient evidence for the task. Track relevant-file precision and recall, missed dependencies, unsupported assumptions, duplicated tokens, time to first correct plan, regression rate, and human corrections. Maximum token count is a capacity metric, not a quality metric.
Can long context and graphs work together?
Yes. Query the graph to identify relevant entities and dependency paths, retrieve the underlying source and tests, then let the long-context model reason over that evidence and its tool trajectory. Refresh the graph after accepted changes and periodically audit it against the repository.
Conclusion
GLM-5.2’s one-million-token context is a real, officially documented capability that can support long coding trajectories and broad evidence sets. A code knowledge graph solves a different problem: making repository relationships explicit, queryable, and reusable.
Choose the combination based on measured repository outcomes. Use the graph to select and organize evidence, use GLM-5.2 to reason over the active task, and use tests plus review to establish correctness. Raw tokens and structured knowledge are strongest when each handles the job it was designed for.
GPT-5.6 Sol is an officially available frontier model with a 1.05-million-token context window and strong vendor-reported coding-agent results. Switching to it may improve planning, persistence, tool use, and implementation. It still does not arrive knowing a private repository’s architecture, dependency rules, ownership, deployment constraints, or design history.
A model change can raise the ceiling of a coding workflow. Reliable repository understanding still depends on the evidence and verification system surrounding the model.
Why Users Switch Models for Codebase Tasks
Developers usually switch coding models after encountering a repeated workflow failure: the agent loses track of a long task, misses a related file, produces a plausible but incomplete refactor, consumes too many tokens, or needs too much steering.
GPT-5.6 Sol is relevant because OpenAI positions it as the flagship tier of the GPT-5.6 family. The official API page lists gpt-5.6-sol as the model ID, with the gpt-5.6 alias routing to Sol. It supports a 1,050,000-token context window and up to 128,000 output tokens.
OpenAI announced general availability on July 9, 2026 across ChatGPT, Codex, and the API, with plan and workspace eligibility differences. Developers should verify that their account, Codex version, model selection, and reasoning setting match the intended trial.
Those specifications make a switch attractive for:
long-running implementation and debugging;
multi-file changes with substantial source evidence;
tool-heavy workflows that search, edit, build, and test;
tasks where a larger working context delays compaction;
teams seeking a different capability, latency, or cost profile.
The switch should begin with a hypothesis, such as “Sol reduces missed cross-module dependencies in our migration tasks,” rather than the vague expectation that a stronger model will understand the repository automatically.
Keep the previous model as a control during that trial. Run identical repository tasks from clean sessions, provide the same tools and evidence, and compare navigation errors, dependency omissions, verification behavior, latency, and total cost—not just whether the final patch appears plausible.
What a Better Model Can Improve
OpenAI describes GPT-5.6 Sol as its best coding model at launch and reports results on coding-agent evaluations that include real codebases, terminal workflows, and long-horizon engineering.
In OpenAI’s launch table, Sol scores 64.6% on SWE-Bench Pro, 72.7% on DeepSWE v1.1, and 88.8% on Terminal-Bench 2.1. OpenAI also reports 91.9% for Sol Ultra on Terminal-Bench 2.1. These are vendor-reported results and belong to the stated model settings and evaluation harnesses; they are evidence of intended capability, not guarantees for a private repository.
In practice, a better coding model may improve:
decomposition of a broad request into testable steps;
persistence across long tool trajectories;
selection and coordination of terminal tools;
interpretation of test failures;
consistency across related edits;
review of its own patch before handoff.
The large context window can retain more source, documentation, tool output, and intermediate decisions. Programmatic tool coordination can also reduce the need to pass every intermediate result through the model unchanged.
However, OpenAI’s own long-context results show why capacity is not perfect retrieval. Its launch page reports 73.8% on an eight-needle MRCR evaluation spanning 512K to 1M tokens and 77.1 F1 on GraphWalks BFS at one million tokens. Those are not repository benchmarks, but they demonstrate that accepting a long input does not imply flawless use of everything inside it.
What It Still Does Not Know About Your Repo
GPT-5.6 Sol does not know private facts that are absent from its prompt, tools, or repository. It also cannot reliably infer every convention from code alone.
Important missing knowledge may include:
which team owns a shared API;
which package boundary is intentional;
which generated files are overwritten by CI;
which downstream service consumes an event;
which feature flag controls a production path;
why an earlier implementation was rejected;
which migration order avoids a compatibility break;
which tests are known to be incomplete.
A repository can contain contradictory signals. A stale README may disagree with current code. A test can encode legacy behavior. A comment can describe an abandoned plan. A broad context dump gives the model all three without identifying authority.
The model also sees only the repository and external systems it is permitted to inspect. Cross-repository consumers, production configuration, private runbooks, and unwritten operational knowledge remain outside its view unless the workflow exposes them.
This is why Claude Code repository context and Codex context engineering should focus on evidence organization, not only model selection.
Structured Knowledge vs Raw Prompt Context
Raw prompt context is task-local working memory. Structured repository knowledge is reusable navigation and policy.
A robust workflow can separate the layers:
Knowledge layer
Example
Update pattern
Task context
issue, plan, inspected code, test output
every run
Repository map
modules, entry points, build and test commands
on structural change
Code graph
callers, dependencies, schemas, tests, owners
indexed after accepted changes
Architecture record
boundaries, decisions, rejected alternatives
human-reviewed
Verification
hidden tests, regression suite, CI, review
every change
The model should use structured knowledge to locate relevant evidence, then inspect the current source. A graph edge that says service A consumes schema B is useful for impact analysis, but the source and runtime configuration should verify the relationship.
This design protects repository memory from model churn. Teams can replace GPT-5.6 Sol with another model without rewriting the architecture map or losing indexed dependency relationships. Conversely, the model’s large context remains valuable for reasoning over the selected code and current trajectory.
Structured context can also reduce prompt waste. Instead of loading an entire monorepo, the agent can query the affected entities, follow dependency paths, and retrieve a task-specific evidence set.
Verification and Risk Notes
Evaluate GPT-5.6 Sol on private tasks that represent the repository and risk level. Public coding benchmarks are useful for orientation, but their task quality and contamination must be considered.
OpenAI stopped recommending SWE-bench Verified for frontier comparisons after finding flawed tests and contamination. In July 2026, OpenAI also estimated that roughly 30% of SWE-Bench Pro tasks were broken. The responsible conclusion is not that benchmarks have no value. It is that teams need auditable task design and more than one measurement.
For a model trial:
freeze the repository commit and execution environment;
select localized, cross-module, refactor, CI, and impact-analysis tasks;
hide acceptance and regression tests from the agent;
keep model, reasoning, tool, network, timeout, and permission settings constant;
run multiple independent trials;
retain trajectories, patches, test output, latency, tokens, and cost;
review missed dependencies, unnecessary edits, policy violations, and grader gaming.
Compare the new model with the current default using the same harness. A higher pass rate can still hide larger diffs, more review work, or unacceptable regressions. Conversely, a model that solves fewer benchmark-like tasks may be better on your architecture-specific workload.
Require dependency review for changes that cross packages or services, modify public contracts, alter persistence or security behavior, introduce dependencies, or depend on relationships not enforced by tests.
FAQ
What repo knowledge should survive model changes?
Keep architecture maps, ownership, public contracts, build and test commands, dependency relationships, decision records, generated-file rules, operational constraints, and known test gaps outside model-specific prompts. Version them with the repository or a governed knowledge system.
How should teams test a new coding model?
Run the current and candidate models against the same frozen private tasks with identical permissions and tools. Repeat trials and compare correctness, regressions, dependency coverage, diff size, human steering, review time, latency, tokens, and total cost.
When should outputs require dependency review?
Require it when an edit changes a shared type, API, event, schema, package boundary, deployment order, security control, or external integration. Also require it when the agent cannot produce evidence for every identified downstream consumer.
Conclusion
GPT-5.6 Sol can materially improve a coding-agent workflow. Its official context size, tool support, and vendor-reported results justify testing it on demanding codebase tasks.
The model is still one layer of repository understanding. Preserve architecture and dependency knowledge outside the prompt, retrieve current source for each task, and verify every consequential change with tests and review. Switch models when the measured end-to-end workflow improves—not when the model name or context number changes.
The Inkling model is Thinking Machines Lab’s first open-weight foundation model: a 975-billion-parameter Mixture-of-Experts system with 41 billion active parameters, native text, image, and audio reasoning, and weights designed for customization. It arrived on July 15, 2026, with a deliberately measured pitch. Thinking Machines Lab does not call Inkling the strongest model overall. It presents Inkling as a broad base that developers can inspect, deploy, and fine-tune.
That distinction matters. Inkling combines an unusually large sparse architecture, controllable reasoning effort, multimodal inputs, and a native context window of up to one million tokens. But the practical product has boundaries: hosted Tinker access currently exposes 64K and 256K contexts, self-hosting demands hundreds of gigabytes to terabytes of accelerator memory, and most headline benchmark results come from the vendor’s release evaluation rather than a uniform independent test.
This guide separates the Inkling model’s published specifications from its marketing, explains how its architecture works, interprets the benchmarks, and shows the realistic options for trying, fine-tuning, or self-hosting it.
Mira Murati founded Thinking Machines Lab after serving as OpenAI’s chief technology officer. This source cover image accompanied the original Chinese report.
66 layers; 256 routed experts plus 2 shared experts per MoE layer
Six routed experts activate for each token
Context
Up to 1M tokens in the native model
Tinker currently offers 64K and 256K configurations
Inputs and output
Text, images, and 16 kHz WAV audio in; text out
Video appeared in pretraining data but is not a documented runtime input
Pretraining
45 trillion multimodal tokens
Exact corpus mix and training cutoff are not disclosed
Fine-tuning
Available through Tinker
Playground and cookbook recipes lower the evaluation barrier
Checkpoints
BF16 and NVIDIA-oriented NVFP4
BF16 needs at least 2 TB aggregate VRAM; NVFP4 at least 600 GB
License position
Checkpoints labelled Apache 2.0 plus a separate Model Acceptable Use Policy
Accurate shorthand is “open-weight,” not unrestricted open source
Smaller model
Inkling-Small preview: 276B total, 12B active
Full weights were not released as of July 16, 2026
What is the Inkling Model?
Inkling is a general-purpose multimodal model trained from scratch by Thinking Machines Lab. Its stated purpose is not to dominate one benchmark category. The company trained it across reasoning, coding, tool use, instruction following, factuality, vision, audio, conversation, and safety so that organizations can adapt one foundation to different workflows.
The company’s release announcement emphasizes three properties:
Open weights: developers can download the checkpoint rather than accessing it only through a closed API.
Native multimodality: text, image, and audio representations are processed jointly by the model.
Controllable thinking effort: applications can trade additional reasoning tokens for performance instead of using one fixed inference budget.
Thinking Machines Lab’s launch announcement describes Inkling as an open-weight model for reasoning across text, images, and audio, with fine-tuning available through Tinker.
Inkling is also intended to become the background reasoning component for the company’s interaction-model work, where users collaborate through voice and vision. That helps explain why the first release prioritizes breadth and customizability over a narrow benchmark crown.
Open weight does not mean completely open
Inkling’s Hugging Face repositories label the checkpoints Apache-2.0. However, Thinking Machines Lab also applies a binding Model Acceptable Use Policy with additional restrictions. The complete pretraining corpus, corpus proportions, full training code, and total compute budget are not published.
For that reason, “open-weight model” is the precise description. “Fully open-source AI” would imply a level of training transparency and unrestricted use that the release does not provide.
Architecture: 975B total, 41B active
Inkling is a 66-layer sparse MoE Transformer. Although the checkpoint contains 975 billion parameters, only about 41 billion are active for each token. Sparse activation is what makes a model of this total size computationally usable: the router sends each token to a subset of specialized expert networks instead of evaluating every parameter.
Each MoE layer contains 256 routed experts and two shared experts. Six routed experts activate per token. Their outputs are combined with the shared experts after joint score normalization. The router uses sigmoid scores and an auxiliary-loss-free balancing bias, following ideas popularized by DeepSeek-V3.
The attention stack alternates five sliding-window layers for every global-attention layer, producing 55 local and 11 global layers. There are eight key-value heads. Thinking Machines Lab chose learned relative-position attention instead of RoPE, reporting better long-sequence extrapolation in its experiments. Short convolutions appear after key/value projections and again before attention and MLP residual branches return to the main residual stream.
These details are not cosmetic. Local attention controls cost, periodic global attention carries information across the sequence, and sparse experts expand capacity without activating the entire 975B checkpoint for every token.
The launch demo places Inkling inside an OpenCode harness and asks it to write, run, and evaluate a Tinker fine-tuning job. It is a product demonstration, not an independent autonomy benchmark.
Multimodal inputs and the 1M-token context window
The native Inkling architecture supports up to one million tokens, but that number needs qualification. Thinking Machines Lab’s Tinker service currently exposes 64K and 256K variants. A buyer evaluating the hosted service should plan around those product limits rather than assuming the full native window is available through every endpoint.
The formal model card documents three runtime input types:
UTF-8 text;
pixel images, with recommended dimensions between 40 and 4,096 pixels;
WAV audio sampled at 16 kHz, with an optimal length of 20 minutes or less.
Output is text. Although video was part of the 45-trillion-token pretraining mixture, video is not listed as a supported runtime input. Calling Inkling a text-image-audio model is therefore more accurate than calling it a video model.
Vision inputs are divided into 40×40-pixel patches and transformed through a four-layer hierarchical MLP. Audio enters as dMel spectrogram representations. Lightweight embedding front ends convert both modalities into representations processed jointly with text tokens by the decoder. Thinking Machines Lab describes this as encoder-free because it avoids a separate large vision or audio encoder.
The vendor’s radar chart illustrates breadth rather than a single aggregate score. Comparing axes with different evaluation methods should be treated as directional.
Inkling benchmarks: strengths and trade-offs
The most useful way to read Inkling’s results is as a capability profile, not a universal leaderboard. Thinking Machines Lab ran its release evaluations at thinking effort 0.99 and temperature 1.0. Coding trajectories could use up to 256K tokens. Some comparator results came from Artificial Analysis, some were self-reported by other vendors, and others used Thinking Machines Lab’s internal harnesses.
Selected published Inkling results include:
Area
Evaluation
Inkling result
Reasoning
Humanity’s Last Exam, text only
29.7%
Reasoning with tools
Humanity’s Last Exam
46.0%
Science reasoning
GPQA Diamond
87.2%
Coding
SWE-bench Verified
77.6%
Coding
SWE-bench Pro Public
54.3%
Terminal agents
Terminal-Bench 2.1, best harness
63.8%
General agents
MCP Atlas
74.1%
Instruction following
IFBench
79.8%
Vision
MMMU Pro
73.5%
Audio
VoiceBench
91.4%
The company explicitly says Inkling is not the strongest model overall. Closed models lead many reasoning and coding rows, while other open-weight systems win specific tasks. Inkling’s argument is that one downloadable checkpoint is competitive across several domains and can be adapted.
Agentic coding and artifact creation
Thinking Machines Lab trained Inkling in multiple coding-agent harnesses and randomized tool definitions to reduce dependence on one interface. In Design Arena’s blinded web-development comparison, Inkling appeared among the stronger open-weight entries at launch, but below several closed models.
Design Arena uses pairwise human judgments of generated web applications. It is useful evidence about visual artifact quality, but it is not a substitute for repository-level software correctness testing.
The demos also show Inkling creating a multi-page travel journal and refining a multiplayer snake game over 40 feedback rounds with a Codex model acting as reviewer. These examples demonstrate sustained tool use and visual consistency under curated conditions. They do not prove that arbitrary long-running tasks will finish without supervision.
A launch demo shows a nine-page food-and-travel journal with consistent visual styling. The animated source is preserved from the original article.
Controllable thinking effort
Inkling can vary its reasoning budget from approximately 0.2 to 0.99 effort. During reinforcement learning, the team changed system-message instructions and the per-token cost so the model learned to respond with different amounts of computation.
This creates a more useful deployment question than “What is the best score?” Applications can ask what score is available at an acceptable token budget and latency. In the vendor’s Terminal-Bench sweep, Inkling matched Nemotron 3 Ultra’s score with roughly one-third as many generated tokens. That is promising efficiency evidence, but it remains a vendor-run comparison whose harness and operating points matter.
Inkling’s blue curves trace performance as effort rises. Competitors are shown at default operating points, so the chart compares a sweep with individual reference points rather than identical inference policies.
Audio and vision
Inkling’s reported audio results place it near specialist open-weight audio models: 77.2% on MMAU and 91.4% on VoiceBench. The VoiceBench score should be read carefully because the benchmark uses formatting-sensitive string matching; Thinking Machines Lab added a system instruction to produce the expected answer format.
For vision, Inkling reported 73.5% on MMMU Pro and 78.1% on CharXiv reasoning questions, rising to 82.0% when a Python tool was available. Tool-assisted image reasoning can zoom, crop, or calculate, but it also means the tool environment contributes to the final result.
The multimodal comparison mixes open- and closed-weight systems. Missing cells mean the source did not report a directly comparable score.
Safety results are a starting point
The vendor reports 78.0% on FORTRESS Adversarial, 95.9% on FORTRESS Benign, and 98.6% on StrongREJECT at effort 0.99. The combination is intended to measure refusal of harmful prompts without excessive refusal of benign look-alikes.
These are release-time safety evaluations, not a guarantee for every deployment. Fine-tuning, tools, system prompts, and application context can materially change behavior.
Open weights make independent evaluation possible, but they also let deployers modify safeguards. Any production use still needs domain-specific red teaming, access control, logging, and post-fine-tuning evaluation.
Why the full benchmark table needs footnotes
Inkling’s open-weight comparison shows strong results in some instruction-following, coding, and multimodal rows, while GLM, Kimi, Nemotron, or other systems lead elsewhere.
The open-weight table uses a mixture of external scores, vendor self-reports, and Thinking Machines Lab harnesses. Small differences should not be treated as statistically decisive.
The table against closed models is even more useful as a reality check: Inkling generally trails the strongest proprietary systems on difficult reasoning and coding rows, despite competitive instruction-following and some agentic results.
Thinking Machines Lab’s own table supports its restrained positioning: Inkling offers breadth and control, not across-the-board frontier leadership.
Teams should rerun their own prompts, tools, latency limits, and cost assumptions. A one-point difference from a release table is less important than reproducibility in the intended environment. For a broader evaluation framework, see Graphify’s guide to the best LLMs for coding in 2026.
How the Inkling model was trained
Inkling was pretrained on 45 trillion tokens spanning text, images, audio, and video. The model card describes broad source categories—public internet and repositories, acquired third-party data, and synthetic or augmented data—but does not publish the mix, named datasets, or cutoff date.
Large matrix weights used the Muon optimizer, while other parameters used Adam. The team coupled weight decay to the square of the learning rate and used schedules inspired by its modular-manifold research. Post-training covered math, agentic coding and tool use, audio, vision, conversation, factuality, and safety.
An initial supervised fine-tuning stage used synthetic data generated by open-weight models, including Kimi K2.5. Thinking Machines Lab says that stage consumed a small share of compute and that the majority went to large-scale reinforcement learning on synthetic and human-created environments.
The asynchronous RL program exceeded 30 million rollouts over two long continuous runs on NVIDIA GB300 NVL72 systems.
The held-out aggregate reward rose roughly log-linearly across the reported run. Because the aggregate combines several evaluations, it does not reveal whether every capability improved at the same rate.
The team also observed that the model’s hidden reasoning traces became shorter and more telegraphic as training rewarded efficiency. That observation is interesting, but compressed internal reasoning should not be confused with a guarantee of lower end-to-end latency or higher answer quality.
The example shows fewer grammatical connectives in a later RL trace while retaining the same solution path. It is an illustrative sample, not a population-level measure.
Inkling-Small preview
Inkling-Small is a separate 276B-parameter MoE preview with 12B active parameters. Thinking Machines Lab reports that it uses a similar architecture, improved pretraining data and recipe, and the same scalable post-training stack.
The smaller model is close to Inkling on several published rows and slightly ahead on HLE with tools, GPQA Diamond, IFBench, and a few multimodal tests. It is also materially behind on Terminal-Bench 2.1, Tau 3 Banking, SimpleQA Verified, and AudioMC.
Inkling-Small trades capacity for 12B active parameters. As of July 16, 2026, it remained a preview and its full weights had not been released.
There is no published firm release date, complete hardware profile, standalone price, or public checkpoint for Inkling-Small. Treat it as a roadmap signal rather than a deployable option today.
How to access and use Inkling
There are three practical paths.
1. Evaluate or fine-tune through Tinker
Tinker offers Inkling with 64K and 256K context configurations. The Inkling Playground provides chat and integrated web search for quick qualitative testing. Tinker’s cookbook adds audio recipes, while tml-renderer supports sampling and post-training with tool calls, reasoning content, and multimodal inputs.
Thinking Machines Lab advertised a limited-time 50% discount at launch. Its July 16 documentation listed, per one million tokens:
Tinker mode
Prefill
Cached input
Sample
Train
64K
$1.87
$0.374
$4.68
$5.61
256K
$3.74
$0.748
$9.36
$11.23
Pricing is time-sensitive, and the documentation warned of broader changes effective July 17. Verify current prices before budgeting.
2. Use a hosted inference provider
Thinking Machines Lab announced Together AI, Fireworks, Modal, Databricks, and Baseten as API partners. Availability can differ by provider and date: Modal and Baseten published live launch support, while Together’s public page still said “coming soon” during this review. Check the chosen provider’s actual endpoint, context limit, modality support, and price rather than assuming every announced integration is live.
3. Download and self-host the weights
The official Hugging Face organization publishes BF16 and NVFP4 checkpoints. The model is integrated or being integrated with Transformers, SGLang, vLLM, TokenSpeed, and llama.cpp-related workflows.
Hardware is the main constraint:
BF16: at least 2 TB of aggregate VRAM; the model card gives examples such as eight B300 or sixteen H200 GPUs.
NVFP4: at least 600 GB; W4A4 targets four B300 GPUs, while W4A16 can target eight H200 GPUs.
Those are minimum memory profiles, not complete production sizing. KV cache, context length, concurrency, multimodal preprocessing, networking, and serving overhead all affect the real cluster requirement.
Fine-tuning Inkling with Tinker
Inkling is most differentiated when a team needs to adapt a generalist model to specialized judgments, tools, audio workflows, or internal data. A sensible pilot is narrower than “fine-tune our company model”:
Define one measurable task and a held-out test set.
Establish the base model’s quality, latency, token use, and refusal behavior.
Fine-tune on a small, provenance-controlled dataset.
Compare the checkpoint against the base using blinded review and task metrics.
Re-run safety, privacy, and regression tests after every training change.
Record the exact checkpoint, renderer, prompt format, effort setting, and tool schema.
The model’s size does not remove the usual fine-tuning risks. Poor labels, leaked evaluation examples, narrow reward signals, and aggressive specialization can degrade useful general capabilities.
Limitations and who should use it
Inkling is a credible candidate for teams that need a customizable text-image-audio base, can evaluate models rigorously, and have either a Tinker workflow or access to substantial inference infrastructure. Agentic coding teams may value tool-schema robustness and controllable effort. Audio and visual-reasoning teams gain a single checkpoint rather than separate specialist models.
It is a weaker fit when:
a closed API already meets the quality target at lower operational complexity;
the deployment cannot support the hardware or provider cost;
a fully reproducible training dataset and pipeline are mandatory;
the application needs documented video input;
“open source” procurement rules conflict with the additional acceptable-use policy;
benchmark leadership matters more than customization.
The best evaluation is a workload-specific curve: quality versus total tokens, latency, price, human correction rate, and failure severity. Inkling’s controllable effort is useful only if those operating points are measured in the real application.
Inkling Model FAQ
Is the Inkling model open source?
Its full weights are downloadable and the Hugging Face repositories are labelled Apache 2.0, but use is also subject to Thinking Machines Lab’s Model Acceptable Use Policy. The training data and full training pipeline are not public. “Open weight” is the more precise term.
How large is Inkling?
Inkling has 975 billion total parameters and activates about 41 billion per token through a sparse Mixture-of-Experts architecture.
Does Inkling support a one-million-token context?
The native model supports up to 1M tokens. Tinker currently exposes 64K and 256K configurations, and third-party providers may have different limits.
What modalities does Inkling accept?
The model card documents text, images, and 16 kHz WAV audio as inputs and text as output. Video was included in pretraining data but is not a documented runtime input.
Can Inkling run locally?
Technically yes, but not on ordinary consumer hardware. Official minimums start around 600 GB aggregate VRAM for NVFP4 or 2 TB for BF16, before serving overhead.
Is Inkling-Small available?
Not as a full public checkpoint as of July 16, 2026. Thinking Machines Lab has published a 276B-total, 12B-active preview and says weights will follow after testing.
Bottom line
The Inkling model is best understood as a large, open-weight multimodal foundation for customization—not a claim to universal state of the art. Its 975B/41B-active MoE design, controllable effort, text-image-audio support, and Tinker integration create a flexible platform. Its value will depend on whether teams can reproduce the vendor’s strengths in their own harnesses while accepting the hardware, licensing, data-transparency, and evaluation constraints.
The best LLM for coding is not one permanent winner. Start with GPT-5.6 Sol or Claude Opus 4.8 for difficult, long-running changes; Claude Sonnet 5 for a balanced coding-agent default; Gemini 3.5 Flash for high-throughput, long-context work; and an open-weight model when deployment control matters more than turnkey convenience. Then test the shortlist on your own repositories.
This comparison covers model capability, context, API cost, deployment, and evidence—not editor features. Prices and availability were verified on July 15, 2026. Model aliases, previews, and introductory prices can change, so treat every figure as a dated snapshot.
Choose the complete coding system, not the largest isolated benchmark score.
What Makes an LLM Good at Coding
A good AI coding LLM does more than complete a function. It understands repository conventions, follows a multi-step plan, uses tools correctly, repairs failed attempts, and returns a patch a human can review. That makes five properties more useful than a single score:
Task fit: algorithm writing, repository repair, frontend work, migration, or review require different strengths.
Agent reliability: the model must select tools, interpret terminal output, preserve state, and recover from errors.
Context discipline: a large window helps only when the model finds the right evidence and resists irrelevant code.
Review quality: a passing test is not enough; the patch should be scoped, readable, secure, and maintainable.
Operational fit: latency, total task cost, data policy, availability, and deployment options determine whether a model works in production.
The model and the agent are separate entities. The model reasons and generates actions. The agent supplies prompts, tools, permissions, memory, retries, and an execution environment. For product-level workflow choices, compare Graphify’s best AI coding agents in 2026 and best AI coding CLIs.
Benchmarks That Actually Matter
No coding benchmark measures the whole job. Use each benchmark for the question it can answer:
End-to-end terminal workflows with published model-and-agent combinations
The model’s contribution separated from the agent scaffold
Benchmark metadata matters as much as the result. Record the task set and version, model snapshot, agent harness, tool policy, reasoning effort, attempt count, cost cap, and evaluation date. A vendor-reported run and an independent run should never share an unlabeled score column.
Extended context and coding quality depend on serving configuration
Context is the advertised maximum, not a guarantee of equal accuracy across every token. Prices exclude cache behavior, tool output, retries, hosting, and engineering time.
The Best Coding LLMs in 2026
Frontier Models to Verify
GPT-5.6 Sol is the strongest OpenAI candidate to test for complex GPT coding workflows. OpenAI calls it the flagship for complex reasoning and coding, with a 1.05M-token window and 128K maximum output. Its main buying risk is economics: the model costs $5 per million input tokens and $30 per million output tokens, and very long inputs carry a surcharge. GPT-5.6 Terra and Luna are lower-cost family options worth adding when Sol quality is unnecessary.
Claude Opus 4.8 is the premium Claude coding candidate for long-horizon agent work. Anthropic positions Opus for complex reasoning and agentic coding, while Claude Sonnet 5 targets a better speed-and-intelligence balance. Sonnet is the more practical default for repeated edit-test loops; Opus belongs on the escalation path for the hardest tasks. Measure both under the same effort setting because more reasoning can raise quality, latency, and cost together.
Gemini 3.5 Flash is the stable Google candidate for sustained agent and coding workloads. It combines a 1M-token input window with lower list prices than the premium models above. Gemini 3.1 Pro remains Preview, so it can join an exploration track for harder reasoning but should not silently replace a production default.
These are shortlist recommendations, not claims that one model beats every other model. Vendor benchmark results can suggest candidates, but only a controlled internal trial supports a purchasing decision.
Open-Weight Models to Verify
Open-weight models help when a team needs deployment control, offline evaluation, data locality, or custom serving. They are not automatically open source, inexpensive, or laptop-friendly.
DeepSeek V4 Pro and Flash offer 1M-token context, tool use, reasoning modes, and unusually low hosted prices. Official materials still label the V4 release Preview and link the open weights. Teams should use the current V4 IDs rather than building new integrations on deepseek-chat or deepseek-reasoner, which DeepSeek says will retire on July 24, 2026.
Mistral Medium 3.5 provides Modified MIT weights, a 256K context window, and a 128B dense architecture. It is a credible governed-deployment candidate, but “open weights” does not remove GPU, observability, security, or upgrade work.
Qwen3.6-35B-A3B uses an Apache 2.0 license, 35B total parameters, and 3B active parameters. Its model card lists 262,144 native context with an extended configuration beyond 1M. Test the exact quantization and serving stack you plan to deploy; model-card capability does not establish your throughput or total ownership cost.
Cost and Context Trade-Offs
Token price is not task price. A cheaper model can cost more if it retries commands, reads unnecessary files, generates long reasoning traces, or creates review-heavy patches. A premium model can be economical when it finishes a difficult migration in one accepted run.
Track total cost per accepted patch: input, cached input, output and thinking tokens, tool calls, failed runs, GPU time, and human review minutes. Also test a compact context policy against a “send everything” policy. Retrieval quality and context discipline often matter more than the advertised window.
How to Pick a Coding Model for Agents
Run a controlled trial with 8–12 representative tasks. Include a small bug, multi-file feature, test repair, dependency upgrade, refactor, and one task that should be refused or escalated.
Use this protocol:
Lock the same repository commit and acceptance tests for every model.
Fix the agent scaffold, system prompt, tools, permissions, and network policy.
Set the same reasoning level, retry limit, wall-time limit, and cost budget.
Run every model without letting one receive extra hints.
Review blinded patches for correctness, scope, security, clarity, and maintainability.
Record accepted-patch rate, review edits, failed commands, wall time, total cost, and security events.
Choose a default, a cheaper fast path, and an escalation model instead of forcing one model onto every task. If you want to test OpenAI’s coding surface specifically, start with Graphify’s Codex guide. Graphify’s broader AI coding research and comparisons can help map model findings back to tools and workflows.
A practical routing policy can start with three rules. Send small, well-tested edits to the fast path. Escalate broad migrations, ambiguous failures, and architecture work to the strongest approved model. Route sensitive repositories only to models and endpoints that satisfy the project’s data policy. The agent should record why it selected a route, and a developer should be able to override that choice without rewriting the task.
Do not promote a model on aggregate acceptance alone. Split results by task family and inspect the tail failures. A model that solves nine simple issues but corrupts the one migration may be worse for that workflow than a slower candidate with eight clean patches. Set explicit thresholds for correctness, security events, review edits, and cost. When no candidate clears every guardrail, keep the current default and narrow the proposed use case rather than averaging a dangerous failure away.
Finally, repeat a small portion of the suite. One run cannot reveal variance. Two or three attempts on the highest-value tasks show whether success is stable or depends on a lucky trajectory. Keep attempt count equal across candidates and report pass-at-one separately from pass-with-retries, because retries consume both money and engineering time.
Version Volatility and Limits
Model conclusions decay quickly. A provider can change an alias, retire an ID, alter pricing, expand context, or ship a new snapshot after this article is published. Preview endpoints carry extra stability risk, and even pinned snapshots can behave differently when the surrounding agent changes.
Maintain a model registry with provider, exact model ID, snapshot, status, context limit, price source, evaluation date, approved use cases, and rollback target. Re-run the internal suite before changing the default model or agent scaffold. Do not interpret a 1M-token window as 1M tokens of uniform recall, and do not mix results from different benchmark versions.
FAQ
What internal tasks should teams use for model trials?
Use 8–12 recent, representative tasks with objective acceptance criteria. Cover bug repair, feature work, tests, refactoring, dependency changes, repository search, and an unsafe or ambiguous request. Remove secrets and freeze each task to the same commit so every model receives equal evidence.
Who should approve changing the default coding model?
The engineering owner should approve capability and developer-workflow changes. Security or platform owners should approve data handling, permissions, network access, and hosted-versus-self-hosted deployment. Procurement or finance should review material cost changes. Production rollout needs a named rollback owner.
What records help compare model runs later?
Keep the exact model ID and snapshot, provider, agent and harness version, prompts, repository commit, tool policy, reasoning setting, attempt count, token usage, wall time, cost, command log, test results, reviewer edits, and final acceptance decision. Preserve sensitive logs under the same access and retention policy as source code.
Conclusion
The best coding model 2026 shortlist depends on the job. Test GPT-5.6 Sol and Claude Opus 4.8 for hard long-horizon work, Claude Sonnet 5 for a balanced default, Gemini 3.5 Flash for throughput, and DeepSeek, Mistral, or Qwen when open-weight control matters. The durable advantage is not picking today’s loudest benchmark winner. It is building a fair evaluation loop that can select—and safely replace—the model behind your coding agents.
