[Critical][Codex App] GPT-5.6 Sol is catalog-capped at 372K (353.4K effective) vs the 1.05M model spec

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.707.30751 (bundle build 5018), bundled CLI codex-cli 0.144.0-alpha.4, model catalog client version 0.144.0.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Darwin 27.0.0 arm64 arm

macOS 27.0 (26A5378j), Apple Silicon.

What issue are you seeing?

Codex currently gives gpt-5.6-sol threads a 353,400-token effective context window even though the public GPT-5.6 Sol API model specification advertises a 1,050,000-token context window.

This is not only a UI rounding problem. The freshly fetched, server-provided Codex model catalog contains the following metadata for gpt-5.6-sol:

{
  "context_window": 372000,
  "max_context_window": 372000,
  "effective_context_window_percent": 95,
  "auto_compact_token_limit": null
}

Codex core therefore computes and uses this effective window:

372,000 * 0.95 = 353,400

App Server exposes model_context_window: 353400 in the thread's task_started and subsequent token-usage events, and the Codex App displays a total window of approximately 353k.

With auto_compact_token_limit absent, Codex derives the default compaction threshold from 90% of the raw catalog window:

372,000 * 0.90 = 334,800

No context-window, auto-compaction, project-level, environment-variable, or provider override is configured locally. The catalog was freshly fetched with a current ETag, so this does not appear to be stale local metadata.

The current evidence establishes a Codex catalog/runtime cap. It does not claim that the upstream model endpoint itself rejects inputs above 372,000 tokens.

What steps can reproduce the bug?

Use the Codex App version above with the official openai provider and a ChatGPT Pro account.
Select gpt-5.6-sol and start a fresh local thread.
Open the context-window indicator. Codex reports a total usable window of approximately 353k tokens.
Inspect the gpt-5.6-sol entry in ~/.codex/models_cache.json; observe context_window: 372000, max_context_window: 372000, and effective_context_window_percent: 95.
Inspect the sanitized thread metadata; observe task_started.model_context_window: 353400 and the same value in subsequent token-usage events.

What is the expected behavior?

The public API model specification lists a 1,050,000-token context window for GPT-5.6 Sol:

https://developers.openai.com/api/docs/models/gpt-5.6-sol

Absent a documented Codex-specific preview cap, the Codex catalog should match that raw model window or clearly disclose the product-specific limit. With the same 95% effective-window policy, a 1,050,000-token raw window would imply approximately 997,500 usable tokens:

1,050,000 * 0.95 = 997,500

The current 353,400-token effective budget is only about 35.4% of the effective window implied by the published API model specification, a reduction of about 64.6%. The derived 334,800-token default compaction threshold is only about 31.9% of the published 1.05M raw window.

Additional information

Codex computes the effective window from the resolved catalog metadata and effective_context_window_percent:

codex/codex-rs/core/src/session/turn_context.rs

Lines 195 to 202 in 2c85975

    
           pub(crate) fn model_context_window(&self) -> Option<i64> { 
        
               let effective_context_window_percent = self.model_info.effective_context_window_percent; 
        
               self.model_info 
        
                   .resolved_context_window() 
        
                   .map(|context_window| { 
        
                       context_window.saturating_mul(effective_context_window_percent) / 100 
        
                   }) 
        
           }

The protocol defines the effective percentage and derives the default compaction limit when no explicit limit is supplied:

codex/codex-rs/protocol/src/openai_models.rs

Lines 348 to 406 in 2c85975

    
           const fn default_effective_context_window_percent() -> i64 { 
        
               95 
        
           } 
        
           /// Model metadata returned by the Codex backend `/models` endpoint. 
        
           #[derive(Debug, Serialize, Deserialize, Clone, PartialEq, Eq, TS, JsonSchema)] 
        
           pub struct ModelInfo { 
        
               pub slug: String, 
        
               pub display_name: String, 
        
               pub description: Option<String>, 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub default_reasoning_level: Option<ReasoningEffort>, 
        
               pub supported_reasoning_levels: Vec<ReasoningEffortPreset>, 
        
               pub shell_type: ConfigShellToolType, 
        
               pub visibility: ModelVisibility, 
        
               pub supported_in_api: bool, 
        
               pub priority: i32, 
        
               #[serde(default)] 
        
               pub additional_speed_tiers: Vec<String>, 
        
               #[serde(default)] 
        
               pub service_tiers: Vec<ModelServiceTier>, 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub default_service_tier: Option<String>, 
        
               pub availability_nux: Option<ModelAvailabilityNux>, 
        
               pub upgrade: Option<ModelInfoUpgrade>, 
        
               pub base_instructions: String, 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub model_messages: Option<ModelMessages>, 
        
               #[serde(default)] 
        
               pub include_skills_usage_instructions: bool, 
        
               pub supports_reasoning_summaries: bool, 
        
               #[serde(default)] 
        
               pub default_reasoning_summary: ReasoningSummary, 
        
               pub support_verbosity: bool, 
        
               pub default_verbosity: Option<Verbosity>, 
        
               pub apply_patch_tool_type: Option<ApplyPatchToolType>, 
        
               #[serde(default)] 
        
               pub web_search_tool_type: WebSearchToolType, 
        
               pub truncation_policy: TruncationPolicyConfig, 
        
               pub supports_parallel_tool_calls: bool, 
        
               #[serde(default)] 
        
               pub supports_image_detail_original: bool, 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub context_window: Option<i64>, 
        
               /// Maximum context window allowed for config overrides. 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub max_context_window: Option<i64>, 
        
               /// Token threshold for automatic compaction. When omitted, core derives it 
        
               /// from `context_window` (90%). When provided, core clamps it to 90% of the 
        
               /// context window when available. 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub auto_compact_token_limit: Option<i64>, 
        
               /// Opaque identifier for compaction-compatible model configurations. 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub comp_hash: Option<String>, 
        
               /// Percentage of the context window considered usable for inputs, after 
        
               /// reserving headroom for system prompts, tool overhead, and model output. 
        
               #[serde(default = "default_effective_context_window_percent")] 
        
               pub effective_context_window_percent: i64,

codex/codex-rs/protocol/src/openai_models.rs

Lines 436 to 451 in 2c85975

    
           impl ModelInfo { 
        
               pub fn resolved_context_window(&self) -> Option<i64> { 
        
                   self.context_window.or(self.max_context_window) 
        
               } 
        
               pub fn auto_compact_token_limit(&self) -> Option<i64> { 
        
                   let context_limit = self 
        
                       .resolved_context_window() 
        
                       .map(|context_window| (context_window * 9) / 10); 
        
                   let config_limit = self.auto_compact_token_limit; 
        
                   if let Some(context_limit) = context_limit { 
        
                       return Some( 
        
                           config_limit.map_or(context_limit, |limit| std::cmp::min(limit, context_limit)), 
        
                       ); 
        
                   } 
        
                   config_limit

App Server exposes the computed model context window through the thread token-usage protocol:

codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs

Lines 1372 to 1395 in 2c85975

    
           pub struct ThreadTokenUsageUpdatedNotification { 
        
               pub thread_id: String, 
        
               pub turn_id: String, 
        
               pub token_usage: ThreadTokenUsage, 
        
           } 
        
           #[derive(Serialize, Deserialize, Debug, Clone, PartialEq, JsonSchema, TS)] 
        
           #[serde(rename_all = "camelCase")] 
        
           #[ts(export_to = "v2/")] 
        
           pub struct ThreadTokenUsage { 
        
               pub total: TokenUsageBreakdown, 
        
               pub last: TokenUsageBreakdown, 
        
               // TODO(aibrahim): make this not optional 
        
               #[ts(type = "number | null")] 
        
               pub model_context_window: Option<i64>, 
        
           } 
        
           impl From<CoreTokenUsageInfo> for ThreadTokenUsage { 
        
               fn from(value: CoreTokenUsageInfo) -> Self { 
        
                   Self { 
        
                       total: value.total_token_usage.into(), 
        
                       last: value.last_token_usage.into(), 
        
                       model_context_window: value.model_context_window, 
        
                   }

The practical impact is severe for repository-scale analysis, long-running agentic coding sessions, large specifications, tool-heavy workflows, and multi-agent coordination because Codex begins managing context pressure at roughly one third of the published raw model capacity.

Related but not duplicate reports:

GPT-5.5 context window oscillates between 258400 and 353400 effective tokens in Codex Desktop #30875 reports GPT-5.5 catalog/runtime context-window oscillation involving the same 353,400-token value.
Support 1M token context for GPT-5.5 in Codex #19464 and Reopen #19464 and support 1M context #30910 request larger GPT-5.5 Codex windows but do not report this GPT-5.6 Sol catalog mismatch against the published 1.05M specification.

Please confirm whether the 372,000-token Codex cap is intentional. If it is not, the gpt-5.6-sol catalog metadata should expose the correct raw and maximum context window. If it is intentional, Codex should document the product-specific limit clearly instead of presenting 353,400 as the model's context window without explanation.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Reopen #19464 and support 1M context #30910

Powered by Codex Action

Pretty much the same as it was for GPT 5.5. Let me add some weight here:
It is a critical miss on Open AI's side to release a model like SOL with a 300k tokens context window. Literally: what is the point? Below 1M as useless as it gets for a frontier model.

ChatGPT Pro user here. This 372K catalog cap (353.4K effective) on GPT-5.6 Sol is a hard blocker for my work.

I verified it locally: overriding the client catalog/context to 1.05M, disabling Responses Lite, and switching from WebSocket to HTTP all still produced a server-side context-window error at 380,005 input tokens. So this is not a UI or client accounting issue.

I specifically need a true ~1M context window on the current top model inside Codex under the ChatGPT subscription. API-only 1.05M access does not solve the subscription use case. If this remains capped, I will move long-context work to Claude Code.

Please align Codex Pro with GPT-5.6 Sol's advertised 1.05M window, or publish a concrete rollout timeline.

gpt 5.5 in codex with 400k context window is Ok because now we have gpt 5.6
gpt 5.6 in codex with 372k (holy how could it be even less than gpt 5.5 's) context window is NOT Ok because we haven't gpt 6, while claude code with Opus supports 1M long time ago!

fix(codex): GPT-5.6 context window 1_050_000 -> 372_000 (ruling on ch…

Update model docs for GPT-5.6 family, Sonnet 5, Gemini 3.1/3.5; bump …

Update (July 13): this appears to have regressed further. With Codex CLI 0.144.1 and a freshly fetched model catalog, gpt-5.6-sol now reports

context_window=272000
max_context_window=272000
effective_context_window_percent=95

... yielding 258400 effective tokens.

On July 9, the same setup reported 372000 -> 353400 effective tokens. codex debug models and app-server usage agree, so this is not a client display issue.

Is the 272K Codex subscription cap intentional, and if so, where is it documented?

Update (July 13): this appears to have regressed further. With Codex CLI 0.144.1 and a freshly fetched model catalog, gpt-5.6-sol now reports

context_window=272000
max_context_window=272000
effective_context_window_percent=95

... yielding 258400 effective tokens.

On July 9, the same setup reported 372000 -> 353400 effective tokens. codex debug models and app-server usage agree, so this is not a client display issue.

Is the 272K Codex subscription cap intentional, and if so, where is it documented?

Same issue appeared today for me - PRO subscription on win11 app - Poland.

feat(codex): declare gpt-5.6 context window for Claude Code takeover

Feat/copilot gpt56 1m max (#2)

fix(claudex): [1m] を外し compact 窓をバックエンドのキャップ内に収める (#811)

feat(codex): declare gpt-5.6 context window for Claude Code takeover

+1

99% of long horizon work has become waiting on compacting.

+1 its been weeks since Tibo says they will bring back the 373k context window... It is completely unacceptable.

Additional current evidence: Windows, ChatGPT Pro, Codex 0.146

I can reproduce the same issue on the current Windows Codex Desktop build after a full application restart.

Environment:

Codex Desktop package: 26.721.4979.0
Bundled CLI: codex-cli 0.146.0-alpha.3.1
Platform: Windows x86_64
Authentication: ChatGPT Pro
Model: gpt-5.6-sol, reasoning xhigh

Freshly downloaded model catalog after restart:

context_window: 272000
max_context_window: 272000
effective_context_window_percent: 95

Fresh turn telemetry reports:

task_started.model_context_window: 258400

This exactly matches 272000 * 95% = 258400.

I also tested the documented top-level override:

model_context_window = 1050000

The setting remains present and config validation succeeds, but it is clamped by the server-delivered max_context_window of 272000. The running thread therefore remains at 258400.

For diagnosis, temporarily changing the local catalog context_window and max_context_window to 1050000 caused a fresh session to report 997500 effective tokens. After restarting Codex, the remote catalog was downloaded again, restored both values to 272000, and the runtime returned to 258400. This demonstrates that the restriction is imposed by the current Codex catalog and is not a UI rounding problem or a malformed local configuration.

The official GPT-5.6 Sol page still documents a 1,050,000-token context window: https://developers.openai.com/api/docs/models/gpt-5.6-sol

Please clarify whether 272000 is an intentional Codex product limit for ChatGPT Pro. If intentional, disclose it explicitly in the model picker and plan documentation. If not intentional, please correct max_context_window in the server-delivered Codex catalog so the documented override and the published model capacity can be used.

I hit this while running an endurance test against the Codex backend. A connectivity probe measured the actual accepted context size for the subscription endpoint (chatgpt.com/backend-api/codex/responses):

gpt-5.6-sol / -terra / -luna, gpt-5.5, gpt-5.4: 370,013 tokens accepted, 374,000 rejected with context_length_exceeded
gpt-5.4-mini: 250,000 accepted, 300,000 rejected

Token counts are the provider's own usage.input_tokens, not client-side estimates, and the rejections reproduce.

The same models accept 600,007 tokens through api.openai.com/v1/responses, so this is a limit imposed by the subscription transport, not
the model. That distinction isn't documented anywhere I could find — the published figure is the 1,050,000 model window, and the error
message is a generic context_length_exceeded that doesn't state the actual ceiling.

By comparison, Anthropic and Moonshot both return the limit in the error text (prompt is too long: 1050081 tokens > 1000000 maximum, exceeded model token limit: 262144), which makes it trivial to configure a client correctly. Including the effective cap in the Codex error would save a lot of guessing.

Apparently openai doesn't care about us and is forcing us to give up gpt 5.6, for after 2 weeks there is still no proper answer or solution.

Just spawn 6 subagents and pray for your ctx window. As it stands, I believe this is to squash any real viability on mainstream Hermes/openclaw. By the time you get to actual work, it ends up in a death loop of context compaction.

…

On Mon, Aug 3, 2026 at 8:29 AM akakoori ***@***.***> wrote: *akakoori* left a comment (openai/codex#31860) <#31860 (comment)> Apparently openai doesn't care about us and is forcing us to give up gpt 5.6, for after 2 weeks there is still no proper answer or solution. — Reply to this email directly, view it on GitHub <#31860?email_source=notifications&email_token=ABT3VEK5BPAKU3I2H4CKCRD5ICATNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJWGYZTCMBXGYZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5166310762>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABT3VEIZJSMCBFQGBKPRJLT5ICATNAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIOBUHEYDQMZQGA22C5QC> . You are receiving this because you commented.Message ID: ***@***.***>

feat(codex): declare gpt-5.6 context window for Claude Code takeover

feat(models): offer GPT-5.6 Sol at the 1M context window OpenAI docum…

fix(chatgpt_oauth): budget context from the Codex catalog, not the AP…

feat(ollama-cloud): generate codex model catalog for the curated models

fix: claudex の context window を 872K に引き上げ、feedbackDrafts を off にする (#…

feat(codex): declare gpt-5.6 context window for Claude Code takeover

Navigation Menu

Repository navigation

[Critical][Codex App] GPT-5.6 Sol is catalog-capped at 372K (353.4K effective) vs the 1.05M model spec #31860

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

2 remaining items

Additional current evidence: Windows, ChatGPT Pro, Codex 0.146

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	pub(crate) fn model_context_window(&self) -> Option<i64> {
	let effective_context_window_percent = self.model_info.effective_context_window_percent;
	self.model_info
	.resolved_context_window()
	.map(\|context_window\| {
	context_window.saturating_mul(effective_context_window_percent) / 100
	})
	}

	const fn default_effective_context_window_percent() -> i64 {
	95
	}

	/// Model metadata returned by the Codex backend `/models` endpoint.
	#[derive(Debug, Serialize, Deserialize, Clone, PartialEq, Eq, TS, JsonSchema)]
	pub struct ModelInfo {
	pub slug: String,
	pub display_name: String,
	pub description: Option<String>,
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub default_reasoning_level: Option<ReasoningEffort>,
	pub supported_reasoning_levels: Vec<ReasoningEffortPreset>,
	pub shell_type: ConfigShellToolType,
	pub visibility: ModelVisibility,
	pub supported_in_api: bool,
	pub priority: i32,
	#[serde(default)]
	pub additional_speed_tiers: Vec<String>,
	#[serde(default)]
	pub service_tiers: Vec<ModelServiceTier>,
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub default_service_tier: Option<String>,
	pub availability_nux: Option<ModelAvailabilityNux>,
	pub upgrade: Option<ModelInfoUpgrade>,
	pub base_instructions: String,
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub model_messages: Option<ModelMessages>,
	#[serde(default)]
	pub include_skills_usage_instructions: bool,
	pub supports_reasoning_summaries: bool,
	#[serde(default)]
	pub default_reasoning_summary: ReasoningSummary,
	pub support_verbosity: bool,
	pub default_verbosity: Option<Verbosity>,
	pub apply_patch_tool_type: Option<ApplyPatchToolType>,
	#[serde(default)]
	pub web_search_tool_type: WebSearchToolType,
	pub truncation_policy: TruncationPolicyConfig,
	pub supports_parallel_tool_calls: bool,
	#[serde(default)]
	pub supports_image_detail_original: bool,
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub context_window: Option<i64>,
	/// Maximum context window allowed for config overrides.
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub max_context_window: Option<i64>,
	/// Token threshold for automatic compaction. When omitted, core derives it
	/// from `context_window` (90%). When provided, core clamps it to 90% of the
	/// context window when available.
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub auto_compact_token_limit: Option<i64>,
	/// Opaque identifier for compaction-compatible model configurations.
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub comp_hash: Option<String>,
	/// Percentage of the context window considered usable for inputs, after
	/// reserving headroom for system prompts, tool overhead, and model output.
	#[serde(default = "default_effective_context_window_percent")]
	pub effective_context_window_percent: i64,

	impl ModelInfo {
	pub fn resolved_context_window(&self) -> Option<i64> {
	self.context_window.or(self.max_context_window)
	}

	pub fn auto_compact_token_limit(&self) -> Option<i64> {
	let context_limit = self
	.resolved_context_window()
	.map(\|context_window\| (context_window * 9) / 10);
	let config_limit = self.auto_compact_token_limit;
	if let Some(context_limit) = context_limit {
	return Some(
	config_limit.map_or(context_limit, \|limit\| std::cmp::min(limit, context_limit)),
	);
	}
	config_limit

	pub struct ThreadTokenUsageUpdatedNotification {
	pub thread_id: String,
	pub turn_id: String,
	pub token_usage: ThreadTokenUsage,
	}

	#[derive(Serialize, Deserialize, Debug, Clone, PartialEq, JsonSchema, TS)]
	#[serde(rename_all = "camelCase")]
	#[ts(export_to = "v2/")]
	pub struct ThreadTokenUsage {
	pub total: TokenUsageBreakdown,
	pub last: TokenUsageBreakdown,
	// TODO(aibrahim): make this not optional
	#[ts(type = "number \| null")]
	pub model_context_window: Option<i64>,
	}

	impl From<CoreTokenUsageInfo> for ThreadTokenUsage {
	fn from(value: CoreTokenUsageInfo) -> Self {
	Self {
	total: value.total_token_usage.into(),
	last: value.last_token_usage.into(),
	model_context_window: value.model_context_window,
	}

[Critical][Codex App] GPT-5.6 Sol is catalog-capped at 372K (353.4K effective) vs the 1.05M model spec #31860

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 9, 2026

tobiu commented on Jul 9, 2026

StulkovLD commented on Jul 9, 2026

akakoori commented on Jul 10, 2026

anthrotype commented on Jul 13, 2026

qbawu commented on Jul 13, 2026

2 remaining items

kaykayyali commented on Jul 25, 2026

t04dJ14n9 commented on Jul 27, 2026

Asdar15 commented on Jul 29, 2026

Additional current evidence: Windows, ChatGPT Pro, Codex 0.146

steven-varga commented on Aug 3, 2026

akakoori commented on Aug 3, 2026

kaykayyali commented on Aug 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions