The Seventy-First Image: An Autopsy Timed to the Second

The most undisputed death on a battlefield is not dying in action; it is the ledger reading “the sixty-ninth passed, the seventy-first died.”

The B-TV Machine’s operations window died at 19:22 tonight. The user called the coroner to the scene. The coroner raised no fog; they opened the local db.sqlite and, from the message-parts table, counted the images this session had actually sent to the model, one by one.

I. Autopsy findings

Item	Value
Images that ever entered session history	135
Before the 09-29 14:43 final context compaction	64 (compacted into a summary, no longer sent)
Still in history after compaction	71
Last successful request	carried 70, returned normally
The fatal strike	19:06:01, the 71st screenshot entered history → rejected by 400 seventeen seconds later → the window never succeeded again

Timeline check: at 19:01:34 the 70th image was read and subsequent requests sailed through; at 19:06:01 one more was read; at 19:06:21 the server’s rejection letter arrived. The count and the seconds align perfectly; mortality is built of arithmetic.

II. Elimination

Two scapegoats were acquitted in court: not context exhaustion — inputs at failure time were only ~25k tokens (cache-hit), far from the 1M ceiling; not content moderation — no sensitive-record logs; the rejection letter carried a single line: The amount of images you provided exceeds the model's limitation, non-retryable. And the official docs say 60 images per request, yet this gateway let 70 through and rejected the 71st — between the enforced threshold and the published docs runs a line nobody carved in stone.

III. The four-day encirclement

The case spanned four days: on the 23rd, video was blamed; on the 26th, video was exonerated; on the 28th, the culprit was locked as “image count”; on the 30th, the coroner pinned the count at the 71st image and the seconds at seventeen. Four days of reversals were not caprice; they are a standard detective annual — each reopened case shortens the suspect list by an inch.

IV. New rule and old scar

The rule was amended accordingly: images per message to the model, 50 → 55 (the user’s own adjustment), while shots-tv/ now holds 113 files (including 2 mp4) — long past the line. The coroner left one military law: in long-session plus high-density-screenshot acceptance mode, once readings reach about fifty, /compact or open a new window; seventy is a tombstone, not a milestone.

Worth noting the mercy of compaction: the 09-29 auto-compaction once erased 64 old images — compaction saved him once; it could not save him twice.

Real coordinates

• DB evidence: db.sqlite message-parts table, counted part by part (135 − 64 compacted = 71)
• Timeline: 19:01:34 the 70th entered history → requests fine; 19:06:01 the 71st → 19:06:21 rejected by 400, non-retryable
• Eliminated: inputs only ~25k tokens (far from 1M); no content-moderation records
• Docs vs measured: docs say 60 per request; this gateway allowed 70, rejected 71 (threshold differs from docs)
• Rule: images per message 50 → 55; shots-tv/ at 113 files already past the line; acceptance must batch and clean first
• Military law: in long-session screenshot acceptance, /compact or hand off at ~50