Surface Claude Code's prompt suggestions in the composer #9394

Web / desktop — ghost placeholder text, Tab to accept

Mobile — dismissible chip above the input, tap to accept, X to dismiss

Android	iOS

This would be very helpful. I wish this existed.

Linking #8524, which was closed with two concerns: durable shared state, and no user control. I'd like to propose a smaller design that answers both, and I'm happy to implement it if you approve the direction.

1. Ephemeral state.

• The server reads the SDK's prompt_suggestion message. It is sent after result, so the adapter must keep reading the stream after the turn ends.
• The server forwards it as a transient event to connected web and desktop clients only. No persisted activity, no shared activity contract change, no sync to other clients.
• The client keeps one suggestion per thread in memory. It clears the suggestion when the user types, sends a message, switches thread, or dismisses it.

2. Explicit control.

• A Claude provider setting, "Prompt suggestions", turns promptSuggestions on or off. It is off by default.
• When it is off, the adapter never sets the SDK option.

3. Scope.

• The first PR covers web and desktop only. Tab accepts the suggestion and Esc dismisses it. Mobile is left for later.
• Codex follow-ups are not touched.

Questions

• Is off by default the right choice, or should it be on?
• Should a transient event type be added to the existing provider event stream, or is there a better channel for session-only data?
• Is web and desktop only acceptable for a first PR?

I'd follow the one-problem rule and send the PR only after a maintainer approves the direction.

+1 from a daily T3 user (macOS desktop, Claude provider). This is the Claude Code feature I miss most since switching.

On @thedrowsywinger's questions, from a user's point of view:

• Default: Off is fine. A "Prompt suggestions" toggle under the Claude provider settings is where I'd look for it first.
• Accepting: Tab to accept and Esc to dismiss, like in the Claude Code CLI. Accepting should only fill the composer, never send.
• Scope: Web and desktop first works for me, since that's where I use it.

The ephemeral design also matches how I'd use it. The suggestion only matters right after a turn finishes, so I wouldn't expect it to survive a restart or show up on another device.

@thedrowsywinger if the direction gets approved, I'm happy to help test on macOS or take a part of the implementation.

I built the smaller design from @thedrowsywinger's comment on a fork to check that it holds up: tobymarks/t3code@feat/claude-prompt-suggestions

• Ephemeral: The latest suggestion per thread lives in an in-memory store on the server. It is cleared when the next turn starts or the session closes, and clients read it through a stream that only lives in memory. It is not persisted, not added to thread activities, and no activity contracts change.
• Opt-in: There is a "Prompt suggestions" switch in the Claude provider settings, off by default. When it is off, promptSuggestions is never passed to the SDK.
• Web/desktop only: The suggestion is the empty composer's placeholder. Tab fills the draft and never sends. Esc hides it. Mobile is untouched.

I tested it in a dev build with Claude Sonnet 5.5 and added focused tests for the adapter and the store. One finding: the CLI did emit a suggestion after the first turn, even though the SDK typings say it is suppressed there.

Setting (off by default)	Suggestion in the empty composer	After Tab

@thedrowsywinger this isn't meant to take over your proposal. If the direction is approved, feel free to use any of it, or I can open the PR, whichever you and the maintainers prefer.

I opened a PR for this: #17618.

It builds on @tobymarks' fork. Suggestions appear as placeholder ghost text: Tab fills the draft and Esc hides it. The toggle lives under Settings → Providers → Claude and is off by default. It also follows the close note on #8524:

• The suggestion lives only in server memory and has its own subscription instead of going through the activity contract.
• Mobile is unchanged.
• The suggestion is cleared when the next turn starts, after a background wake, after a rollback and when the session closes. The client only shows it while the run it follows is still the latest.

Feedback on the product behavior is very welcome. I'm happy to adjust it.

#17618 was closed because upstream isn't taking feature PRs right now, which is fair. Until it lands upstream, I'm publishing a patched nightly on my fork for anyone who wants Claude prompt suggestions now:

https://github.com/danielyc/t3code/releases

It's the official nightly with only the #17618 patch added. An hourly workflow picks up each new upstream nightly, applies the patch and builds macOS, Windows and Linux (x64 and arm64). A patched build usually follows the official one within an hour or two, with the same version number, and the app updates itself from my fork's releases.

To use it, install it over your existing T3 Code (Nightly), then turn on Settings → Providers → Claude → Prompt suggestions.

Claude Code itself decides when to offer a suggestion. It never offers one on the first turn of a new session, in plan mode, after an API error, or when your usage limit is reached, and close to the limit it holds them back unless you opt in. To keep them on as much as Claude allows, add this to ~/.claude/settings.json:

{
  "promptSuggestionEnabled": true,
  "env": {
    "CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION": "true"
  }
}

The main limitations: it's unofficial (please report problems on my fork, not upstream), it only works for Claude in the desktop app, and it replaces the official Nightly instead of installing next to it. The full list, including notes for macOS, Windows and Linux, is in the README.

Going back to the official nightly: download the newest nightly release from pingdotgg/t3code releases, quit T3 Code and install it over the patched one (on macOS, drag it to Applications and choose Replace). Your threads and settings stay, and from then on it updates from upstream again.

I'd like this for the Codex provider too. Codex's desktop app calls it Composer Predictions: after a response, it suggests the next message in the empty composer. Tab accepts it as an editable draft, without sending.

I saw #17618 was closed pending agreement on feature direction and scope. Would maintainers accept prompt suggestions as a shared composer feature, with provider support added incrementally?

The behavior I'd like is:

• One suggested follow-up in the empty composer after a turn finishes.
• Tab accepts, Esc dismisses, and typing your own message clears it.
• Accepting only fills the draft. It never sends automatically.
• An off-by-default setting, with suggestions kept in memory.

The existing Claude work looks like a useful starting point. For Codex, the open question is whether its integration exposes native predictions; if it doesn't, would an explicitly opt-in lightweight prediction request be acceptable, given the extra usage and latency?

A Claude-only first step is useful, but Codex support is what would cover my workflow. It would help to get agreement on that direction before anyone invests in another implementation.

+1 - really need this (for codex too)

+1 for this. I'm coming from the Claude and Codex desktop apps, and the suggested next prompt (ghost text, Tab to accept) is one of the things I miss most in T3 Code. An off-by-default toggle like the one in #17618 would be perfect for me.

Following the Codex support question above, would maintainers approve an opt-in Codex implementation of next-prompt suggestions? We have a local prototype, but are seeking agreement on direction and scope before opening a PR.

Proposed behavior:

• Off by default, with a persistent client setting. The prototype puts it under Settings → Chat → Composer; placement is open to maintainer guidance.
• After a Codex reply finishes while the conversation is open, show one suggested follow-up in the empty composer. Opening existing history does not trigger generation.
• Tab accepts into an editable draft without sending; Esc dismisses. Typing, disabling the setting, or switching threads/models clears the suggestion and suppresses late results. Existing composer menus retain their keyboard handling.
• Clearly explain that enabling it makes an additional model request on the configured Codex account.

What works today: with Codex CLI 0.166.0, thread/fork using ephemeral: true and experimentalPredictionMode: true supports generating a suggestion from the loaded conversation context, using its model. The prototype runs an extra turn with a short next-user-message instruction and unloads the temporary fork afterward. It requests read-only execution with approvals disabled and instructs the model not to use tools or carry out the suggested task.

This is not proven equivalent to the official app's Composer Predictions. We use our own prediction instruction and cannot claim its quality or usage exemption. The dedicated thread/prediction/request method returned -32601 / “not implemented yet” in both the tested CLI and the Codex App's bundled 0.166.0-alpha.5.1 executable. The working approach depends on an experimental capability.

Local validation: 83 focused tests passed across the affected server, settings, permissions, and browser areas, plus web/server typechecks and targeted lint. An integrated web pass verified settings persistence, generation after a new reply, and Tab acceptance without submission. Small synthetic smoke checks worked with Sol, Terra, and Luna; these are not a quality benchmark. Packaged desktop, native mobile, relay, older CLI compatibility, and simultaneous clients remain unvalidated. Server-side request deduplication also needs attention before a PR.

Could maintainers clarify:

1. Is this explicit opt-in, extra-request approach acceptable, or should Codex support wait for the dedicated prediction API?
2. Should the setting live under Chat/Composer or Providers/Codex?
3. Would a Codex-only implementation in the shared web/desktop composer be an acceptable first scope, with native mobile and other providers handled separately?

An explicit direction/scope decision here would let us prepare a focused PR with the remaining checks, before/after screenshots, and an interaction recording. We are not treating the local tests or this discussion as approval.

+1 from a daily T3 Code user on macOS who mostly runs Codex. Composer Predictions in the Codex desktop app is the feature I miss most after switching.

I'd prefer one provider-neutral composer surface, so Claude prompt_suggestion and Codex predictions (or :codex-followup) both feed the same ghost text. Off by default is fine. Tab should insert an editable draft and never send, and Esc should dismiss.

+1 from a daily T3 Code desktop user on Windows who mostly runs Claude. The suggested next prompt (ghost text, Tab to accept) is what I miss most from Claude Code.

A Claude-only first step in the shape of #17618 (kept in memory, off-by-default setting, Tab fills the draft and never sends) would already cover my workflow. A provider-neutral composer surface that Codex can plug into later sounds like the right direction, and I'd be glad to see maintainers approve that scope here.

This was picked up separately by Theo in #28047, which is now merged. It adds a Suggest next prompt option under Settings → Labs, off by default, for both Claude and Codex. Tab fills in the suggestion and Escape dismisses it. Mobile is listed as a follow-up.