ai-space/pxpipe
3
0
Fork 0
mirror of https://github.com/teamchong/pxpipe.git synced 2026-07-22 02:02:51 +02:00
Code Issues Packages Projects Releases Wiki Activity

dashboard: correct the docstring's renderer-width number

Browse Source 
Per the renderer-analyst's audit of src/core/render.ts, our renderer's
fixed width is `2*PAD_X + DEFAULT_COLS*ATLAS_CELL_W = 8 + 100*9 = 908px`,
NOT the 1466 the previous docstring claimed (which mistook Anthropic's
max image width for ours). True worst-case is 908×1568/750 ≈ 1898
tokens, a typical image at this workload is ~170 tokens (well under
what the byte-derived estimator computes already). No formula change —
`estImageTokens(pngBytes) = pngBytes/375` was always size-agnostic. This
is a comment-only fix so a future reader doesn't repeat the mistake.
This commit is contained in:
teamchong
2026-05-18 17:59:11 -04:00
parent b49764e64c
commit b6f2b65b9a
1 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/dashboard.ts
+6 -4
View File
@@ -85,10 +85,12 @@ function effectiveCost(
* if the baseline were warm-cache and savings look tiny.
*
* Uses `imageBytes` (actual PNG byte count) to estimate image tokens rather
* than `imageCount × 3066`. The old worst-case estimate assumed every image
* was 1466×1568, which our renderer never produces — typical images at this
* workload are ~1466×90px, so the worst-case overestimates by ~15× and the
* `extraText` clamp collapses to 0, hiding real savings.
* than `imageCount × 3066`. The old constant assumed every image was the
* worst-case 1466×1568 (Anthropic's max). Reality: our renderer's width is
* fixed at 2*PAD_X + DEFAULT_COLS*ATLAS_CELL_W = 908px, so even a full-height
* image is only 908×1568/750 ≈ 1898 tokens — and a typical image at this
* workload is closer to 908×~140px (~170 tokens). Worst-case overestimated
* by ~15×, the `extraText` clamp collapsed to 0, and real savings hid.
*/
function baselineCost(
actualEff: number,