Repository navigation
Android Remote reasoning-effort mismatch: mobile Max/Ultra appears as Medium on Windows Desktop #42301
Description
Summary
There appears to be a reasoning-effort synchronization or representation mismatch between ChatGPT Android Remote and Codex Desktop on Windows when using GPT-5.6 Sol.
On Android Remote, I can select the highest mobile reasoning mode shown by the client (for example Max / Ultra, depending on the UI wording). After the task is handed to the Windows Codex host, the corresponding Desktop session can show the reasoning level as Medium.
The problem is that the product does not expose the effective reasoning effort actually used for the turn, so from the UI alone I cannot determine which of these is happening:
- Android really sends the higher reasoning effort, but Windows Desktop cannot represent that value and displays
Mediumincorrectly. - The unsupported or differently named mobile value is actually downgraded to
Mediumsomewhere in the Remote/app-server path. - Android and Desktop are mapping the same effective reasoning state to different UI labels.
This matters because the user may believe a task is running at the highest reasoning effort while the Desktop appears to indicate Medium, with no authoritative per-turn value available to verify which is correct.
Environment
- Remote controller: ChatGPT for Android
1.2026.237 - Android: 16
- Host: Windows Codex / ChatGPT Desktop
- Model: GPT-5.6 Sol
- Exact current Windows Desktop build was not captured for this report and can be added if required.
Reproduction
- Connect ChatGPT Android to a Windows Codex host through Remote Control.
- Start or continue a Codex task using GPT-5.6 Sol.
- On Android, explicitly select the highest available reasoning mode (
Max/Ultra, depending on the mobile UI wording). - Submit the task to the Windows host.
- Open/inspect the same task on Windows Desktop.
- Observe that the Desktop can show the reasoning effort as
Mediumrather than the higher setting selected on Android.
Control observation
Using Very High / Extra High (xhigh) appears to be safer because both mobile and Desktop recognize that level consistently. The ambiguity is specifically with the higher mobile mode / label and its mapping across Remote.
Expected behavior
Remote should preserve the selected reasoning effort end-to-end, and both clients should expose the same effective value.
Ideally, the product should expose the effective per-turn reasoning effort returned/accepted by the host or model runtime, rather than only the local selector state. For example, a turn/session diagnostic could distinguish:
- requested reasoning effort;
- normalized/mapped effort;
- effective effort actually used for the turn.
If a mobile-only value is unsupported by the Windows host/app-server, the client should show an explicit downgrade or incompatibility message rather than silently displaying or executing Medium.
Why this is distinct / related
This looks related to existing reasoning-effort propagation bugs, especially:
- Codex iOS remote task on Windows 26.527 ignores xhigh and starts gpt-5.5 medium #25583 — iOS Remote task on Windows selected
xhighbut the Windows session started asmedium. - Codex Desktop reasoning level resets from xhigh/high to low in the same active thread after delegations/continuations #26930 — reasoning effort can reset unexpectedly inside Codex Desktop.
The current report is specifically about Android Remote + GPT-5.6 Sol + highest mobile reasoning mode, and asks whether the observed Medium on Desktop is only a UI representation mismatch or an actual reasoning-effort downgrade.
No task IDs, account identifiers, host identifiers, local paths, or private conversation content are included.
Activity
cesariveiro-lang commentedon Sep 2, 2026
User-impact / trust concern
This mismatch is particularly frustrating in Remote because the mobile UI actively presents the higher reasoning mode as a meaningful choice. When selecting
Ultra/ the highest available mode on the phone, the UI indicates that it will use more reasoning / consume more resources, which implies that the user is explicitly opting into a more expensive, deeper reasoning path.But after handing the task to the Windows host, none of that is reflected consistently on Desktop:
Mediuminstead;That leaves the user with no trustworthy way to answer a basic question: is this task really running at the maximum / Ultra reasoning level I selected and was warned would consume more, or was it silently mapped/downgraded to Medium?
For a paid product, this is a confidence problem, not just a cosmetic UI inconsistency. I am paying more than €200/month for the service, and the Remote experience makes it impossible to verify that the higher reasoning level I explicitly selected is actually what the host/model is using.
What would restore confidence here is an authoritative per-turn diagnostic visible on both mobile and Desktop, for example:
Without that, the user is being asked to trust a cross-device control whose effective value is not observable anywhere.
cesariveiro-lang commentedon Sep 2, 2026
Additional trust / billing transparency concern
The main problem here is not only that the labels differ across Android Remote and Windows Desktop. It is that the product visibly charges the cost side of the higher mode while providing no authoritative evidence for the service side.
On Android, selecting the highest mode warns that it will consume more quota/credits. In practice, usage does appear to drain faster. However, on the Windows host the same task can still appear as
Medium, there is no equivalentUltra/Maxselector, and neither the Desktop UI nor Codex itself can report the effective reasoning effort actually used for that turn.So from the user's perspective the situation is:
For a subscription costing more than €200/month, this is a serious confidence problem. I am not alleging incorrect billing; the problem is that the product gives the user no way to verify that the increased quota consumption corresponds to the requested higher reasoning service.
Please expose an authoritative per-turn diagnostic such as:
requested effort -> normalized effort -> effective effortIf the requested level cannot be honored by the Remote host/runtime, the client should explicitly report the downgrade before or during execution rather than leaving the user to infer it from inconsistent UI labels and quota consumption.
cesariveiro-lang commentedon Sep 2, 2026
Broader Pro reliability / transparency context
I want to add broader context because this reasoning-effort mismatch is not occurring in isolation. I am a ChatGPT Pro subscriber paying €229/month, using ChatGPT, Codex Remote and Work heavily for ongoing technical work.
Current environment:
1. Max / Ultra reasoning is not verifiable end-to-end
This is the core issue reported here. Android can offer the highest reasoning mode and explicitly warn that it consumes more quota/credits, while the corresponding Windows Codex session can display
Medium. Windows does not expose an equivalent Max/Ultra selector, and neither Codex nor support currently exposes an authoritative per-turn value showing what reasoning effort was actually used.The practical trust problem is therefore:
higher-cost reasoning selected on Android -> visibly higher quota consumption -> Desktop may show Medium -> no authoritative effective-effort field existsI am not claiming incorrect billing. I am asking for verifiability: ideally the product should expose
requested effort -> normalized effort -> effective effort, and explicitly report any downgrade or unsupported mapping.2. Codex Remote is persistently unstable during normal use
This is documented separately in #39954. Remote can be fully usable, then disconnect repeatedly during an active session while the Windows Codex job itself continues running. A common recovery is simply:
Remote works -> disconnects -> back out to Remote -> reopen the same host/thread -> works again -> disconnects again laterNo pairing, network, enrollment, Desktop or configuration change is required for the recovery. The cycle can repeat constantly, which makes Remote usable but unreliable for sustained supervision/control.
3. ChatGPT Android long-reasoning responses can arrive very late and out of sequence
In ordinary ChatGPT use, especially with Think longer / Pro reasoning, I sometimes wait around two minutes or receive an apparent error and continue the conversation. Several minutes later, a notification can suddenly deliver the old requested response after the conversation has already advanced several messages.
Observed pattern:
high-reasoning request -> long wait / apparent error -> continue conversation -> old response arrives minutes later out of conversational orderThe UI gives no clear indication whether the original turn really failed, is still running in the background, or will arrive later.
4. Already-visible ChatGPT responses can temporarily disappear
Responses that were already rendered in the Android conversation sometimes disappear from the transcript. Closing and reopening the app often makes them reappear. This is not 100% reproducible, but it happens often enough to undermine confidence in conversation-state synchronization.
5. Work / browser reliability is also poor in my usage
The Work experience is frequently unreliable for me, especially around browser-based work where browser sessions can become blocked/stuck and require recovery. This is a quality/reliability complaint rather than a claim that the entitlement is absent, but it contributes to the overall Pro experience.
6. "Unlimited main chat" still has a hard per-conversation maximum length
The Pro plan UI shown to me advertises "Unlimited main chat" and "Maximum memory and context". I have a long-running master work conversation that eventually became non-continuable with the exact message:
I understand this is not the same as exhausting the overall Pro usage quota: ChatGPT remains usable in a new chat. So I am not claiming that overall Pro chat access is blocked.
The transparency issue is that an individual Pro conversation has a hard maximum length that can force a long-running work thread to be abandoned, while the sales UI says "Unlimited main chat". It would be useful for OpenAI to document clearly what "unlimited" means, what the per-conversation maximum is, and where that limit is disclosed before the user reaches it.
Why I am adding this here
The common concern across these incidents is state fidelity and verifiability across clients. The user-visible UI can disagree with the underlying or remote state, arrive late, disappear and reappear, or expose a higher-cost option without exposing the effective value actually used.
For a €229/month Pro subscription, this materially reduces confidence in the product. I would appreciate both a technical clarification on the Max/Ultra -> Medium mismatch and, more broadly, improvements that expose authoritative state rather than forcing users to infer it from inconsistent client UIs.