builders · review · first seen Oct 26, 09:32 UTC

Cline SDK v0.2.0 reattaches active sessions

Cline SDK v0.2.0 shipped a change to how an active session is recovered, alongside changes to retries, Gemini search, and auto-compaction. Builders should check whether their session-start code assumes that starting again replaces a running session.

L0 · primary1 source5 claims checked4 min read

What shipped

Starting a session that already has a run in progress now reattaches to the live session instead of replacing its runtime. The release notes describe the old failure: the original run kept going but could no longer be reached, and its transcript writes landed on a stale snapshot. Reattachment addresses that specific recovery path. It does not make every kind of second start valid: a start that includes a prompt while a run is in progress is rejected. [1][2]

The release also changes how a session reaches clients that registered a capability. The hub records those clients, including one that joins a task already running, and sends each request to the first one still connected. If none remains, the request fails quickly with a message the user can act on rather than waiting indefinitely. This is relevant when a builder reattaches to a run and expects its client to participate in that live session. [1]

Model requests now retry at most 3 times after the first attempt, down from 5. A turn whose connection drops after the model has streamed only reasoning is retried, with that partial reasoning discarded. A turn that has produced text, media, or tool calls is still not retried. Failed attempts are recorded in Langfuse traces; cancelled requests are no longer reported there as errors. [1]

Two other shipped changes narrow behavior that a builder may have treated as automatic. The gemini provider no longer sends native Google Search, while Vertex keeps native search. Auto-compaction no longer runs when the model's input limit is unknown. Neither change is described as a new default that preserves the previous behavior across providers or models. [1][2]

Why it matters if you build

For a workflow that reconnects after losing its client, the distinction between reattaching and starting with a prompt matters. A prompt-free start against an active run reaches the live session; a start with a prompt is rejected. Review the code path that resumes work before treating the rejection as an intermittent failure. The old behavior could leave the run active but unreachable, so a successful start alone was not evidence that a client was attached to the run it expected. [1][2]

The retry change sets a lower ceiling on attempts after an initial model request fails. It also draws a useful boundary for connection loss: reasoning-only partial output can be discarded and retried, but output containing text, media, or tool calls cannot. Builders who inspect failures should distinguish those cases rather than assume that every interrupted turn is retried. Langfuse traces now include failed attempts, while cancellations no longer appear as errors, so the meaning of those trace entries has changed too. [1]

Provider and context-limit choices need a separate check. If a workflow depends on native Google Search through gemini, this release no longer sends it there; the stated exception is Vertex. If a model's input limit is unknown, the SDK no longer runs auto-compaction. The claims do not give a replacement search path or a substitute compaction rule, so neither should be assumed when deciding whether to use this release in an existing workflow. [1][2]

How to try it today

1. Start a session, leave its run in progress, then start that session again without a prompt. Check that the second client reattaches to the live run.
2. Repeat the start while the run is in progress, this time with a prompt. Handle the rejection explicitly.
3. Check the behavior of a registered capability client that joins an already-running task, then disconnect registered clients and inspect the resulting failure.
4. Inspect model-request failures and Langfuse traces against the new retry ceiling; distinguish a reasoning-only interrupted turn from one that emitted text, media, or tool calls.
5. Check workflows that rely on native search through gemini or auto-compaction with an unknown model input limit before using the release there.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Cline SDK v0.2.0 reattaches to a live session when a run is already in progress.

   per GitHub releases · cline/cline (L0)
2. shipped L0 · primary

   Starting a session with a prompt while a run is in progress is rejected.

   per GitHub releases · cline/cline (L0)
3. shipped L0 · primary

   Model requests retry at most 3 times after the first attempt, down from 5.

   per GitHub releases · cline/cline (L0)
4. shipped L0 · primary

   The gemini provider no longer sends native Google Search; Vertex keeps native search.

   per GitHub releases · cline/cline (L0)
5. shipped L0 · primary

   Auto-compaction no longer runs when the model's input limit is unknown.

   per GitHub releases · cline/cline (L0)

What is not confirmed

The supplied claims do not establish how often reattachment or retry failures occur in practice, or what a particular workload will cost under the lower retry ceiling. They also do not establish an alternative native-search path for gemini or what happens to a workflow that reaches an unknown input limit without auto-compaction. Test those cases rather than treating the release notes as measurements or migration instructions. [1][2][3][4]

Who should act, who should wait

Move now if an active run can outlive its client and your recovery code needs to regain that run: reattachment directly addresses the unreachable-run behavior described in the release notes. Update that path to avoid supplying a prompt during an active run. Wait on an untested switch if your workflow requires native Google Search through gemini or relies on auto-compaction when the input limit is unknown; the shipped behavior removes those assumptions. [1][2][3][4]

Sources

• SDK v0.2.0 — GitHub releases · cline/cline L0 · primary