vvzvlad/gitmost
1
0
Fork 0
Code Issues 27 Pull Requests 16 Packages Projects Releases Activity

AI-chat: реактивная рекавери недостаточно агрессивна при незаданном окне и реальном малом контексте (<50k) — остаточный кирпич #520

New Issue
Open
opened 2026-07-11 23:42:34 +03:00 by agent_coder · 0 comments
agent_coder commented 2026-07-11 23:42:34 +03:00
Collaborator
Copy Link
Copy Source

Контекст

В #490 (PR #510) добавлен токен-бюджет реплея истории + реактивная ветка. При переполнении контекстного окна провайдер отдаёт 400, ход штампуется metadata.replayOverflow, и СЛЕДУЮЩИЙ ход режется агрессивно — floor(0.5 × threshold) (resolveEffectiveReplayThreshold).

По решению владельца (эскалация, Option A) при ЗАДАННОМ chatContextWindow бюджет = floor(0.7 × window) без капа; при НЕЗАДАННОМ — плоский фолбэк 100k.

Проблема

Агрессивная рекавери — это фиксированная доля 0.5× от базового бюджета. Она НЕ учитывает реальное окно модели, когда:

  1. chatContextWindow НЕ задан → базовый бюджет = плоские 100k;
  2. реальное окно модели маленькое (например < 50k токенов).

Тогда даже агрессивный ход даёт порог 0.5 × 100k = 50k, что ВСЁ ЕЩЁ больше реального окна модели. Провайдер снова отдаёт 400, ход снова штампуется replayOverflow, но priorOverflowed уже был true — второго ужесточения нет (фракция не эскалирует итеративно). Результат: остаточный кирпич — чат не восстанавливается, повторяя 0.5×100k=50k каждый ход.

Возможные направления (на обсуждение)

  • Итеративная эскалация: считать число подряд идущих replayOverflow-ходов и умножать фракцию (0.5^k) либо резать до абсолютного минимума.
  • Выводить/уточнять реальное окно модели из тела 400 (провайдеры часто сообщают maximum context length is N) и брать min(бюджет, N·0.7).
  • Уменьшить плоский фолбэк или сделать его адаптивным по последнему известному contextTokens.

Ссылки

Отмечено при ревью-фиксе #510: DO #1 (тест агрессивной рекавери) проходит для номинального случая, но фиксированная доля не эскалирует в описанном сценарии.

## Контекст В #490 (PR #510) добавлен токен-бюджет реплея истории + реактивная ветка. При переполнении контекстного окна провайдер отдаёт 400, ход штампуется `metadata.replayOverflow`, и СЛЕДУЮЩИЙ ход режется агрессивно — `floor(0.5 × threshold)` (`resolveEffectiveReplayThreshold`). По решению владельца (эскалация, Option A) при ЗАДАННОМ `chatContextWindow` бюджет = `floor(0.7 × window)` без капа; при НЕЗАДАННОМ — плоский фолбэк 100k. ## Проблема Агрессивная рекавери — это фиксированная доля `0.5×` от базового бюджета. Она НЕ учитывает реальное окно модели, когда: 1. `chatContextWindow` НЕ задан → базовый бюджет = плоские 100k; 2. реальное окно модели маленькое (например < 50k токенов). Тогда даже агрессивный ход даёт порог `0.5 × 100k = 50k`, что ВСЁ ЕЩЁ больше реального окна модели. Провайдер снова отдаёт 400, ход снова штампуется `replayOverflow`, но `priorOverflowed` уже был true — второго ужесточения нет (фракция не эскалирует итеративно). Результат: остаточный кирпич — чат не восстанавливается, повторяя 0.5×100k=50k каждый ход. ## Возможные направления (на обсуждение) - Итеративная эскалация: считать число подряд идущих `replayOverflow`-ходов и умножать фракцию (`0.5^k`) либо резать до абсолютного минимума. - Выводить/уточнять реальное окно модели из тела 400 (провайдеры часто сообщают `maximum context length is N`) и брать min(бюджет, N·0.7). - Уменьшить плоский фолбэк или сделать его адаптивным по последнему известному `contextTokens`. ## Ссылки - Родительская задача: #490 - PR: #510 - Связано с обсуждением реактивной ветки в #497 Отмечено при ревью-фиксе #510: DO #1 (тест агрессивной рекавери) проходит для номинального случая, но фиксированная доля не эскалирует в описанном сценарии.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
epic
Large multi-phase effort spanning many changes
 needs-human
эскалация: нужно решение человека
 review/approved
в последнем ревью нет открытых blocking-находок
 review/changes-requested
последнее ревью оставило открытые blocking-находки
 review/needs
head не ревьюился (head != reviewed_head)
 возможно, баг
Похоже на баг, но требует подтверждения/воспроизведения; чиним, если повторится
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent_coder agent_qa agent_reviewer agent_vscode vvzvlad
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vvzvlad/gitmost#520
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?