[Bug]: Provider handoff fails with "Insufficient context allowance" when switching Antigravity instances after usage limit, wedging both

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Run a long conversation on a primary Google Antigravity provider instance (accumulating substantial turns/history).
Hit the provider usage limit ("Usage Limit Reached").
Switch provider in the thread to a second Antigravity provider instance/account to continue the task.
The run fails immediately with:
Provider error: Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.
Switch back to the original primary Antigravity provider instance.
The original provider instance also immediately fails with the exact same "Insufficient context allowance" error on every turn retry.

Expected behavior

Switching between Antigravity accounts/instances should calculate context allowance accurately, or automatically offer/execute conversation compaction prior to handoff.
If a handoff fails, it must not corrupt the thread state or permanently wedge the original provider instance from running.
A one-click "Compact context and retry" action should be presented rather than permanently bricking the thread across all provider instances.

Actual behavior

When switching to the second Antigravity instance after hitting a usage limit, the handoff fails immediately with:

Provider error: Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.

Furthermore, switching back to the original primary Antigravity instance does not restore functionality: every subsequent turn on the original provider fails with the identical unhandled error because the failed handoff attempt remains pending/unresolved. Both instances are now permanently wedged for this thread.

Impact

Blocks work completely

Version or commit

v0.0.46 / main (latest nightlies)

Environment

Linux x86_64, T3 Code Desktop, Provider: Google Antigravity (ACP) / Gemini 3.8 Flash (Medium)

Logs or stack traces

From statev2.sqlite orchestration turn items:

{
  "status": "failed",
  "title": "Provider error",
  "type": "error",
  "failure": {
    "class": "provider_error",
    "message": "Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.",
    "code": null,
    "retryable": null
  }
}


Orchestration state:
- Source provider: `antigravity` (hit usage limit)
- Target provider: `antigravity_antigravity_2` (failed handoff delivery due to `ContextHandoffBudgetError`)
- Returning to source provider: Still fails with the same handoff delivery budget error on subsequent turns.

Screenshots, recordings, or supporting files

No response

Workaround

No in-app recovery exists. Once the handoff fails, neither provider instance can execute turns on the thread. The only workaround is starting a brand new thread and manually retrieving prior context via t3_thread_read.

Additional reproduction with Pi, plus a compaction/quota error-reporting problem that appears related to this issue. No Antigravity account switch is needed in this reproduction.

Environment

T3 Code Desktop Nightly 0.0.46-nightly.20261005.2676, macOS
T3's provider settings UI reports Pi v1.0.0, with Authenticated · pi and the provider enabled, per a screenshot supplied after this report.
Version correction: the original report listed 0.87.1 from the local Homebrew Pi installation. That does not establish which executable/version T3 launched for the affected run. The historical run's actual runtime version has not been independently verified.
Provider instance pi, model openai/gpt-6.1-sol, full-access runtime
Evidence below is from the affected thread's durable activity and run records, not a fresh synthetic reproduction.

Observed sequence on 2026-10-05, UTC

Resuming a long Pi thread with continue fails immediately with:

Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.

A manual /compact starts at 14:06:53 and emits this failed compaction event at 14:09:02:

Compaction failed: Turn prefix summarization failed: The ChatGPT user has reached their Subscription Sharing usage limit. Ask the user to try again after their usage limit resets or use an API key instead.

Despite the failed compaction event, the enclosing /compact run is recorded as completed.
Further continue attempts at 14:09:08, 14:09:58, and 14:29:38 all fail with only the generic handoff-context error. The last attempt starts at 14:29:38.325 and fails at 14:29:38.387, about 62 ms later. There is no successful intervening compaction.

The thread is neither archived nor actively running, and has no pending user-input requests. Repeated resumes do not recover it.

Requested recovery and error behavior

When a legitimate handoff-budget shortage can be recovered by compacting the target native conversation, provide an explicit, bounded automatic-compaction recovery path before rejecting the ordinary turn. Show that compaction is happening, preserve the user's pending message, and honor provider capability/user compaction preferences.
If compaction is blocked by provider quota, report both facts, with the actionable blocker first: “Cannot resume: automatic compaction is blocked by your ChatGPT usage limit; context still requires compaction.”
Preserve the most recent relevant failed-compaction/quota information on subsequent retries rather than replacing it with the generic context error. Do not present historical quota exhaustion as definitely current forever; use a known reset/retry time when provided and allow an explicit bounded retry when it is unknown.
Do not report the manual compaction operation as successfully completed when its compaction event failed.
No silent paid-provider fallback, history deletion, or unbounded repeated quota requests.

Source triage

Current main has the generic budget rejection in apps/server/src/orchestration-v2/ContextHandoffDelivery.ts, deliverContextHandoffs / ContextHandoffBudgetError.

In apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts, the unsuccessful compaction_end branch emits a failed compaction item and schedules a settle probe, but does not itself assign turn.failure. The deferred compact response path also skips assigning a failure when sawCompaction is already true. This is a candidate explanation for the completed enclosing run; it should be covered by a regression test before treating it as the proven cause.

Related prior Pi report: #12931, closed as completed, and its duplicate #12929. That report diagnosed a timeout/self-handoff/context-window accounting problem. I have not established that the same underlying cause explains this thread, or that its native context genuinely exceeded the model window. The handoff allowance error by itself is not proof of native context exhaustion.

Suggested regression coverage:

Recoverable budget failure → one visible compaction → recompute allowance → resume original message.
Compaction quota failure → failed operation + actionable quota/context diagnostic; no success status.
Subsequent resume retains relevant recovery failure, with bounded retry behavior.
Incorrect window accounting or self-handoff is fixed at its source rather than masked by unnecessary compaction.

fix(server): a full target no longer fails every turn on a context ha…

@Pipyakas

the issue is still happening

Reproduction & Environment Verification

Following up on the triage request regarding reproduction on current nightly and Antigravity runtime details:

1. Environment & Versions

T3 Code Version: 0.1.2-nightly.20261021.3457 (Linux x86_64, AppImage)
Antigravity ACP Runtime Version: agy_acp_server_1.1.1
- Build ID: 61dd43a0-bfda-45ac-ac73-c3c35923da9f
- Runtime: Python 3.14.5 embedded (Blaze release 2026.08.18-1)
- Model: gemini-3.8-flash-medium

2. Sequence & Log Evidence (from durable thread state)

The wedging sequence occurred on thread 247d5ab5-5d36-465d-ab4c-47c1094a5070:

Ran on primary instance (antigravity) until reaching quota:
"Usage Limit Reached: You have reached your current quota for this period. Your limit will reset in 2 hours, 45 minutes."
Switched to secondary instance (antigravity_antigravity_2).
Switching back created handoff context-handoff:thread:247d5ab5...:from-provider-instance:antigravity_antigravity_2:to-provider-instance:antigravity:668c6d4c-0e13-4c72-b9a1-b026a9a97623 with 110 omitted items and 8 intact items.
When budget calculation returned 0 allowance, ContextHandoffBudgetError triggered:
Provider error: Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.
Because the failed handoff remained in ready status, every subsequent turn attempt on the thread failed immediately with the same unhandled budget error, permanently wedging both provider instances on the thread.

3. Verification of Recent Fixes

Verified commit 7e13143 by @Pipyakas (fix(server): a full target no longer fails every turn on a context handoff). Delivering the t3_thread_read recovery pointer when no history fits instead of throwing an unhandled budget failure directly resolves the permanent wedging loop.
Agree with @vineelsai26 that adding explicit automatic compaction before rejection or an in-app "compact and retry" button provides the cleanest user recovery path.

fix(server): a full target no longer fails every turn on a context ha…

Navigation Menu

Repository navigation

[Bug]: Provider handoff fails with "Insufficient context allowance" when switching Antigravity instances after usage limit, wedging both #15997

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Environment

Observed sequence on 2026-10-05, UTC

Requested recovery and error behavior

Source triage

Reproduction & Environment Verification

1. Environment & Versions

2. Sequence & Log Evidence (from durable thread state)

3. Verification of Recent Fixes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Provider handoff fails with "Insufficient context allowance" when switching Antigravity instances after usage limit, wedging both #15997

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

vineelsai26 commented on Oct 5, 2026

Environment

Observed sequence on 2026-10-05, UTC

Requested recovery and error behavior

Source triage

nathnael-desta commented on Oct 22, 2026

Reproduction & Environment Verification

1. Environment & Versions

2. Sequence & Log Evidence (from durable thread state)

3. Verification of Recent Fixes

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions