You ask why a test is failing. The assistant explains, then offers to write your next request for you. If you were about to say “fix that and run it again,” the convenience is easy to appreciate. If you only wanted an explanation, there is a small detour waiting beside the Tab key.
OpenAI announced Composer predictions on October 9. The beta serves personal ChatGPT Pro users aged 18+ in supported regions, through the latest Codex desktop app, with GPT-6 Astra or GPT-6.1 Sol in local and SSH threads. Generating predictions costs no credits or usage allowance during beta; sending messages follows normal billing and limits.
The feature suggests a whole next message after a response, rather than completing words as you type. Tab accepts; sending remains separate. It excludes Chat, though local Work conversations may show predictions. Suggestions can be absent or delayed. They’re enabled by default; General → Composer → Show predictions disables them.
We haven’t tested this beta. What follows is an analysis of the design, with hypothetical examples of where it could help and where a little hesitation would be healthy.
Suppose you ask a coding assistant why a test fails. It explains the problem. You were already about to ask it to make a narrow fix and run the test again. If a proposed message captures that request accurately, the appeal is obvious. Your hands have been spared a small, repetitive job.
On an afternoon of small corrections, that could save more than keystrokes. Each follow-up takes attention away from the code while you turn an intention into an instruction. A suggestion that gets it right lets you stay with the problem a little longer.
It could also make a vague instruction more precise. Perhaps you were going to write “fix it,” then notice that a suggested follow-up names the broken test. Reading a possible instruction can help you work out what you really want. That is a worthwhile use even if you discard most of the sentence.
The catch is in requests that sound reasonable enough to accept before you notice what they leave out.
The missing restriction
Imagine the same broken test in a project you are only reviewing. A repair might be technically sensible, but your job this morning is to explain the failure to someone else. Or perhaps you want a fix, provided it leaves a fragile dependency alone. That condition may be the most important part of the request.
A sensible next step can still be the wrong next step for you.
A well-written sentence can also add work: change another file, tidy a neighbouring function, tackle a second issue. Each might be worthwhile, but together they turn a five-minute question into a larger commission. The suggestion needs the same scope check as a request you wrote yourself.
That is a risk to examine in use, not a finding about this beta. The release notes cannot tell us whether people preserve important restrictions when accepting a proposed follow-up. A trial would need to look at the resulting work as well as the number of times someone presses Tab.
Read the verb
For anyone trying the beta, a useful habit would be to look first at the action being proposed. Explain, inspect, edit and publish carry very different consequences. Then check the boundary: which file, which change, how far?
A good trial would measure whether the suggestion helps you reach the result you had in mind, including time spent correcting unwanted detours. Counting accepted suggestions alone would miss that distinction.
Typing less is useful. Having less to undo is better.
A prediction earns its place when you read it and recognize the request you meant to make. When you do not, editing or ignoring it is part of using the feature well.
Got a different take? I’d love to hear it. hello@maisfps.com
