[Feature]: Suggest a follow-up prompt when a turn finishes #6839

A cheaper way to get this for Claude threads: the Claude Agent SDK already predicts the next prompt, T3 just does not switch it on.

@anthropic-ai/claude-agent-sdk (including the 0.3.170 that t3code pins) has promptSuggestions: true on the query() options. With it set, the CLI emits one { type: "prompt_suggestion", suggestion } message after each turn's result, generated off the turn's own prompt cache, so there is no second model call and no extra text-generation plumbing. ClaudeAdapter already receives the message today; it just returns without doing anything (#4244 added that as a "no T3 surface yet" case), and the option is never passed.

I built the SDK-native version on a fork so it can be evaluated (or thrown away):

main...getbrikly:t3code:feat/claude-prompt-suggestions

What it contains (13 files, +458/−2, no new dependencies):

• ClaudeAdapter: pass promptSuggestions: true; map prompt_suggestion to a new turn.prompt-suggestion runtime event, attributed to the turn that just completed (the message arrives after result, once turnState is cleared).
• contracts: the turn.prompt-suggestion event schema.
• ProviderRuntimeIngestion: persist it as a prompt-suggestion activity through the existing activity channel, so it reaches every client and survives reloads. Web and mobile hide it from the work log.
• Web composer: derive the suggestion for the latest completed turn and render it as faded text in the empty editor (in the existing placeholder slot) with a Tab hint. Tab inserts it into the draft, never sends. Typing ignores it. It clears as soon as a newer user message or turn exists, or while the composer is in any other state (approval, question, plan follow-up, draft text). Matches the Claude Code CLI behaviour.
• docs/user/composer.md section.
• Tests: adapter (event emitted for the completed turn, dropped when there is no turn to attach to, option passed), ingestion mapping, work-log filtering, and the derive helper.

Deliberately not included:

• A T3 settings toggle. Suggestions already follow the user's own Claude settings (promptSuggestionEnabled: false in settings.json or CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false suppresses them, and the CLI also suppresses on the first turn, in plan mode, after API errors and near the usage limit), so I did not add a second switch. Easy to add if you would rather have one in Settings.
• Other providers. This is Claude-only by construction; none of the other harnesses expose an equivalent. The turn.prompt-suggestion event is provider-agnostic, so a provider that grows one later can emit it without client changes.
• A mobile surface (mobile just hides the activity).

Verified with targeted typecheck (contracts, server, web, mobile), vp fmt --check, lint, and the touched test files (server 128, web 86, contracts 10). Happy to open it as a PR, reshape it, or drop it, whichever you prefer.

Opened the SDK-native version as a PR, rebased onto today's main: #8524. Same shape as described above (promptSuggestions: true → turn.prompt-suggestion event → prompt-suggestion activity → Tab-to-accept ghost text in the empty composer), no settings toggle, Claude-only by construction.

+1, would love to see this. It's one of the Claude Code features i miss most in T3.

The smaller version described in the #8524 close note sounds right to me: keep the suggestion as ephemeral session state, add a toggle in Settings, and accept it with Tab or right arrow like in the Claude Code CLI.

I opened a PR for the smaller version that the #8524 close note asked for: #17618.

It uses the Claude Agent SDK's own promptSuggestions option, so there is no extra model call, and it follows the two points from the close note:

• Explicit user control: an off-by-default Prompt suggestions toggle per Claude instance, under Settings → Providers → Claude.
• Ephemeral state: the latest suggestion per thread lives only in server memory and reaches the client over its own subscription. Nothing is persisted, the activity contract is unchanged, and mobile is untouched.

In the web and desktop apps the suggestion shows as ghost text in the empty composer. Right Arrow or Tab puts it in the draft without sending, as in the Claude Code CLI, and Esc hides it. It is cleared when the next turn starts, when a background wake starts, on rollback and when the session closes.

It is Claude-only by construction. Suggestions for other providers would need the text-generation approach from the original post, which this PR does not attempt.

Status: it is up to date with main, and I tested it in the web dev build and in a packaged desktop build on macOS on top of the latest nightly. The fork's CI workflows still need a maintainer's approval to run. Feedback on the product behavior is welcome, since the close note asked for that to be settled first.

I'd like to help add Codex follow-up suggestions once 0.163 reaches stable, ideally reusing the opt-in, ephemeral suggestion state and composer behavior from #17618 in a separate Codex change.

We verified an end-to-end path on codex-cli 0.163.0-alpha.5: thread/fork with experimentalPredictionMode: true, ephemeral: true, and excludeTurns: true, followed by a prediction prompt and structured output on the fork. It inherits the parent's model/context; setting effort: "low" on the prediction turn returned a useful suggestion in about 3.9 seconds in our smoke test. T3 still needs to supply the prediction prompt and output schema.

For clarity, this uses prediction fork mode, not thread/prediction/request, which is still unimplemented in that alpha. Stable 0.162.1 does not support the fork flag and silently ignores it.

Would this be a welcome follow-up once 0.163 is stable? Happy to wait for #17618 and maintainer direction before proposing an upstream implementation.

AI-assisted; the alpha fork flow was tested locally.

I like the provider-independent direction of this proposal. We’ve been looking into related implementations, and a few findings seem relevant:

• PR #17618 uses Claude’s native SDK prompt suggestions, with an opt-in setting and composer ghost text. This seems like a useful native path and a reference for the interaction design.
• The earlier PR #8524 was closed without merging. The discussion around opt-in behavior and keeping suggestions ephemeral seems worth carrying forward.
• A recent comment in this discussion reports an experimental Codex path using thread/fork with experimentalPredictionMode, ephemeral, and excludeTurns in 0.163.0-alpha.5. We haven’t independently tested it, so I’d treat this as a promising integration lead rather than an established capability.
• ZCode’s suggested-prompts implementation provides predefined prompts for starting new tasks. From what we could verify, that is a different feature from predicting the next prompt in an ongoing conversation.

These findings suggest that native support will vary between agents and versions. Could suggestion generation sit behind a common interface, with three configurable options?

1. Automatic: use native agent suggestions when supported.
2. Separate model: use a configurable lightweight model regardless of the main agent.
3. Off: make no additional requests.

Our setup routes multiple providers through a shared relay. Being able to select one inexpensive suggestion model across Codex, Claude, OpenCode, and other integrations would be useful. Native and generic generation could share the same composer behavior, while avoiding duplicate requests.

For the generic path, I’d suggest bounded context containing the task goal, recent relevant messages, and what the agent actually completed. Returning no suggestion should be a valid outcome, particularly when the task is finished.

Requests should happen at most once per completed turn, only for the active conversation with an empty composer. Results should be discarded if the user starts typing or another turn begins. Accepting a suggestion should fill an editable draft without sending it, and unaccepted suggestions should stay out of conversation history.

A small, explicit opt-in first version with one suggestion and a configurable suggestion model seems like a good starting point. Is an interchangeable generation interface compatible with the direction you envision here?

Thanks both. #17618 should already work as the shared layer you describe: the server's PromptSuggestions service, the PromptSuggestion contract, the subscription and the composer behavior don't depend on the provider. Only the source is Claude-specific. A Codex adapter, or a generic text-generation fallback later, can publish into the same service without client changes.

@aj604 a separate Codex PR on top of that sounds right to me once 0.163 is stable. Since prediction fork mode is an extra turn on the user's own plan, I'd keep it behind its own off-by-default toggle per Codex instance, the same way Claude works.

@ironyh I'd keep the generic "separate model" option out of the first version. I also had that idea but it adds a model call per turn and gets less context than the native path. If maintainers want it later, it could reuse the existing text-generation model setting as a fallback for providers without native suggestions, with a selector for preferred behaviour for all providers.

In the end it's up to the maintainers whether they want this direction.

#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.

👍 Moving my proposal here as Julius asked (closed #21429 as a duplicate). There's a draft implementation in #21428.

It's the provider-independent version of this idea, shaped by the #8524 close note:

• Opt-in: Settings → General → Next prompt suggestions, off by default.
• Ephemeral: one guarded orchestration.suggestNextPrompt { threadId, afterMessageId } request per reply you watched finish. The result lives only in client memory: nothing is persisted or broadcast, and there are no new events or projections.
• Works with any provider: it uses the configured text generation model, with an optional dedicated "Prompt suggestion model" so you can pick something fast and cheap.
• Interaction: ghost text in the empty composer. Tab or Right Arrow accepts, Esc hides it until the next reply.
• Cost guard: opening or switching to old threads never runs a model, and rolled-back turns are excluded.

Design questions for maintainers:

1. Is an opt-in, provider-independent version acceptable alongside (or instead of) the Claude-native path from feat(claude): suggest the next prompt as composer ghost text #17618? The trade-off is one extra small model call per turn versus Claude-only coverage.
2. Placeholder plus Tab, or a chip in the banner slot as the original post suggests?
3. Keep the dedicated model setting, or always use the text generation model?

I have an updated provider-independent implementation of this idea in PR #25652, building on the opt-in and ephemeral-state concerns discussed here. I’m linking it for design feedback; explicit maintainer approval of the direction and scope is still outstanding.

The proposed interaction is grey text in the empty composer after an agent reply the user watched finish. Tab or Right Arrow inserts an editable draft and never sends it; Escape dismisses it. Accepting consumes the suggestion. Opening an old thread does not generate one.

The current shape:

• Off by default, under Settings → Threads → Next prompt suggestions, with optional project-scoped instructions.
• Uses the existing text-generation model selection, including project overrides and its normal usage-limit fallback. There is no separate suggestion-model setting in this version.
• One additional model request per eligible watched reply. This is the trade-off of the generic approach; it does not depend on a provider exposing native suggestions.
• Ephemeral client state only. Suggestions add no events, projections, activities, or conversation messages. The RPC requires orchestration-operate permission because it runs a model.
• Stale results are discarded. Thread/environment changes, newer messages, and rollbacks invalidate suggestions; the server checks the source reply both before and after generation. Disabled or unsupported generation produces no suggestion.
• Web/desktop composer scope. Mobile has no suggestion UI in this proposal. A native provider source could be considered separately, but this PR implements only the generic text-generation path.

Local verification at 675876c14: 422 tests in 25 files, typechecks for 32 affected packages, changed-file checks, and the web production build passed. The PR includes runtime screenshots and browser checks for settings search, persistence, and project override reset. A real-provider run through suggestion generation and composer acceptance, native-client interaction, and relay mode remain unverified. Fork CI also needs maintainer approval.

For maintainers, the two decisions I’d like to settle are:

1. Is this opt-in generic approach welcome, given the extra model request, or should the first version be limited to native provider suggestions?
2. Is grey composer text with Tab/Right Arrow acceptance the preferred interaction, or would a suggestion chip be a better fit?

Happy to narrow or reshape the PR around the agreed direction. This is a request for product-direction feedback, not a claim that the feature has been approved.

+1 — seconding this request. I would love composer predictions in T3 Code similar to the Codex experience: a suggested next prompt after a turn finishes, with Tab to accept it into an editable draft and Escape to dismiss. Accepting should never send automatically. This would make it easier to keep work moving without having to type every follow-up from scratch.

+1 from a T3 Code Nightly user on macOS using Codex. This is the interaction I want from ChatGPT: after the assistant finishes, the empty composer automatically shows a context-aware follow-up message as faint ghost text, and I press Tab to accept it.

My preferred behavior:

• Suggest one useful next message based on the current conversation, rather than a generic canned reply.
• Show it in the empty composer with a small Tab to accept hint.
• Tab inserts an editable draft; it does not send it. I can edit it and use the normal send action when ready.
• Typing my own message ignores the suggestion; Esc dismisses it. Never overwrite an existing draft or let a late suggestion replace something I have started typing.
• Preserve normal Tab focus navigation when there is no suggestion, and existing mention/autocomplete behavior when its menu is open.
• Make it optional, and support Codex as well as Claude. A Claude-only implementation would not cover my current workflow. If generating suggestions requires an extra model call, make the extra usage clear when enabling it.

A simple example: after the agent explains a change, the composer could suggest “Can you verify this with a focused test?” I press Tab, adjust the wording if needed, and send. The suggestion itself must not start another agent turn or grant approval for an action.

I saw the maintainer direction in #21429 to consolidate this request here, and the Claude-specific work in #9394. Adding my use case here rather than opening a duplicate. I would like to contribute toward this once maintainers agree on direction and scope.

Customize the suggestion agent in Settings

Please also expose a Follow-up suggestions settings section where I can:

• Enable or disable suggestions.
• Choose the provider and model responsible for generating them, independently of the main conversation agent, from supported configured providers.
• Edit the suggestion agent's instructions: for example, my preferred tone, reply length, language, and the kinds of next steps it should suggest.
• Restore the default instructions if I want to undo my customization.

These settings should apply only to suggestion generation, without changing the main conversation agent's instructions. The suggestion agent's job is to return proposed text; it should not execute tools or actions. If a provider-native suggestion mechanism does not support model or instruction customization, make that limitation explicit in Settings rather than implying those controls work. Choosing another provider should also make clear that conversation context will be sent to that provider and may incur additional usage.

Prepared with Codex assistance. The reference screenshots contain private conversation details, so I have described the interaction instead of uploading them. No implementation or testing is claimed.

Would still really love this feature 😃

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.

Following up on #28047 (thanks @t3dotgg). It shipped the built-in Claude and Codex suggestions behind Labs. This proposes one opt-in extension: a "My model" source, so a user can steer suggestions with a model and focus they choose. It's the shape @ironyh (Automatic / Separate model / Off) and @Abaans (choose provider and model, edit the suggestion agent's instructions) asked for above. I'm looking for direction and scope approval before opening anything.

What it adds

Under Settings → Labs → Suggest next prompt:

• Source: Built-in (default, unchanged) or My model, which works with any text generation provider.
• Model and effort: the existing picker. When off, it follows the text generation model.
• Behavior: a dropdown of presets plus your own instructions. A project can override the behavior.
  • Stay on track (default), Show me the next step, Head off future problems, Verify before moving on, Tests first, Security check, Help me understand, Ship small.
  • The presets map to common complaints about coding agents: drift and scope creep, "almost right" code, verifying before commit, skipped tests, security, and "it works but I don't know why".
• Speed: "Recent suggestions took about N s", the measured median, with a note that smaller models and low effort are fastest.
• Notice: your recent conversation is sent to the suggestion model's provider, and each suggestion is an extra request on its usage.

See it

Settings: source, model and effort, behaviors, and adding your own.

In a thread: each suggestion appears in the empty composer after the turn, and Tab fills it in.

The composer, Tab, Escape and staleness rules are #28047's, unchanged. My model writes into the same in-memory suggestion store through a new publishPromptSuggestion.

Cost and safety rails

• Only threads someone has open. It generates when a root run completes on a thread with a live suggestion subscription, or once when you reopen a thread whose latest completed run has no suggestion. It never runs for threads nobody has open, delegated or subagent threads, or provider continuations.
• No paying twice. While the source is My model, the built-in requests are gated off, and built-in events can't overwrite a My model suggestion.
• Bounded context. The context sent is the last 8 executed runs, the latest todo list or proposed plan, and last-turn tool labels. One temp cwd keeps project instructions out.
• Quiet failures. A failure publishes nothing and doesn't count toward speed.
• No persistence. Nothing is stored and no contracts change for activities. Mobile is untouched.

Evidence (eval, 15 short conversations)

evals/next-message compares #28047's Codex prompt wording ("generic", run through the same text generator as a stand-in, not the cache-sharing thread/sample) against behavior prompts:

Real app check

These results come from a dev server with a real Claude Haiku turn:

• After the agent said it hadn't picked where to store rate-limit counters, the suggestion was "Assume it's a single process for now. Which store would you pick for the counters?"
• With Security check selected, after the agent proposed an in-memory map, the next suggestion was "What happens if an attacker spreads guesses across many IPs against one username? Could they lock out the real user with this scheme?"

Settings showed "Recent suggestions took about 5 s".

Size and scope

The branch is on my fork: https://github.com/subhi229/t3code/tree/feat/custom-prompt-suggestions

It covers server, contracts, client-runtime, the web Labs panel, docs and the eval. Tests cover the service (watching, gating, continuation skip, cancellation by a newer run, late updates for older runs, one paid request per run, queued messages, project behavior, failures, per-model speed), session-manager gating, settings resolution and the behavior options. vp run check:changed passes.

Before posting, I had three models review the branch independently, and fixed what they agreed on between rounds:

One finding I left as is: when the suggestion model's provider is disabled for a project, it falls back to the text generation model the same way commit messages do. Changing that seems like a decision for all text generation, not this feature.

Happy to cut scope. For example, the first PR could drop custom behaviors and per-project overrides and keep only Source, Model and the presets. Which shape, if any, would you accept?

Thanks for shipping #28047. Suggest next prompt works well in my Claude and Codex threads.

Could OpenCode threads get it too? On v0.1.9, turning on the Labs toggle and restarting the app still gives no suggestions in OpenCode threads. From the source, only the Claude and Codex adapters produce one.

OpenCode doesn't seem to have a built-in prediction like Claude's promptSuggestions or Codex's thread/sample. If that's right, the "My model" source proposed in the last comment would also cover OpenCode, and any other provider without its own prediction.