You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "Astro-Han (via GitHub)" <gi...@apache.org> on 2026/09/01 15:37:31 UTC

[PR] fix(runtime): price artifact media inside the context budget [maka]

Astro-Han opened a new pull request, #4486:
URL: https://github.com/apache/maka/pull/4486

   ## Summary
   
   An image Tool Result is a one-line reference on the ledger and real bytes in the provider request. Every sizing site measured the former, so a screenshot cost ~0 tokens: compaction was never triggered by images, the prune never selected them, and a request could go far over the window while the budget reported room to spare. That is the mechanism behind the failure in #4458 — the escape hatch and the gate that fired were measuring different objects.
   
   #4283 unified four consumers on the effective projection, but "what the model sees" and "how large the request is" only coincide for text; the artifact reference is exactly where they diverge. This adds the missing half:
   
   - `effectiveToolResultMedia` is the one answer to what a Tool Result rehydrates into, covering both artifact parts and the pre-artifact image results the decoder still hands to materialization raw.
   - Media cost is a flat per-modality constant. No character count can answer it — providers price an image by its resized tile area — and it stays independent of the selected model, because sizing may not read the model and over-counting only triggers compaction, which is reversible. Peers do the same for the same reason (gemini-cli bills a flat 3000 per image; codex ~1844 for a resized one).
   - It is carried in tokens rather than folded into the char count: `charsPerToken` calibrates text, so scaling media by it would make an image cheaper on a session with a low text ratio.
   - Reactive overflow recovery reads that same decode instead of the raw execution fact — the fifth consumer #4348 did not reach — and, when the provider reported the rejected request's size, drops the largest images only until that overshoot is covered instead of every image in the history at once.
   
   No schema change: `mediaType` and `ref` are already on the artifact part, so the cost is derived, not stored.
   
   Refs #4458, #4283
   
   ## Verification
   
   - `npm run test:dist -w @maka/runtime` — 3135 pass, 0 fail, 13 skipped.
   - `npm run format` and `npm run lint` — clean.
   - `npx tsc --noEmit -p packages/runtime/tsconfig.json` — clean.
   
   New coverage, each failing without the change:
   
   - `effective-history-compaction.test.ts` — budgeting prices an artifact projection above the equivalent text projection.
   - `provider-image-overflow-recovery.test.ts` — an image artifact is priced by its materialized cost; a pre-artifact image with no durable projection is still recovered; omission drops the largest images only until the overshoot is covered.
   
   Not run: the full-repo suite.
   
   ## Review focus
   
   The constant is deliberately coarse and model-independent. It over-counts a small image and under-counts a very large one; both directions only move the compaction trigger, never a turn's outcome. If that trade is wrong, the argument to make is about where sizing is allowed to read the model, not about the number.
   
   Out of scope, and still open on #4283: `midTurnRequestPayloadChars` remains a second sizing authority measuring `JSON.stringify(messages)`.
   
   ## AI use
   
   - [ ] No generative tool made a substantive contribution
   - [x] Generative tooling made a substantive contribution
   
   Tool(s) and scope: Claude Code — mechanism analysis, implementation, and tests, reviewed and verified by the author.
   
   ## Checklist
   
   - [x] Tests cover the change and fail without it
   - [x] Lint, format, typecheck and the affected suites pass locally
   
   Does this PR entail a change in behavior?
   
   - [x] Yes — described under Summary above
   - [ ] No
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [PR] fix(runtime): let the provider decide fit, anchor estimates on real usage, retire the local verdict [maka]

Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han merged PR #4486:
URL: https://github.com/apache/maka/pull/4486


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [PR] fix(runtime): let the provider decide fit, anchor estimates on real usage, retire the local verdict [maka]

Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on PR #4486:
URL: https://github.com/apache/maka/pull/4486#issuecomment-5506393180

   Thank you for such a careful read, and for taking the delta on faith after seeing the implementation. All three notes and the count are in `5b339b2ca5`:
   
   1. **Docs** — the three passages in the compaction draft (both languages) now describe what is on the branch: capacity is the declared window or nothing, an estimate only asks for a compaction, and a rejected request is compacted, retried once, then reported as `context_overflow`. Good catch; I had written those off as historical drafts.
   2. **Downgrade note** — added to `CHANGELOG.md` under 0.2.0: sessions this build writes do not open in earlier releases because of the `lastRequestAnchor` key, downgrading needs a `runtime.sqlite` copy taken beforehand, `context_budget_exhausted` is retired, epoch 94.
   3. **Two constants** — I went with putting the intent in code rather than tying the numbers together: a Tool Result carrying media is always a stale-archive candidate, and `maxResultEstimatedTokens` decides text-only results alone. Two tests pin it (a single image with a two-character reference is collected; 1,000 tokens of plain text is not). The identical comparison in `active-tool-result-prune` is left as is: that path never sees a `type: 'content'` image result, which is a separate gap.
   4. Description corrected to twenty-one, with the two usage-accounting tests named. Thanks for counting.
   
   One small thing worth flagging so it does not trip up PR-3: with an undeclared window `maxHistoryEstimatedTokens` is still there rather than absent. `defaultHistoryBudgetTokens` returns 32,000 for providers other than DeepSeek, and the pre-turn gate uses it as a shaping threshold when no anchor is available. It can only ask for a compaction, never end a turn, which is why I left it alone for now; the PR description says so as well. When PR-3 replaces the count-bounded tail with a token bound, that constant looks like a natural thing to retire in the same pass, if you agree.
   
   Looking forward to PR-3.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [PR] fix(runtime): let the provider decide fit, anchor estimates on real usage, retire the local verdict [maka]

Posted by "hqhq1025 (via GitHub)" <gi...@apache.org>.
hqhq1025 commented on code in PR #4486:
URL: https://github.com/apache/maka/pull/4486#discussion_r3912024256


##########
packages/runtime/src/tool-result-archive-transition.ts:
##########
@@ -289,8 +293,17 @@ export function collectStaleToolResultArchiveCandidates(
     if (!sourceProjection) continue;
     const serializedResult = serializedToolResultProjection(sourceProjection);
     const originalBytes = utf8ByteLength(serializedResult);
-    const originalEstimatedTokens = estimateTokens(serializedResult.length, charsPerToken);
-    if (originalEstimatedTokens <= maxResultEstimatedTokens) continue;
+    const media = projectionArtifactMedia(sourceProjection);
+    // An artifact serializes to a short reference and materializes to real
+    // image bytes, so the string alone would price a screenshot at nothing.
+    const originalEstimatedTokens =
+      estimateTokens(serializedResult.length, charsPerToken) +
+      media.length * MATERIALIZED_IMAGE_TOKENS;
+    // A result that carries media is always a candidate: archiving it drops
+    // whole images from the request, which is worth doing whatever the
+    // reference text around them happens to weigh. The size gate is there to
+    // spare small text results, so it only decides those.
+    if (media.length === 0 && originalEstimatedTokens <= maxResultEstimatedTokens) continue;

Review Comment:
   **P3 — Update the exported policy contract for the new threshold semantics.** This condition deliberately makes every media-bearing result eligible regardless of `maxResultEstimatedTokens`, but `StaleToolResultPrunePolicy.maxResultEstimatedTokens` still says that “Tool result payloads above this estimate are replaced” (`tool-result-archive.ts:30`). A caller reading the exported policy can still expect a small image result below the threshold to stay full. Please document that the threshold applies only to text-only results and that media is always eligible after `minRecentTurnsFull`.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org