The Model Is Part of a System
For the Claude Code/Opus and Opencode/quantized-GLM comparison, the central problem is attribution: which observed difference belongs to the model, and which belongs to the agent, serving stack, or deployment boundary around it? Decomposing those interfaces helps a decision-maker interpret the evidence honestly and distinguish fast token generation from fast, reliable completion of a coding task.
A model does not meet a developer by itself. It arrives through an agent harness that decides what context to collect, which tools to expose, how edits are represented, when tests run, and how the conversation persists. It is then executed by a serving system with its own batching, caching, memory, and scheduling behavior. The organization also determines where code travels, who owns the state, and what happens when the service is overloaded or a deployment fails. These layers form the system that a developer experiences.
The two paths own different parts of the loop
The cloud configuration uses Claude Code as the local control surface and Claude Opus as the remote reasoning service. The client works with the local filesystem and shell, gathers file contents and command output, and sends the evolving context to the vendor endpoint. The vendor-managed service owns the model execution and server-side reuse of eligible prompt prefixes. The developer sees one terminal agent, but the inference boundary sits outside the corporate network.
The private configuration uses Opencode with GLM-5.1/5.2 served through vLLM on an internal Blackwell allocation. Opencode separates a server process from its terminal interface, persists session state locally, and accesses models through a provider abstraction. The serving engine owns the private model instance, its prefix cache, and its GPU allocation. Inference traffic remains inside the company’s network, but the organization now owns the reliability of the path from request admission to generated response.
The difference is not merely where the weights are stored. It is a difference in state ownership and decision-making. In the cloud path, the provider controls the inference service’s hardware, queueing policy, model rollout, and service-side cache behavior. The enterprise controls its local agent and the data it chooses to send, but must accept the provider’s endpoint and governance terms. In the private path, the enterprise controls the network boundary, model checkpoint, hardware allocation, and serving configuration. It must also operate the processes that preserve those properties under load, failure, upgrades, and multiple tenants.
The agent harness mediates both paths. It constructs the prompt, selects tools, submits edits, and reacts to compiler or test output. That makes the harness an active part of model behavior rather than a transparent pipe. Claude Code and Opencode use different runtime architectures and different approaches to provider profiles. The first is designed around a single vendor’s models; the second is designed to support heterogeneous providers. A vendor can co-tune tool schemas, system prompts, and edit formats with its own model. A provider-neutral harness gains flexibility, but has to adapt a model through a more generic interface.
That relationship can amplify capability in either direction. A model that understands a particular tool schema may complete a task with fewer interpretive steps. A generic adapter may make the same model portable but leave more ambiguity at the interface. These are plausible mechanisms for a performance difference, not proof that one harness alone caused the observed repair gap. The study deliberately treats the whole configuration as the unit of analysis because its naturalistic design does not run every model through every harness.
The boundary is also visible in failure handling. When a cloud request fails, the enterprise may be waiting on a vendor service, an API limit, or a remote model response; local hardware can remain healthy while the endpoint is unavailable. When a private request fails, the organization may need to diagnose the serving engine, memory allocation, network policy, checkpoint, or GPU capacity. A private deployment removes one external dependency while creating a larger internal ownership surface. Neither path has “no operations”; they place operations in different hands.
The architecture can be represented without treating the components as interchangeable.
The diagram’s important relationship is not the component count. It is the set of interfaces the agent crosses on every iteration: context leaves the local control surface or stays within it; model state is reused by a service-side or private cache; capacity is controlled externally or allocated internally; and test failures return to the agent loop regardless of where inference occurred.
Speed, capability, and completion are different properties
The measured configurations sit on a speed–quality trade-off. In the reported independent benchmark context, Opus 4.8 scored 56 on the Artificial Analysis Intelligence Index and 69.2% on SWE-bench Pro, while GLM-5.2 scored 51 and 62.1%. The local NVFP4 GLM deployment generated roughly 185 tokens per second under interactive single-tenant load, compared with about 66 tokens per second for hosted Opus 4.8. The local path therefore had a clear raw-generation advantage in that observation even as the frontier model held a higher reported capability score.
Those figures answer different questions. A benchmark score is an external measure of performance on a defined evaluation. Output tokens per second describe generation under a serving condition. Neither directly measures how many repository changes reach acceptance, how often a developer must intervene, or how long a task takes from scope to verified commit. A model can produce more tokens per second and still require more rounds of correction. A model can generate a longer explanation or rewrite more files without producing more durable logic.
The enterprise case makes the gap between raw output and usable progress visible. The local configuration’s higher Fix Commit Ratio was associated with more syntax and type repairs, more API or package misuse, and more logical defects. A representative type error was not a failure to produce code at all; it was a failure to preserve a response type across branches. Another example concerned an HTTP client inheriting proxy settings and routing an internal call incorrectly. Both changes could look plausible until static checks or runtime behavior exposed the mismatch. The cost appeared later, in a repair iteration and developer attention.
This is a feedback effect between layers. The model produces an answer. The harness applies it and invokes the repository’s tools. The serving system determines how quickly the answer arrives, but the repository’s compiler, tests, and runtime determine whether it is acceptable. If a generated change fails, the harness sends the failure back as new context. The model then has to interpret not only the original task but also the error. A small capability difference at the first step can become a larger delivery difference when the loop repeats.
Quantization belongs in this account, but the evidence does not justify assigning the entire quality gap to it. NVFP4 makes the large GLM checkpoint fit within an approximately 465 GB footprint on a four-B200 slice, with an FP8 key-value cache. That memory reduction is what makes the measured private serving arrangement practical. Quantization can also affect numerical fidelity, especially in complex reasoning, but the study did not run a controlled FP16 or FP8 GLM baseline. It therefore cannot separate degradation caused by quantization from the underlying capability difference between GLM and Opus, or from the harness and serving differences.
This is an important decision boundary. If a team interprets the result as “NVFP4 is the problem,” it may choose an expensive higher-precision deployment without knowing whether the repair burden would actually disappear. If it interprets the result as “the local model is inherently unreliable,” it may overlook improvements in model version, harness adaptation, validation, or routing. The measured object is the deployed bundle. A future controlled comparison could vary one layer at a time; this case study does not.
The context window illustrates a similar point. A large context capacity can prevent truncation, but it does not guarantee accurate use of repository-internal APIs or environment behavior. The reported local failures included incorrect interface assumptions even though the newer local checkpoint belonged to the same broad long-context class as the cloud model. More context can make more information available; it does not ensure that the model grounds every decision in that information.
Why raw generation speed can lose to the feedback loop
Suppose two configurations receive the same task. The faster decoder returns an initial answer sooner. That is a real benefit if the answer passes validation. If it fails, the total time includes the initial response, the test or compiler run, the developer’s diagnosis, the repair request, and another validation cycle. The sequence can repeat. In a multi-turn agent, the number of rounds is a multiplier on both model time and human review time.
The timestamp indicators in the enterprise study point in that direction. Under the local configuration, the longest uninterrupted repair run reached 58 commits instead of 18, and the median inter-commit interval increased from 5.9 to 12.7 minutes. The share of commits inside debugging spirals also rose from 35.0% to 69.8%. These values are not direct measurements of task completion time: agent and test-runner waiting, including unattended sessions, contribute to the intervals. They nevertheless show that the faster token generator did not produce a simpler visible work pattern in this deployment.
The distinction matters for capacity planning. A private cluster may generate tokens quickly while its users wait on additional review and repair. That extra work can reduce effective concurrency because developers, not GPUs, become the bottleneck. Conversely, a slower model may deliver better throughput at the level that matters to the team if it reaches accepted changes with fewer failed rounds. “Throughput” must therefore be labeled: tokens per second, requests per second, accepted changes per hour, and completed tasks per developer-day are different measures.
The same reasoning applies to latency. A private serving system’s raw decode speed does not fully determine when a new request produces its first token. Queue occupancy, prefill work, active decode sequences, batching, and memory state can delay admission. A cloud API may hide those mechanics behind a service boundary, but the developer still experiences their result as waiting. Later analysis can use live workload-aware routing to manage that state; at this layer, the key point is simply that speed is a property of the system under load, not a permanent label attached to the model.
The operational meaning of sovereignty
The private configuration’s strongest non-price advantage is its data boundary. Source code, schemas, logs, and request context can remain on the internal network instead of being sent to a third-party inference endpoint. That can simplify governance for proprietary assets, but it does not turn the private cluster into a trust-free zone. Shared GPU memory, host logs, and reusable key-value prefixes create internal separation requirements when more than one department uses the same serving resource.
The organization must therefore own controls at several boundaries: hardware isolation for tenant resources, network and container isolation for traffic, mutual authentication for connections, and developer-specific access tokens for authorization. The serving team also owns monitoring, capacity allocation, incident response, and model or checkpoint changes. The cloud provider owns much of the underlying service operation, but the enterprise still owns the decision to transmit data, the credentials used, and the compliance relationship with the provider.
The trade-off is not privacy versus no privacy or operations versus no operations. It is external dependency and data transfer versus internal control and internal responsibility. The system-level comparison keeps those obligations visible alongside capability and speed. A private deployment can be the right choice because sovereignty is worth the operating burden. It can also be the wrong choice if the organization cannot maintain isolation, capacity, and repair-quality controls. The model is only one part of that judgment.
The next measurement must therefore move from architecture to outcome. Once the system boundaries are clear, repository evidence can show whether one configuration produced more durable software or merely more activity—and whether the difference is large enough to change the economics of the decision.