Cline SDK v0.0.95 Update: GPT-6 Compatibility Fix and Hub Telemetry Identity

A "small but critical" SDK iteration

Cline has released SDK v0.0.95. Judging by the version number, this is a routine iteration, but the changes touch several real-world pain points: parameter adaptation for OpenAI-compatible requests, telemetry attribution for the Hub daemon, and a major refresh of the model catalog. For developers relying on Cline to build AI coding workflows, the value of this update isn't in new features—it's in "making requests that would have failed no longer fail."

According to the GitHub Release page, this update was auto-published by github-actions, with commit hash c718573. The full changelog can be viewed between sdk/sdk/v0.0.94...sdk/sdk/v0.0.95.

Core fix: parameter name switch for the GPT-6 series

The most notable change is the parameter handling logic for OpenAI-compatible requests. For gpt-6-sol, gpt-6.1-sol, gpt-6-1-sol, and subsequent model IDs from gpt-5 through gpt-9, the SDK now sends max_completion_tokens instead of max_tokens. The original text explicitly states that the purpose of this change is to stop OpenAI and Azure from rejecting these requests—in other words, before this change, requests targeting the new model IDs could be rejected outright by the gateway due to a parameter name mismatch.

Interestingly, there's the edge case handling: Azure's gpt-35-turbo still retains max_tokens. This means the SDK doesn't crudely replace the parameter name globally, but distinguishes by model family. This level of precision is critical in cross-cloud compatibility layers, because OpenAI and Azure have historically behaved inconsistently with respect to the same parameter, and a one-size-fits-all approach often introduces regressions.

max_tokens and max_completion_tokens are two parameters in the OpenAI Chat Completions API with similar semantics but different purposes. max_tokens is the earlier field, used to limit the total number of tokens the model generates (including both reasoning process and visible output); OpenAI introduced max_completion_tokens in the o1 series and later reasoning models, specifically to constrain the token upper limit for the entire completion, and gradually recommends that new models use the latter. Azure OpenAI's parameter support cadence is not synchronized with the OpenAI main site, and some older deployments (such as gpt-35-turbo) still only accept max_tokens. Therefore, the compatibility layer must route by model family, otherwise requests will be rejected by the gateway with a 400.

Hub daemon learns to "remember" its launcher

Client identity added to telemetry resource attributes

The Hub daemon will now record which client launched it, specifically through the three fields CLINE_HUB_LAUNCHER_CLIENT, CLINE_HUB_LAUNCHER_VERSION, and CLINE_HUB_LAUNCHER_TRANSPORT, and publish this information as OTel (OpenTelemetry) resource attributes. SSH remote Hub reports the local client, with the transport field set to ssh.

This directly helps with troubleshooting in multi-client, multi-environment scenarios. Previously, in the Hub daemon's telemetry data, it was difficult to distinguish which client version triggered a given behavior and through which transport method; now this information is part of the resource attributes, making the observability chain more complete.

In OpenTelemetry, "Resource Attributes" are used to describe the entity itself that produces telemetry data—such as service name, host, deployment environment, etc.—and are attached to all traces, metrics, and logs exported by that process, as distinct from span attributes that describe a single operation. Writing the launcher client, version, and transport method into resource attributes means that no matter which trace is queried later, it can be directly filtered and aggregated by client dimension without needing to repeatedly tag each span. For components like daemons that are reused by multiple upstream clients, this is the standard approach for attribution analysis.

Three new utility functions added to the shared package

To support the above capability, the @cline/shared package adds three functions: withHubLauncherIdentity, claimHubLauncherIdentity, and readHubLauncherIdentity. From their names, their responsibilities can be inferred: reading, claiming, and wrapping the launcher identity. Meanwhile, the telemetry self-check report adds a traces_exporter field to help confirm whether the trace export configuration is in effect.

This kind of "read—claim—wrap" three-part API typically corresponds to a context-passing pattern: claimHubLauncherIdentity writes the identity into process-level state early during startup, readHubLauncherIdentity is used by telemetry initialization to read it, and withHubLauncherIdentity temporarily injects the identity at call boundaries as a higher-order function, avoiding global state pollution. The reason it's placed in @cline/shared rather than inside the Hub package is to let different launchers such as CLI and IDE plugins reuse the same convention and ensure consistent reporting fields.

Model catalog refresh and recommended default changes

The model catalog has expanded from 6,952 to 7,041 entries, and two new providers have been added: CommandCode and Reflection.

On the recommendation list, Cline's top recommendation has returned to Claude Sonnet 5.5, so the cline provider's bundled default model has switched back from Gemini 4 Argon to Claude Sonnet 5.5. This change is worth noting: changes to the default model directly affect new users' first experience, and also reflect a shift in the team's judgment about the ranking of model capabilities.

Other providers' default models have also changed: 302.AI to Gemini 4 Argon, Eden AI and Prime Inference to Muse Spark Open, CoreWeave to Reflection Beam 1.0, NanoGPT and Pioneer have corresponding adjustments (Pioneer pointing to Nemotron 3.5 Super VL), and Scaleway to DeepSeek^Ad V4.1 Flash.

There's another easily overlooked detail that can cause failures: OpenCode Go retains the base URL https://opencode.ai/inference/go/v1 and pins it, because models.dev migrated the provider-level URL to an OpenAI-only path. Without pinning, requests would hit an incompatible endpoint.

models.dev is a community-maintained model metadata catalog that provides model lists, context windows, pricing, and base URLs for various providers, and is used by multiple AI coding tools as a data source for their model catalogs. When upstream uniformly migrates provider-level URLs to OpenAI-protocol-only paths, downstream tools that rely on this catalog and pass them through directly will send requests to mismatched endpoints. Therefore, pinning the correct base URL locally is essentially adding a layer of stability protection between upstream metadata changes and end requests.

What this update tells us

The maintenance cost of compatibility layers is underestimated

From parameter name differentiation, to adjusting provider defaults one by one, to pinning base URLs, this release is almost entirely compatibility work. The competitiveness of AI coding tools depends largely on whether this kind of "invisible" adaptation is timely—users don't perceive it, but when it's missing, it manifests as "a certain model suddenly stops working."

Telemetry attribution is becoming standard infrastructure

Writing launcher identity into OTel resource attributes is essentially making observability data carry its own context. For AI coding scenarios where multiple clients and multiple transport methods coexist, this has more long-term value than any new user-facing feature.

Upgrade recommendations

If you're using the Cline SDK and calling new model IDs through OpenAI or Azure, you should upgrade as soon as possible to avoid parameter rejection issues. If your workflow involves SSH remote Hub or requires cross-client behavior analysis, the telemetry changes are also worth noting. Before upgrading, it's recommended to check the Full Changelog against default model changes to avoid behavioral differences caused by default value switches.

One-line Summary

Cline SDK v0.0.95 focuses on fixing OpenAI/Azure parameter compatibility, Hub telemetry attribution, and the model catalog.

Paragraph Summary

Cline has released SDK v0.0.95. Although the version number is small, the changes focus on real-world failure points. The core fix is parameter routing for OpenAI-compatible requests: new model IDs such as gpt-6-sol and the gpt-5 through gpt-9 series now use max_completion_tokens to avoid rejection by OpenAI and Azure gateways, while Azure's gpt-35-turbo still retains max_tokens. The Hub daemon now records launcher identity, writing it into OTel resource attributes through three environment variables; SSH remote Hub reports transport as ssh, and @cline/shared adds three accompanying identity-handling functions. The model catalog has expanded from 6,952 to 7,041 entries with two new providers, the cline default model has switched back from Gemini 4 Argon to Claude Sonnet 5.5, default values for multiple providers have been adjusted accordingly, and OpenCode Go's base URL has been pinned to prevent endpoint incompatibility.