Skip to content

Explicit cache breakpoints in OpenAI Responses, fix copy beyond viewport - #179

Merged
stippi merged 5 commits into
mainfrom
fix-copy-beyond-viewport
Aug 10, 2026
Merged

Explicit cache breakpoints in OpenAI Responses, fix copy beyond viewport#179
stippi merged 5 commits into
mainfrom
fix-copy-beyond-viewport

Conversation

@stippi

@stippi stippi commented Aug 9, 2026

Copy link
Copy Markdown
Owner

No description provided.

stippi added 3 commits August 8, 2026 21:20
OpenAI's automatic prompt caching often misses in practice, showing up
as ballooning uncached input tokens in agent sessions. GPT-5.6+ models
support explicit cache control via prompt_cache_breakpoint markers on
input content blocks, analogous to Anthropic's cache_control.

- Extract the Anthropic cache-marker placement (stable prefix via
  volatile flag, markers every 5 messages) into a shared
  prompt_caching module and reuse it for both OpenAI Responses clients
  (HTTP and WebSocket).
- Place breakpoints on input_text/input_image blocks; markers anchored
  on non-eligible items (tool calls/outputs, assistant text) shift
  backwards to the nearest eligible block. The HTTP client additionally
  marks the developer/system message.
- Gate the field on GPT-5.6+ (older models reject it).
- WS client: markers serialize as part of the input items, so
  compute_delta forces a full resend when marker positions move; the
  cached token prefix itself stays valid.
- Parse cache_write_tokens from usage and normalize OpenAI usage to
  Anthropic semantics: input_tokens now excludes cached and
  cache-write tokens (consumers like context-usage tracking already
  assumed this).
…ages

The quantized scheme left the tail behind the last marker (up to ~5
messages, often including large tool results) billed at full input
price on several consecutive requests. A cache write (1.25x) pays for
itself as soon as the prefix is reused once, so caching as early as
possible is strictly cheaper for any conversation that continues.

New stateless placement: leading marker on the last stable message,
trailing marker on the message directly before the last stable
assistant message. Since every request ends on a user message and the
response is appended right behind it, that position is exactly where
the previous request placed its leading marker — the lookup is
guaranteed to hit and only the newly appended messages are written,
regardless of how many messages arrived in between (tool results,
pending user messages).

The OpenAI Responses clients keep the quantized scheme: implicit mode
already caches up to the latest message on every request, and
rarely-moving markers keep the WS client's incremental input intact
(per-request movement would force a full resend every turn).
Bumps gpui-component to ab37c62a (markdown-source-copy-consume-v3):
markdown-source-copy + the copy-beyond-viewport fix (select the full
geometric band, not just visible glyphs) + the zed 1a246efd pin.

Also adapts BlockView::markdown_view to the SelectionFormat API
(.selectable_source() -> .selection_format()).
@stippi stippi changed the title Fix copy beyond viewport Explicit cache breakpoints in OpenAI Responses, fix copy beyond viewport Aug 9, 2026
stippi added 2 commits August 10, 2026 16:35
Consume the merged 'Copy Markdown source' work (gpui-component PR #2628)
from stippi/gpui-component. Pin gpui-component to the thin pin-zed-cc053a4a
branch (upstream main + one commit pinning the zed git deps) and pin the
zed crates to cc053a4a so the graph resolves to a single copy of gpui.
@stippi
stippi merged commit 1a3e1b6 into main Aug 10, 2026
5 checks passed
@stippi
stippi deleted the fix-copy-beyond-viewport branch August 10, 2026 15:24
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