Cline SDK v0.0.90 Released: Major Performance Overhaul for Agent Teams

The open-source AI coding tool Cline has released SDK v0.0.90. The centerpiece of this update is a comprehensive fix for Agent Teams performance issues, alongside a refreshed model catalog and improved handling of standalone requests. For developers relying on multi-agent collaboration, this is a genuinely substantive engineering improvement.

From 1.66GB to Manageable: The Agent Teams Storage Collapse

In older versions, the longer an Agent Team ran and the more collaborating members it had, the slower the entire session became. The root cause was a design flaw: every streamed chunk and every heartbeat (sent every 2 seconds) triggered a full re-save of the entire team state.

This meant the system would repeatedly write out the complete conversation history of all finished members. The official release disclosed some alarming numbers — a local teams.db file had ballooned to 1.66 GB, with a single run row being rewritten approximately 339,000 times.

This design flaw may go unnoticed in small-scale tests, but in real-world long sessions with multiple agents, the constant full-disk writes quickly drag down performance, causing noticeable lag.

Agent Teams is a multi-agent collaborative architecture where multiple AI agents handle different subtasks and coordinate through shared state. In Cline's implementation, the team state includes each member agent's full conversation context, tool call records, and intermediate outputs — causing the state object to grow linearly over time. Streaming is the standard response mode for large language models, generating tokens incrementally and pushing them to the client in real time rather than waiting for the full response. In a multi-agent scenario, each member continuously produces streamed chunks, compounded by heartbeat signals every 2 seconds, resulting in a very high volume of concurrent write operations. SQLite, as a single-file embedded database, has inherent lock contention and page flush overhead for writes — under this pattern of high-frequency full rewrites, performance degrades sharply, ultimately manifesting as system-wide lag.

The v0.0.90 Fix

The new version systematically restructures the storage mechanism with a clear and pragmatic approach:

Separating Real-Time Data from Persistent Data

Streamed chunks and heartbeat data are now sent only to the live UI and are no longer written to the database. This high-frequency, ephemeral data never needed to be persisted in the first place — removing it significantly reduces I/O pressure.

Writing Only Changed Entities

Instead of full saves, the system now writes only the entities that have changed, batching those writes into a single transaction approximately every 300 milliseconds. Run records now store a summary rather than a full conversation transcript.

Batching multiple write operations into a single transaction is a classic database performance optimization technique, known as "batch commit" or "write coalescing." Each time SQLite commits a transaction, it must flush the WAL (Write-Ahead Log) to disk to ensure durability — this involves an fsync system call that can take several milliseconds on a spinning disk. If every streamed chunk triggers an independent commit, the dozens of writes per second accumulate significant disk I/O latency. By batching within a 300ms window, the number of commits in a given period drops from dozens to single digits, dramatically reducing I/O pressure. Saving summaries instead of full transcripts also fundamentally controls the growth of individual record size — an optimization across both space and time dimensions.

Database-Level Constraints and Migration

The team_events table now has explicit limits: a maximum of 2,000 rows per team, retained for 30 days. SQLite team storage has been upgraded to schema v2, with a one-time migration to compact existing data. Developers can also explicitly call SqliteTeamStore.vacuum() to reclaim freed disk space. Additionally, team data that fails to write will now be retried rather than silently dropped, improving data reliability.

The essence of these changes is transforming a coarse "always save everything" model into a fine-grained storage architecture that is incremental, batched, and bounded.

Standalone Requests and Model Catalog Updates

Beyond the core performance fix, v0.0.90 also addresses an edge case: standalone provider requests made outside of a session (such as generating a commit message) can now correctly resolve Cline's surface headers. Specifically, sessionId in resolveProviderRequestHeaders is now an optional parameter, and X-Task-ID is omitted when there is no value, rather than sending an empty string. These small details prevent request failures caused by empty fields.

The model catalog has also been refreshed, with default models changing for several providers: DigitalOcean switches to GPT-6.1 Sol, GMI Cloud moves to Qwen 3.8 Flash, NanoGPT updates to Pareto 26.10 Preview, Nvidia adopts DeepSeek^Ad V4.1 Flash, and Ofox also uses GPT-6.1 Sol. Keeping the model catalog current is routine maintenance for tools like this.

Surface headers are HTTP header fields Cline uses to identify the request's originating context — such as the current task ID (X-Task-ID) and session ID — which providers can use for routing, billing, or log attribution. In a normal session flow, these fields are automatically populated by the framework. But a "standalone request" is a one-off call made outside the session lifecycle — like auto-generating a git commit message — where there is no associated sessionId. In older code, requiring this field would cause request construction to fail or result in empty-value fields triggering server-side parsing errors. Making sessionId optional and omitting X-Task-ID when empty rather than passing an empty string is a more semantically correct approach to HTTP: a missing field and an empty field are not semantically equivalent, and many APIs strictly validate empty strings.

What This Means for Developers

As an open-source AI coding project with nearly 70,000 stars on GitHub, the stability of Cline's SDK directly affects a large number of downstream users. The signal from this update is clear: as AI agents evolve from single-agent to multi-agent collaboration, state management and storage design become the new performance bottleneck.

Case studies like a 1.66 GB database and a single row rewritten 339,000 times serve as a warning for any team building agent systems — in high-frequency streaming scenarios, a default "save everything" strategy is often catastrophic. Properly distinguishing between real-time state and persistent state, adopting incremental batch writes, and setting hard limits on historical data are engineering practices worth adopting.

Users actively using the Agent Teams feature are advised to upgrade as soon as possible. The migration will automatically compact existing data, and long-running sessions should see a noticeable performance improvement.