Cline SDK v0.0.90 リリースCline SDK v0.0.90
匿名の公開いいねです。記事の保存・お気に入りではなく、Featured、Top 3、重要度、掲載順位には影響しません。仕組みとプライバシーAnonymous public likes are reactions, not saved articles or bookmarks. They do not affect Featured, Top 3, importance, or listing order.How it works and privacy
- Cline SDK v0.0.90は、チーム保存をSQLiteスキーマv2へ移行し、配信断片とハートビートの永続化を廃止しました。
- 変更分のみを約300ミリ秒ごとに一括保存し、長時間のエージェントチーム実行を高速化します。
Cline SDK v0.0.90 moves team storage to SQLite schema v2, stops persisting stream chunks and heartbeats, and batches changed entities, keeping long agent-team runs fast.
本ページの本文と要約は AI による自動生成です。日本語版と英語版は言語ごとに独立して生成されるため、表現や詳しさが異なる場合があります。正確性は元記事 (github.com) をご確認ください。The body and summaries are AI-generated independently for each language, so wording and detail may differ. Verify accuracy at the original source (github.com).
要約と収集メタデータに基づく AI 解説。元記事全文の転載・翻訳ではありません。AI explainer based on the summaries and collected metadata, not a copy or translation of the full source article.
SDK v0.0.90
Cline SDK v0.0.90では、エージェントチームの保存処理が改められ、セッションの継続中やチームメイトのストリーミング中に処理が遅くなる問題へ対処した。長時間のチーム実行でも速度を維持するため、保存対象と書き込み方法が変更されている。
チーム保存
従来は、ストリームの断片が届くたびに加え、2秒ごとのハートビートでもチーム状態全体を保存し直していた。この状態には、処理を終えた各チームメイトの完全なトランスクリプトも含まれていた。実例では、ローカルのteams.dbが1.66GBに達し、単一の実行行が約33万9000回も書き換えられていたという。
新しい方式では、ストリームの断片とハートビートは稼働中のUIにのみ送られ、永続化されない。実行レコードにもトランスクリプトそのものではなく、要約が保持される。
変更分の一括保存
保存時には、チーム状態全体ではなく、変更されたエンティティだけが書き込まれる。書き込みは約300ミリ秒ごとにまとめられ、1つのトランザクションとして処理される。また、失敗したチーム書き込みは破棄されず、再試行される。
team_eventsにはチーム単位の上限も設けられた。保持範囲は2000行、30日間に制限され、イベントが際限なく蓄積する構造ではなくなった。
SQLiteスキーマv2
SQLiteのチームストレージはスキーマv2へ移行する。移行時には一度限りのマイグレーションが実行され、既存データが圧縮される。さらに、SqliteTeamStore.vacuum()を明示的に呼び出すと、解放された容量が返される。
Agent Teams
Cline SDK v0.0.90 changes how agent-team state is stored so teams no longer slow down as a session continues or while a teammate is streaming. The release focuses on reducing repeated writes during long agent-team runs.
Previously, every streamed chunk and each 2-second heartbeat caused the entire team state to be saved again. That state included the full transcript of every teammate that had already finished. In one local case, teams.db reached 1.66 GB, while a single run row was rewritten approximately 339,000 times.
Stream Chunks and Heartbeats
Stream chunks and heartbeats are now sent only to live user interfaces and are never persisted. This removes the repeated storage work previously triggered by streaming activity and regular heartbeat updates.
Run records also retain a summary rather than the transcript. In addition, team_events storage is capped for each team at 2,000 rows and 30 days, limiting how much event data remains in team storage.
Changed Entities
Instead of re-saving the whole team state, the SDK now writes only entities that have changed. Those changes are batched into a single transaction approximately every 300 milliseconds.
This approach directly reduces the number and size of database writes during a session. Failed team writes are retried rather than dropped, so the revised write path also changes how unsuccessful persistence attempts are handled.
SQLite Schema v2
SQLite team storage moves to schema v2. Existing data is handled through a one-time migration that compacts the stored information.
The release also provides SqliteTeamStore.vacuum(). When called explicitly, this operation returns the amount of space it freed. Together, the schema migration, compacted data, bounded team events, summary-based run records, and batched changed-entity writes are intended to keep long-running agent teams fast.