Workflow: keep inspected images compact and image results prominent

[Juns-g]

Workflow: keep inspected images compact and image results prominent

What I am trying to do

I use coding agents to inspect screenshots repeatedly while debugging, and I also ask them to
generate or deliver images as actual results. I want to glance at the evidence in the timeline,
keep reading the surrounding reasoning, and open the original only when I need detail.

What happens today

Every assistant image becomes a full-width block. Portrait screenshots and long captures can take
several screens, so the tool trace overwhelms the conversation.

This is not only a sizing problem. Paseo currently maps both Codex imageView and
imageGeneration items to ordinary assistant Markdown images:

• codex-app-server-agent.ts
• provider-image-output.ts

The client then renders every assistant Markdown image at width: 100%, with height derived from
its aspect ratio:

• message.tsx
• AssistantMarkdownImage

As a result, an image the agent merely inspected and an image it intentionally produced have the
same visual weight.

A better interaction model

I would like Paseo to make two decisions instead of applying one global size cap.

1. Choose density from image intent

• Inspected/tool image — a view_image, browser capture, or image-bearing tool result should be
  a compact activity such as “Viewed an image”. It can be collapsed after completion; expanding it
  reveals a thumbnail strip.
• Image result — an image generation or an image deliberately delivered as response content
  should remain prominent as a rich inline preview/gallery.
• Unknown Markdown image — keep backward compatibility and treat it as ordinary inline media
  unless the provider supplied stronger intent.

This is the useful distinction in the current Codex app: inspected images are compact activity,
while generated images receive a richer gallery. The goal is the information hierarchy, not to
copy its exact pixels.

2. Compute the preview footprint from geometry

For rich inline images, use the intrinsic dimensions together with the measured message container
and a visual budget derived from the current viewport. The fit should:

• preserve the original aspect ratio;
• never upscale a small image merely to fill the message width;
• contain, rather than crop, a single screenshot;
• constrain extreme portrait images by the available vertical viewport;
• reserve the same geometry while loading so the timeline does not jump;
• group adjacent images into a responsive row/strip instead of stacking full-width blocks.

In other words, the result should come from a shared fit function over intrinsic size, container
size, viewport, and image count — not a universal maxWidth / maxHeight pair. The exact visual
budget can remain a product/design decision.

Both compact and rich previews should continue to open Paseo's existing zoomable lightbox.

Prior art

• The current Codex app separates inspected images from generated image galleries and lets both
  open into a dedicated viewer.
• LibreChat caches intrinsic dimensions and computes message image geometry from aspect ratio,
  container width, and viewport height instead of width alone:
  Image.tsx,
  scaleImage.ts.
• big-AGI lays multiple image attachments out as a wrapping strip and preserves aspect ratio under
  separate wide/tall constraints:
  ImageAttachmentFragments.tsx.

Why this is better than a fixed cap

A fixed cap only changes how large the current mistake is. Intent-aware density makes routine
debug evidence quiet while keeping actual visual deliverables visible. Geometry-aware fitting then
works across desktop, split panes, narrow windows, and mobile without tuning a separate magic pixel
value for each surface.

Suggested implementation seam

Preserve image intent in the provider-neutral timeline model instead of flattening all provider
image events into Markdown. The exact schema is open for discussion, but the renderer needs to know
at least whether an image was inspected or produced. Older daemons and ordinary Markdown images can
continue through the existing fallback.

Paseo already caches assistant image dimensions and estimates virtualized row height. The new
renderer and the estimator should call the same pure geometry function so loading, remounting, and
pagination reserve identical space.

Acceptance criteria

• A completed view_image does not consume a full-width image block until the user expands it.
• A generated/delivered image remains visible and useful in the timeline.
• Small images are not upscaled; portrait and landscape images preserve their ratio.
• Multiple images do not become a vertical stack of full-width blocks.
• Loading an image does not cause a large scroll jump.
• Keyboard, screen-reader, and existing lightbox behavior continue to work.
• Static before/after evidence covers desktop and compact widths; the affected native platforms are
  listed and tested according to Paseo's QA guide.

If this direction fits the product, I am happy to implement it and provide the cross-platform QA
evidence.