Codex now predicts your next prompt. The useful default is still review

THE SIGNAL IN ONE SENTENCE

The next prompt can now arrive before you write it. OpenAI released composer predictions for Codex on October 9. After Codex finishes a response, the beta may place a suggested next message in the composer. Press Tab and the suggestion becomes editable text. It does not send. You can revise it, ignore it, replace it or turn the feature off. That last inch matters more than it looks. Developer tools keep removing friction from the path between an idea and an action. Autocomplete predicts a token. An assistant proposes a patch. An agent can run commands and use tools. Composer predictions move one step higher: they propose what the person might ask the agent to do next. This is not autonomy. It is interface steering. OpenAI says a prediction is based on the conversation in the current Codex thread. If context from earlier work, memory or connected apps is already present in that thread, it can shape the suggestion. The prediction system does not independently retrieve memories or query connected apps. It can also skip a suggestion entirely. That boundary is useful. It is also easy to misunderstand. A suggested prompt can feel like a neutral continuation because it appears in the place where the user normally writes. It may be sensible. It may save a few seconds. It may also carry forward an assumption that should have been challenged, turn a tentative idea into an imperative or invite a larger action than the user intended. The prediction has a privileged seat. It arrives first. OpenAI's safest design choice is the one most likely to be overlooked: accepting the suggestion does not send it. The text pauses in the composer for review. That gives the user a chance to inspect the object, scope, verb and implied permission before any normal Codex work begins. Think of the difference between these instructions: Review the failing test. Fix the failing test. Fix the test and update the dependency. Fix the test, update the dependency and deploy. Each line feels like a plausible next step after the previous one. Each line grants more authority. A model that predicts conversational momentum can produce a smooth escalation without knowing whether the person intended it. The right question is not whether the suggestion sounds natural. It is whether the suggested action matches the user's current goal, evidence and permission boundary. Start with the verb. Words such as inspect, explain, compare and draft generally preserve room for review. Words such as edit, install, delete, merge, deploy, message and publish can change files or external systems. A suggestion that crosses from observation into action should be treated as a new decision, even when it feels like the obvious continuation. Then inspect the object. Which repository, branch, environment, file, account or service would the message affect? A thread may contain several projects, copied logs or references to connected apps. A short suggestion can leave the target implicit. The person accepting it may fill in the blank differently from the system that generated it. Then inspect the scope. "Fix it" may mean one line, one test, every related file or the underlying configuration. "Send the update" may mean drafting a note or posting it to a public channel. Small pronouns are excellent hiding places for large consequences. Finally, inspect the evidence. A prediction can continue the conversation's framing even when the framing is wrong. If the previous answer misdiagnosed the bug, the next suggested prompt may efficiently deepen the mistake. If a requirement changed elsewhere and that change is not in the thread, the suggestion cannot account for it. If the thread includes stale context, the prediction may be coherent and obsolete at the same time. This is why reviewing the words is not merely copyediting. It is a compact control surface for intent. The beta is narrow at launch. OpenAI says it is available to adults using personal ChatGPT Pro accounts in supported regions, in the latest Codex desktop app. It works in local and SSH threads with GPT-6 Astra or GPT-6.1 Sol. The feature is on by default for eligible users and can be disabled under General, then Composer, then Show predictions. Predictions may take several seconds, especially in long conversations, and they do not appear after every response. Users do not need to wait. They can simply start typing. During the beta, generating predictions does not count toward Codex usage limits or consume credits. A message sent from an accepted prediction is an ordinary Codex message and follows normal usage limits and billing. Those are product facts. They are not evidence of benefit. OpenAI has not published acceptance rates, edit rates, error rates, task-completion gains or controlled productivity results for the feature. The company has not said how often suggestions propose actions beyond the user's intent, how quality changes in long threads or whether default-on predictions measurably improve outcomes. Keystrokes saved would be the weakest useful metric. Teams testing composer predictions should measure the full path from suggestion to consequence. How often does a prediction appear? How often is it accepted unchanged, accepted and edited, ignored or followed by a completely different message? Which verbs appear in accepted suggestions? Do suggestions increase the size of requested changes? How often does a user reverse the resulting work? The most important measurements are not clicks. They are correction and regret. Track whether accepted suggestions preserve the stated goal, point to the right target, respect the current branch and environment, retain explicit tests and approvals, and produce work the user keeps. Compare predicted follow-ups with manually written ones on similar tasks. Look for differences in rollback, rework and accidental scope expansion. Do not turn that evaluation into surveillance. Prompt text can contain proprietary code details, customer names, incident information and private intentions. A workplace study should minimize collection, remove sensitive content where possible, publish a clear retention period and report aggregate patterns rather than building a new dossier on individual developers. The purpose is to test an interface, not to grade employees on how often they disagree with it. Disagreement is valuable data. An ignored suggestion may mean the feature was wrong. It may mean the user changed direction. It may mean the prompt was fine but arrived too late. It may mean the person wanted to think without a sentence already waiting in the box. Those cases should not be collapsed into failure or resistance. Default-on design deserves particular scrutiny because defaults create behavior before users form an opinion. An eligible person who does nothing receives predictions. Someone who finds them distracting has to locate the setting and turn them off. That can be reasonable for a lightweight beta with a clear off switch. It still creates a responsibility to make the state visible. Users should know when text is predicted, when it has been accepted into the composer and when it remains unsent. The interface should never make generated text resemble text the user already authored. Accessibility belongs in the same review. A Tab shortcut may be fast for some users and conflict with navigation patterns for others. Suggestions that appear after a delay can shift focus or add visual noise. Keyboard, screen-reader and reduced-motion behavior should be tested as product behavior, not treated as polish. Long threads are another pressure point. OpenAI says predictions may take longer there. Long threads also accumulate abandoned ideas, corrected assumptions and multiple phases of work. A prediction model must infer which part of the conversation is still active. The older the thread, the more likely a fluent continuation is not the right continuation. A practical habit is to rewrite accepted predictions into four visible parts: Goal: what result do I want? Scope: which files, systems or people are included? Limits: what must not happen without another approval? Proof: what test or evidence will show the work is complete? That sounds heavier than pressing Tab. It need not be. For a low-risk question, the suggestion may already be enough. For an action that writes, publishes, deploys or contacts someone, ten seconds of explicit scope is cheap. Product teams can help by grading suggestions according to consequence. A predicted request to explain a function does not need ceremony. A predicted request to delete data should arrive with the target, reversibility and approval boundary made unmistakable. The more consequential the verb, the more specific the suggestion should become. There is also a healthy product opportunity here. The best next-prompt system may not be the one that predicts a single sentence most confidently. It may offer useful forks. Inspect the change. Run the narrow tests. Prepare a patch for review. Stop here. Those alternatives expose choice instead of manufacturing inevitability. They can help a developer see that continuing is only one option and that a smaller step may produce better evidence. OpenAI's current design already preserves the essential break in the chain. Tab accepts text. The user still sends it. Codex then applies the normal permissions, approvals and execution controls for whatever message was chosen. Keep that separation. Prediction should reduce blank-box friction, not collapse intention into action. The model can propose the sentence. The person should still decide whether the sentence is true, current, bounded and worth sending. The useful default is review because the next prompt is not merely language. It is the next grant of authority.