Cline SDK v0.0.93 Released: In-Process Plugin Loading and Reasoning Toggle Refactor

Cline, the AI coding tool, has released SDK version v0.0.93. On the surface this looks like a routine iteration, but in reality it makes several structural changes to plugin architecture, multi-model reasoning control, auto-compression strategy, and scheduled task dispatching—changes that matter a lot to developers building agents on top of the SDK.

Plugins No Longer Run in a Subprocess

The most notable change this time is the plugin loading mechanism. Previously plugins ran through a node/bun subprocess; the new version switches to in-process loading with one registry per process, and the compiled CLI and its hub no longer need a runtime prepared in PATH. At the same time, CLINE_PLUGIN_MODE=sandbox is retained to keep using the subprocess sandbox, leaving an escape hatch for scenarios requiring isolation.

The registry wraps timeouts and error capture around import, setup, hooks, tools, and commands, and tracks each plugin's status—loading, ready, degraded, failed, disabled—along with the last error. This point is critical: in the past, when a plugin errored, its tools silently disappeared; now failures surface as explicit signals. session.create accepts a plugins policy and returns pluginIssues; subsequent failures are pushed as status notifications to affected sessions; the hub provides plugins.list / plugins.status / plugins.reload interfaces and broadcasts plugin.status_changed; when an uncaught error originates from a plugin, the daemon marks that plugin as failed rather than exiting outright.

Each session gets its own copy of each plugin module, so plugins that maintain session-level state at the module level still work correctly. This design tradeoff solves the state pollution problem that in-process sharing would otherwise introduce.

In-process loading vs. subprocess sandbox: The subprocess isolation approach runs plugins in a separate node/bun process, achieving crash isolation, memory isolation, and restricted permissions; the cost is IPC communication overhead, process startup latency, harder debugging, and the host having to provide a runtime in PATH. In-process loading loads plugin modules directly into the main process and manages lifecycle uniformly through the registry—advantages include a shorter call chain, observable state, and simpler deployment; the downside is that if a plugin throws an uncaught exception or hangs, it could bring down the entire process. The new design therefore compensates for reduced isolation with "status tracking + timeout wrapping + failure marking," and retains the old mode via CLINE_PLUGIN_MODE=sandbox as a fallback so that strong-isolation scenarios can preserve their original behavior.

Registry and plugin lifecycle: The registry is the scheduling center of the plugin system, responsible for executing import (load module), setup (initialize), hooks (register event hooks), tools (register tools), and commands (register commands) in sequence, with timeout and error capture wrapped around each step. The plugin state machine loading → ready → degraded → failed → disabled lets the host distinguish semantics like "not yet ready," "partially unavailable capabilities," and "complete failure." degraded typically means some hooks or tools failed to register but the rest of the plugin is still usable; failed means critical initialization failed and its tools should no longer be called; disabled means the user or daemon actively deactivated it. Each session getting an independent copy of the plugin module means plugins can safely store session-level state at module scope without worrying about pollution from other sessions.

Disabling Reasoning Is No Longer Limited to a Whitelist

The reasoning toggle adjustment now has broader coverage. The old logic only applied to a fixed list; now it applies to all providers: models whose catalog entry has no off option are not sent any related parameters and retain default behavior; models without reasoning capability are skipped entirely. Gemini and Vertex only send exact thinkingBudget to models that declare support for budgets; Gemini models that only support level receive a thinking level (they reject thinkingBudget).

A request never carries both portable reasoning options and native provider control parameters (effort, thinking, thinkingConfig, etc.); when a conflict arises, native parameters take precedence. This kind of mutual exclusion handling reduces exceptions caused by parameter stacking in real calls.

Portability of reasoning parameters vs. conflict with native control: Different providers express "disable/adjust reasoning" very differently. Some use unified portable parameters (such as reasoning: false or a generic effort field), while others require native fields: OpenAI-style effort, Anthropic-style thinking, Gemini-style thinkingConfig. When both appear in one request, the provider may error, silently ignore, or behave unpredictably. The new strategy therefore stipulates mutual exclusion with native precedence—once native control parameters are explicitly used, no portable reasoning options are appended. This tradeoff lets developers write precise logic per provider capability while preserving a path for portable parameters in cross-provider general scenarios.

thinkingBudget vs. thinking level: Some Gemini and Vertex models use a "thinking budget" (thinkingBudget, expressed in tokens) to control internal reasoning length; others that only support level use discrete tiers (such as low/medium/high) to express thinking depth, and they reject the thinkingBudget parameter. The SDK needs to decide which parameter to send based on the model capability declaration in the catalog entry, and skip models that "don't support off" directly to avoid exceptions triggered by unrecognized parameters. This is a key constraint for multi-model routing layers: routing logic must carry model capability metadata, not just the model id.

Image Billing and Auto-Compression Fixes

estimateRequestInputTokens and createTokenEstimator no longer calculate base64 image payloads at text rates. Under the old logic, a roughly 90 KB screenshot would be counted as about 30k tokens, and a few images could trigger auto-compression long before the conversation got near budget—clearly disruptive for scenarios that paste images frequently. The new version adds a fixed ESTIMATED_TOKENS_PER_IMAGE (1600) per image and adds a new createImageAwareReplacer export in @cline/shared.

Auto-compression now uses the resolved model context window. When a discovered catalog entry has no limit but the selected model override does, the old code would hand the bare catalog entry to the compression logic, causing it to run against the wrong budget.

Base64 image payloads and token estimation error: In multimodal requests, images are usually embedded as base64-encoded strings whose character count is about 4/3 of the original bytes. If the estimator processes them at text token rates (about 4 characters ≈ 1 token), a 90 KB screenshot's base64 is about 120 KB, roughly 30k characters, and would be wrongly estimated at about 30k tokens. Real vision token consumption depends on resolution and the provider's chunking strategy, and is usually far lower. This deviation causes auto-compression to trigger long before the conversation nears the context window, hitting image-heavy sessions especially hard. The new approach uses a fixed constant ESTIMATED_TOKENS_PER_IMAGE = 1600 per image, trading some precision for stability and predictability, with createImageAwareReplacer uniformly replacing image content during compression.

Context window resolution and auto-compression budget: Auto-compression needs to know "the effective context window of the current model" to decide when to trigger. Model information comes from two sources: the catalog entry (which provides defaults for the model family) and the selected model override (which specifies stricter limits for a particular deployment or route). When the override has a limit but the catalog entry does not, the old logic would incorrectly hand the bare catalog entry to the compressor, making it run against an oversized budget until the request was rejected by the provider before compressing. The fix makes the compressor use the resolved effective window—override first, falling back to the catalog entry when missing.

Scheduled Tasks and Desktop Fixes

Under bun:sqlite, queued scheduled runs previously could not be correctly claimed—the stored named parameters were bound as NULL, so the desktop hub never claimed queued tasks and they silently stayed in pending state. This is now fixed. Agent turns that ended due to provider errors (such as a retired model id) are now recorded as failed with the error message preserved, rather than silently succeeding; run reports still retain usage and tool call records. Queued cron instances superseded by an updated occurrence in the same schedule are canceled, and backlogs no longer replay all missed slots at once.

Other fixes include: symlinked rule files are now loaded from the config directory instead of being skipped, and edits to the link target take effect on the next refresh or new session; resolveSkillsConfigSearchPaths scans .claude/skills, making skills written for Claude Code visible to Cline; the editor tool declares old_text as a plain string, avoiding cases where some models send null instead of replacement text (at runtime null is still accepted and treated as omitted).

Composio Connectors and Model Catalog Updates

Logged-in sessions now register Composio's meta-tools (search, manage connections, wait for connection, multi-execute), so agents can look up connector tools across toolkits, generate a Connect Link for apps the user hasn't connected yet, and execute the tools they find. Connector tools are discovered via meta-search, and saved desktop connection state no longer provides model tools. Hosts can provide their own auth through the new connectorsRequest option (ConnectorsRequest exported from @cline/core), which is also forwarded to scheduled sessions. resolveComposioToolsStatePath was renamed to resolveComposioConnectionStatePath.

The Cline cloud login helper in @cline/core accepts an AbortSignal, letting hosts cancel a pending login during polling. Cloud session refresh updates open sessions with titles renamed on the web side while preserving local renames made during the refresh.

The model catalog was refreshed from 6,572 to 6,862, adding three providers: AI/ML API, LowRouter, and Prime Inference. Since models.dev no longer lists v0, the v0 provider only carries the default model v0-1.5-md. OpenCode Go's base URL migrated from https://opencode.ai/zen/go/v1 to https://opencode.ai/inference/go/v1. Step 5 Preview was added to the Free list, and default models were adjusted for providers including 302.AI, CrossModel, Cortecs, DigitalOcean, NEAR AI Cloud, Ofox, DevPass, LLM Gateway, Meta, Aixy, CloudFerro Sherlock, Moark, Ambient, NanoGPT, Neuralwatt, and Novita AI.

Composio meta-tools and connection lifecycle: Composio is a platform that wraps third-party apps (such as GitHub, Slack, Notion) as callable tools. Its "meta-tools" are not the capabilities of any specific SaaS, but rather tools for operating the tool ecosystem itself: searching available connector tools, initiating OAuth connections, checking connection status, and chaining multiple tool calls within the same turn. This lets agents dynamically discover tools as needed and ask users to complete authorization (Connect Link) instead of enumerating all tools in advance. Credentials after a successful connection are hosted on Composio's side, and the host only needs to save connection state. The new connectorsRequest option lets hosts inject custom auth logic, enabling private connectors in enterprise environments to be used by agents, and it is forwarded to scheduled sessions so unattended background tasks can also access authorized connections.

Model catalog (models.dev) and provider abstraction: The model catalog is a centrally maintained source of model metadata, recording each model's context window, vision support, reasoning parameter form, billing standard, and so on; the SDK relies on it for routing, budgeting, and parameter decisions. The catalog grew from 6,572 to 6,862 entries, meaning about 290 new model entries, with new providers including AI/ML API, LowRouter, and Prime Inference. The provider is a unified abstraction layer that shields differences in authentication, endpoints, and parameter naming across vendor APIs; when a source stops being maintained (e.g., models.dev no longer lists v0), the catalog must fall back to a default model list, otherwise that provider cannot be parsed correctly.

What This Update Means

From the release notes, the focus of v0.0.93 is not new features but reliability. Moving plugins from subprocess to in-process, combined with status tracking and error isolation, effectively pushes the plugin ecosystem from "usable" toward "operable"; unified handling of reasoning parameters and the fix to image token billing are a cleanup of the multi-provider compatibility layer amid rapidly expanding model counts. For teams building on the Cline SDK, before upgrading they should watch out for whether their plugins depend on subprocess isolation and whether new events like plugin.status_changed will change existing error handling logic.

One-line Summary

Cline SDK v0.0.93 focuses on reliability, refactoring the plugin architecture and unifying multi-model reasoning and billing logic.

Paragraph Summary

Cline SDK v0.0.93 looks like a routine iteration, but actually makes structural changes to plugin architecture, multi-model reasoning control, auto-compression, and scheduled task dispatching. Plugins migrate from node/bun subprocesses to in-process single-registry loading, with timeouts, error capture, and loading/ready/degraded/failed/disabled status tracking so plugin failures no longer silently drop tools; CLINE_PLUGIN_MODE=sandbox preserves the old isolation mode. The reasoning toggle expands to all providers, with portable options and native control parameters mutually exclusive and native taking precedence. Images switch to a fixed 1600-token estimate per image, fixing the issue where a 90KB screenshot was counted as 30k tokens and wrongly triggered compression, and auto-compression now uses the resolved effective context window. It also fixes queued scheduled tasks that couldn't be claimed under bun:sqlite, provider errors recorded as success, and backlog cron replays, and updates the model catalog and Composio connectors.