Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Opus 5.5: let a client opt into summarized thinking instead of forced progress updates

Open Beginner friendly
  • Is something wrong?
#7,728 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
api, backend

Research direction

Start with progressUpdates and the Opus 5.5 override in src/adapters/anthropic.ts, then read the focused regression tests in tests/adapters/anthropic/anthropic-progress-updates.test.ts. Check how reasoning.summary and hideThinkingSummary are handled in the adapter. Done when explicit detailed or concise requests use summarized display without the updates beta, while absent or auto keeps updates; the issue also mentions documenting the behavior in guides/providers.md.

Written by the indexing model from the issue text.

Description

enhancement
Area

Provider adapters (anthropic)

What are you trying to accomplish?

We run a Responses client (gjc, an ACP/coding-agent host with a mobile front end) through OpenCodex against anthropic/claude-opus-5-5 on api.anthropic.com. The client shows reasoning summaries in a "thinking" view. We want Opus 5.5 reasoning summaries to show there, like they do for every other Claude model behind the same adapter.

What prevents this today?

Since #7143 (fixes #7108), the adapter forces thinking: {type: "adaptive", display: "updates"} plus the thinking-display-updates-2026-08-18 beta whenever usesNativeAnthropicEndpoint(provider) and the model is Opus 5.5 (src/adapters/anthropic.ts, progressUpdates around line 1084, override at line 1151). The override runs after, and ignores, everything the request said about reasoning display:

Measured on main (9f0d40a2, 2.92.0) with createAnthropicAdapter(...).buildRequest(parseRequest(...)):

model request reasoning sent thinking
claude-opus-5-5 {effort:"high"} {"type":"adaptive","display":"updates"} + beta
claude-opus-5-5 {effort:"high", summary:"detailed"} {"type":"adaptive","display":"updates"} + beta
claude-sonnet-5-5 {effort:"high"} {"type":"adaptive","display":"summarized"}
claude-sonnet-5-5 {effort:"high", summary:"detailed"} {"type":"adaptive","display":"summarized"}

Observed effect through a 2.88.0 deployment:

  • In one session, 756 of 828 reasoning items on the Opus 5.5 lane carried empty summary text.
  • A probe turn spent 275 reasoning tokens and returned summary_text: "". The only visible text was progress commentary (phase: "commentary").
  • The same client talking to Anthropic directly (display: "summarized") had 47 of 47 thinking blocks with text.

I understand this is intentional. The provider guide explains that under display: "summarized" Anthropic cannot tell progress updates apart from reasoning, and the updates mode is the better default for Codex. So this is not a request to revert #7143.

What should OpenCodex do?

Keep display: "updates" as the default for Opus 5.5. Let a client that explicitly asks for reasoning summaries get them:

  • Request reasoning.summary is "detailed" or "concise": send {type: "adaptive", display: "summarized"} without the updates beta. This is the same body Sonnet 5.5 / Opus 5 get today.
  • "auto" or absent: unchanged (display: "updates").
  • hideThinkingSummary keeps its current meaning.

A client opting in accepts the trade-off the guide describes: progress updates may arrive folded into reasoning summaries instead of as separate commentary.

Example usage or interface
{ "model": "anthropic/claude-opus-5-5", "reasoning": { "effort": "high", "summary": "detailed" } }

→ thinking: {"type":"adaptive","display":"summarized"}, no thinking-display-updates-2026-08-18 beta.

Alternatives or workarounds
  • A provider-level config flag (e.g. opus55ThinkingDisplay: "updates" | "summarized"). It is less flexible than per-request, but it would also work for clients that always send summary: "auto".
  • Patching the deployment locally. We are avoiding that.
Additional context

Happy to send the PR with focused regression tests in tests/adapters/anthropic/anthropic-progress-updates.test.ts (the opt-in path sends summarized and no beta; auto and absent stay on updates). The docs change would go in guides/providers.md. Before writing it, I'd like to confirm which shape you prefer (per-request reasoning.summary vs. provider flag).

Checks
  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
11h 47m
Merged PRs (30d)
649

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.