Skip to content

feat(screenshot)!: default to a 1024px JPEG for agent-facing captures - #185

Merged
yhc509 merged 1 commit into
devfrom
feat/screenshot-agent-defaults
Aug 15, 2026
Merged

yhc509 merged 1 commit into
devfrom
feat/screenshot-agent-defaults

Conversation

@yhc509

@yhc509 yhc509 commented Aug 15, 2026

Copy link
Copy Markdown
Owner

Closes #127

Why

A screenshot is the heaviest single response an agent can request. A 1920×1080 PNG bills at roughly 2,040 image tokens; the same frame capped at 1024px is about 576. --format jpg, --quality and --max-width already existed, but they were opt-in, so the default caller paid full price for fidelity no vision model can use.

What changed

screenshot now defaults to JPEG quality 75, capped at 1024px wide. Three rules keep the new default from surprising anyone:

situation result
--format png|jpg|jpeg given wins outright
no --format, --path ends in .png PNG — writing JPEG bytes into a file the caller named .png is worse than the tokens saved
--width and/or --height given cap suppressed entirely (this gate predates the change)
--max-width 0 cap off, size still auto-detected

--max-width 0 was previously rejected (minimum 1); it is now the documented opt-out and travels as a -1 wire sentinel, because maxWidth == 0 already means "unspecified" and the wire model cannot carry a nullable int.

QA coordinates are unaffected: qa tap / ui-dump / world-dump scale from LastCapturedWidth/Height, so a downscaled capture's coordinates still land.

Structure

ScreenshotDefaults lives in Runtime/Protocol/ so the CLI and the bridge resolve the defaults from one place and the resolution is unit-testable (Editor/*.cs is not compiled by dotnet). Resolving the cap once in Handle also collapses the ShouldApplyMaxWidth gate that was repeated at every capture site — that is most of the −59/+? churn in the handler.

Protocol 7 → 8

The default output of an existing command changed and maxWidth gained a sentinel. Bumping means a CLI that does not know the new defaults is routed to a matching install instead of silently returning different images. No response shape changed.

Verification

dotnet test — 1087 passed (17 new). check-unity-meta.sh passes; the new .cs has a Unity-generated .meta. DocGen --check clean.

Live against the sample project (Unity 6000.3.13f1, headless launch):

case result
no options 1024x600 jpg — cap fired on a 3600×2110 Game View
same frame, --format png --max-width 0 3600x2110 png
file size 104 KB → 10 KB
--path x.png, no --format png
--format jpeg --quality 40 jpg
--width 1600 --height 900 1600x900, cap suppressed
--max-width -1 CLI_USAGE rejection

Release note

This is a breaking default change plus a protocol bump, so it wants a minor version (0.6.0), and the CLI binary must be published before main moves — a user on #main with no CLI speaking protocol 8 would have nothing to dispatch to.

🤖 Generated with Claude Code

A screenshot is the heaviest single response an agent can request: a
1920x1080 PNG bills at roughly 2,040 image tokens, against about 576 for
the same frame capped at 1024px. The lightweight options existed but were
opt-in, so the common caller paid full price for fidelity no vision model
can use.

`screenshot` now defaults to JPEG quality 75 capped at 1024px wide.
Three rules keep that from surprising anyone:

- an explicit `--format` always wins;
- with no `--format`, a `--path` ending in `.png` selects PNG — writing
  JPEG bytes into a file the caller named `.png` is a worse outcome than
  the tokens the default saves;
- an explicit `--width`/`--height` suppresses the cap. That gate predates
  this change, which is why sized captures do not silently shrink.

`--max-width 0` is the opt-out for the cap alone and travels as a -1 wire
sentinel, because `maxWidth == 0` already means "unspecified" and the wire
model cannot carry a nullable int.

ScreenshotDefaults lives in Runtime/Protocol so the CLI and the bridge
resolve the defaults from one place and the resolution is unit-tested;
resolving the cap once in Handle also collapses the ShouldApplyMaxWidth
gate that was repeated at each capture site.

Protocol 7 -> 8: the default output of an existing command changed and
maxWidth gained a sentinel, so a mismatched CLI should be routed to a
matching install rather than silently return different images.

Verified live against the sample project (Unity 6000.3.13f1, headless):
with the Game View at 3600x2110, an option-free capture returned
1024x600 jpg / 10 KB against 3600x2110 png / 104 KB before. Format
selection, the .png path rule, the explicit-size bypass and the negative
--max-width rejection all confirmed against a running editor.

Closes #127

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@yhc509
yhc509 merged commit c5ac5f6 into dev Aug 15, 2026
3 checks passed
@yhc509
yhc509 deleted the feat/screenshot-agent-defaults branch August 15, 2026 03:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant