Bug + patch: a tall screenshot makes every later turn fail on Messages endpoints (many-image 3000px limit)

[Jdrg4]

Bug report + patch: a full-page screenshot makes every later turn fail on Messages endpoints

Branch with the fix: Jdrg4:fix/llm-deepseek-image-max-dimension (one commit)

Symptom

Once a conversation accumulates a tall screenshot, every later turn fails, even turns that carry no new image:

400 {"type":"error","error":{"type":"invalid_request_error",
  "message":"messages.9.content.88.image.source.base64.data: At least one of the
  image dimensions exceed max allowed size for many-image requests: 3000 pixels"}}

The whole turn is lost; the conversation cannot continue without dropping the history. It reproduces with the screenshots an agent takes itself: a 390×6400 or 520×6400 full-page capture.

Root cause

packages/llm/llm-deepseek/src/request-pricing.ts caps every request image at one per-side limit:

export const REQUEST_IMAGE_MAX_DIMENSION = 4096

That is the DeepSeek endpoint's many-image limit. Anthropic's Messages API caps many-image requests at 3000 pixels per side and rejects the whole request over one oversized image, so any target the adapter projects above 3000 is a request the endpoint must refuse.

Measured with the current projection (no API key needed, resolveRequestImageTarget):

Source	Token-grid projection	Target sent today (cap 4096)	With a 3000 limit
1440×3900	755×2044	755×2044	755×2044
520×6400	336×4130	333×4096 ← rejected	244×3000
390×6400	293×4816	250×4096 ← rejected	183×3000

The grid already shrinks a wide capture below the limit; a tall one (a full-page mobile screenshot) projects above 3000 and the 4096 cap leaves it there. That is why the failure appears only after some captures, and then poisons every later turn.

The per-side limit is also the only image limit that is not per model — imagePixelBudget and imageMaxBytes are already per catalog entry.

Patch

Image-capable catalog entries may declare imageMaxDimension; omission keeps 4096, so DeepSeek routes and every existing configuration are unchanged.

• types.ts — imageMaxDimension?: number on DeepSeekCatalogModel.
• request-pricing.ts — resolveRequestImageMaxDimension(model) beside resolveRequestImageMaxBytes; resolveRequestImageTarget uses it.
• config.ts — schema field, resolution into the validated connection (?? REQUEST_IMAGE_MAX_DIMENSION), and the same guard as imageMaxBytes (positive safe integer, rejected on a text-only entry).
• README.md / README.zh.md / README.i18n.yaml — document the field, including that Anthropic's Messages API needs 3000.
• Tests: the projection honours a model's own limit, keeps 4096 when none is declared, and rejects invalid values.

With models: [{ id: 'claude-…', inputModalities: ['text', 'image'], imageMaxDimension: 3000 }], a 390×6400 capture is projected to 183×3000 and the request succeeds.

Verification

pnpm exec vitest run --config vitest.config.ts \
  packages/llm/llm-deepseek/tests/request-pricing.spec.ts \
  packages/llm/llm-deepseek/tests/runtime.spec.ts
  → 2 files, 176 tests passed

pnpm exec tsc -b packages/llm/llm-deepseek/tsconfig.json      → clean
pnpm exec oxlint packages/llm/llm-deepseek/{src,tests}         → 0 warnings, 0 errors
pnpm run verify-translation-pairing <README.md>                → consistent (hashes re-recorded)
pnpm run verify-doc-refs                                       → 4659 files, all references resolve
pnpm run verify-export-jsdoc                                   → every exported name documented

Not run: test:coverage (repo-wide gate) and build. The change adds no dependency and no public export beyond the catalog field.

Question for the maintainers

Is a per-model field the shape you want, or would you rather a connection-level field (one Messages endpoint, one limit) or a different default for Messages-compatible endpoints? I can reshape the patch either way — it is one commit.

I did not open a pull request: CONTRIBUTING.md states the project cannot accept external pull requests at the moment, and the repository has Issues disabled, so there is no issue for a PR description to reference. This report is the contribution; the branch is ready to cherry-pick if you want it.

[PerryLink]

Checked on master ce7073d5. That is 351 commits past dsh-v0.2.2-alpha.2, and on it your numbers hold — with one twist: the clamp lands even further out than your table suggests.

packages/llm/llm-deepseek/src/request-pricing.ts:31 still reads REQUEST_IMAGE_MAX_DIMENSION = 4096, and the comment above it calls that number "Provider per-side limit for a request carrying 15 or more images". The target is built at :57-63: first the token grid (image-tokens.ts:132, capped at MAX_IMAGE_TOKENS = 1024 on :21), then the long edge is clamped to that 4096.

I ran those exact functions on your captures:

source	token-grid projection	sent after the 4096 clamp
390×6400	293×4816	250×4096
520×6400	336×4130	333×4096

So the clamp does fire and still emits a 4096-pixel long edge — a number that cannot satisfy a 3000-pixel limit. Your 1440×3900 row (755×2044) matches the projection exactly, so this is the code's arithmetic, not an estimate.

Two structural points worth putting in the PR:

• The encoder and the pricing meter share one target: images.ts:55 calls resolveRequestImageTarget to produce the bytes it sends, so every retained image is re-projected at that same size on every later request. "Every later turn fails" follows from the history being re-encoded, not from a one-off bad capture.
• There is no per-model dimension override. DeepSeekCatalogModel exposes only imagePixelBudget and imageMaxBytes (config.ts:79-80), so 3000 has to come from either a new field or a change to the constant.

One thing to settle before the patch: that comment claims 4096 is the many-image limit, while the endpoint's 400 says 3000. Both cannot be true for the same endpoint, so quote the error text in the PR — otherwise the value gets "fixed" back to 4096 by whoever reads the comment.

[Jdrg4]

Thanks — your arithmetic matches mine exactly, and the clamp reading at request-pricing.ts:31/:57-63 is the one I hit.

The patch is rebased onto ce7073d5 (it was written against v0.2.2-alpha.2, and the eight files I touch are byte-identical between the two):

• branch: Jdrg4:fix/llm-deepseek-image-max-dimension, commit e75bc45e
• compare against master: 1 commit ahead, 0 behind, 8 files, +59/−15

Taking your points in order:

1. The contradiction is now quoted where the value lives. REQUEST_IMAGE_MAX_DIMENSION's JSDoc no longer asserts that 4096 is the many-image limit. It says the value is not universal and names the failure: "At least one of the image dimensions exceed max allowed size for many-image requests: 3000 pixels". The commit message and both READMEs carry the same sentence, so the next reader cannot "restore" 4096 without contradicting the endpoint.

2. Re-encoding confirmed. images.ts resolves resolveRequestImageTarget for every retained image, so the cap is applied again on each later request — the history keeps a target the endpoint refuses. That is in the commit message as the reason the failure is per-turn rather than per-capture.

3. There is a per-model override now. imageMaxDimension?: number on DeepSeekCatalogModel, resolved by resolveRequestImageMaxDimension beside resolveRequestImageMaxBytes, defaulting to the existing 4096 so DeepSeek routes do not move. Schema field plus the same guards as imageMaxBytes (positive safe integer, rejected on a text-only entry). Docs in README.md / README.zh.md with hashes re-recorded.

Tests: request-pricing.spec.ts (15) and runtime.spec.ts (161) pass; tsc -b on the package clean; oxlint clean; verify-translation-pairing, verify-doc-refs (4659 files), verify-export-jsdoc pass. test:coverage and build not run.

4. The default is the open question, and I would rather you settle it than guess. dsh-llm-deepseek only speaks Messages, and its public baseURL is DeepSeek's own /anthropic endpoint. If that endpoint also enforces 3000 for a many-image conversation, then 4096 is simply wrong as a default and the fix should lower the constant (the field stays for endpoints that allow more). If 4096 is correct for DeepSeek and only other Messages endpoints publish 3000, the field is the whole fix. I only have the Anthropic-side 400 to go on and no DeepSeek key here to produce the matching one. Which is it? Changing the default is a one-line follow-up commit.

On the PR: I cannot open one. gh pr create is refused with Jdrg4 does not have the correct permissions to execute CreatePullRequest, and POST /repos/deepseek-ai/deepseek-harness/pulls answers 404 — pull requests are disabled for this repository, the same way issues are. The compare above shows the branch is visible and clean, so it is the endpoint that is off, not the head.

If you want the commit, either open it from the branch internally, or cherry-pick it:

git fetch https://github.com/Jdrg4/deepseek-harness.git fix/llm-deepseek-image-max-dimension
git cherry-pick e75bc45e

Happy to reshape anything — a connection-level field instead of a per-model one, a different name, or a smaller diff that only moves the constant — whichever you prefer once the default question is answered.