Memory jobs inherit the interactive thread's Fast Mode / priority service tier #32429

What issue are you seeing?

Background memory extraction and consolidation jobs can inherit the foreground thread's Fast Mode / priority service tier.

Memory maintenance is background work and should use the default service tier unless a memory-specific tier has been explicitly configured. Inheriting priority unexpectedly increases usage for requests the user did not intentionally accelerate.

The two memory stages currently inherit the tier through different configuration paths:

• Phase 1 reads the live thread configuration snapshot and copies its service_tier into StageOneRequestContext.
• Phase 2 clones the thread's original Config, including its service_tier, when creating the consolidation agent.

The phase-1 request builder filters the tier against the selected extraction model. The default extraction model, gpt-5.4-mini, currently advertises no accelerated service tier, so priority is normally omitted for that model.

However, memories.extract_model is configurable. If it is changed to gpt-5.4 or another model that supports priority, phase 1 can also send the inherited priority tier.

Phase 2 uses gpt-5.4 by default, and that model advertises priority, so phase-2 consolidation can use the foreground thread's priority tier under the default model configuration.

Relevant code:

• Phase 1 copies the live tier:
  

  codex/codex-rs/memories/write/src/runtime.rs

  Lines 209 to 238 in b5314ae

  	pub(crate) async fn stage_one_request_context(
  	&self,
  	config: &Config,
  	model_name: &str,
  	reasoning_effort: ReasoningEffort,
  	) -> StageOneRequestContext {
  	let config_snapshot = self.thread.config_snapshot().await;
  	let model_info = self
  	.thread_manager
  	.get_models_manager()
  	.get_model_info(model_name, &config.to_models_manager_config())
  	.await;
  	let reasoning_summary = config
  	.model_reasoning_summary
  	.unwrap_or(model_info.default_reasoning_summary);
  	StageOneRequestContext {
  	model_info,
  	session_telemetry: build_session_telemetry(
  	&self.auth_manager,
  	self.thread_id,
  	config,
  	config_snapshot.session_source,
  	model_name,
  	config_snapshot.originator,
  	),
  	reasoning_effort: Some(reasoning_effort),
  	reasoning_summary,
  	service_tier: config_snapshot.service_tier,
  	}

• Phase 1 passes it to the model client:
  

  codex/codex-rs/memories/write/src/runtime.rs

  Lines 281 to 291 in b5314ae

  	let mut stream = client_session
  	.stream(
  	prompt,
  	&context.model_info,
  	&context.session_telemetry,
  	context.reasoning_effort.clone(),
  	context.reasoning_summary,
  	context.service_tier.clone(),
  	&responses_metadata,
  	&InferenceTraceContext::disabled(),
  	)

• The request builder retains a tier when the selected model advertises support:
  

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

  Lines 623 to 628 in b5314ae

  	pub fn service_tier_for_request(&self, service_tier: Option<String>) -> Option<String> {
  	service_tier.filter(|service_tier| {
  	service_tier != SERVICE_TIER_DEFAULT_REQUEST_VALUE
  	&& self.supports_service_tier(service_tier)
  	})
  	}

  
  

  codex/codex-rs/core/src/client.rs

  Lines 889 to 906 in b5314ae

  	let service_tier = model_info.service_tier_for_request(service_tier);
  	let request = ResponsesApiRequest {
  	model: model_info.slug.clone(),
  	instructions,
  	input,
  	tools,
  	tool_choice: "auto".to_string(),
  	parallel_tool_calls: prompt.parallel_tool_calls && !model_info.use_responses_lite,
  	reasoning,
  	store: provider.is_azure_responses_endpoint(),
  	stream: true,
  	stream_options,
  	include,
  	service_tier,
  	prompt_cache_key,
  	text,
  	client_metadata: Some(responses_metadata.client_metadata()),
  	};

• Phase 2 clones the parent config without clearing service_tier:
  

  codex/codex-rs/memories/write/src/phase2.rs

  Lines 302 to 347 in b5314ae

  	pub(super) fn get_config(config: &Config, provider: &dyn ModelProvider) -> Option<Config> {
  	let root = memory_root(&config.codex_home);
  	let mut agent_config = config.clone();
  	agent_config.cwd = root.clone();
  	// Consolidation threads must never feed back into phase-1 memory generation.
  	agent_config.ephemeral = true;
  	agent_config.memories.generate_memories = false;
  	agent_config.memories.use_memories = false;
  	agent_config.include_apps_instructions = false;
  	agent_config.mcp_servers = Constrained::allow_only(HashMap::new());
  	// Approval policy
  	agent_config.permissions.approval_policy = Constrained::allow_only(AskForApproval::Never);
  	// Consolidation runs as an internal worker and must not recursively delegate.
  	let _ = agent_config.features.disable(Feature::SpawnCsv);
  	let _ = agent_config.features.disable(Feature::Collab);
  	let _ = agent_config.features.disable(Feature::MemoryTool);
  	let _ = agent_config.features.disable(Feature::Apps);
  	let _ = agent_config.features.disable(Feature::Plugins);
  	let _ = agent_config
  	.features
  	.disable(Feature::SkillMcpDependencyInstall);
  	// Sandbox policy
  	let writable_roots = vec![root];
  	// The consolidation agent only needs local memory-root write access and no network.
  	let consolidation_sandbox_policy = SandboxPolicy::WorkspaceWrite {
  	writable_roots,
  	network_access: false,
  	exclude_tmpdir_env_var: true,
  	exclude_slash_tmp: true,
  	};
  	agent_config
  	.set_legacy_sandbox_policy(consolidation_sandbox_policy)
  	.ok()?;
  	agent_config.model = Some(
  	config
  	.memories
  	.consolidation_model
  	.clone()
  	.unwrap_or_else(|| provider.memory_consolidation_preferred_model().to_string()),
  	);
  	agent_config.model_reasoning_effort = Some(crate::stage_two::REASONING_EFFORT);
  	Some(agent_config)

• The default consolidation model is gpt-5.4:
  

  codex/codex-rs/model-provider/src/provider.rs

  Lines 124 to 129 in b5314ae

  	/// Returns the preferred model used for memory consolidation.
  	///
  	/// Providers that require backend-specific model IDs should override this.
  	fn memory_consolidation_preferred_model(&self) -> &'static str {
  	DEFAULT_MEMORY_CONSOLIDATION_PREFERRED_MODEL
  	}

• gpt-5.4 advertises priority:
  

  codex/codex-rs/models-manager/models.json

  Lines 524 to 533 in b5314ae

  	],
  	"supports_search_tool": true,
  	"default_service_tier": null,
  	"service_tiers": [
  	{
  	"id": "priority",
  	"name": "Fast",
  	"description": "1.5x speed, increased usage"
  	}
  	],

What steps can reproduce the bug?

1. Enable memory generation.

2. Enable Fast Mode so the foreground thread's effective service tier is priority.

3. Configure both memory stages to use a model that supports priority:

service_tier = "fast"

[memories]
extract_model = "gpt-5.4"
consolidation_model = "gpt-5.4"

4. Create enough eligible thread history for memory extraction and consolidation to run.

5. Start another foreground turn, which launches the memory startup task.

6. Inspect the background Responses requests or associated usage. The memory jobs can carry service_tier: "priority" even though no memory-specific accelerated tier was selected.

With the default extraction model, the phase-1 tier is filtered because gpt-5.4-mini does not currently advertise priority support. Changing memories.extract_model to a priority-capable model exposes the same behavior in phase 1. Phase 2 is affected with its default gpt-5.4 model.

What is the expected behavior?

Background memory jobs should not implicitly inherit the interactive thread's accelerated service tier.

Unless a memory-specific service tier is explicitly configured, both memory extraction and memory consolidation should use the default service tier. On the wire, this should mean omitting service_tier from the Responses request.

The behavior should be consistent across both phases and independent of whether the selected memory model happens to support priority.

Additional information

There is also an inconsistency in where the two phases obtain their configuration:

• Phase 1 reads thread.config_snapshot() and therefore sees live thread-level service-tier changes.
• Phase 2 receives thread.config(), which resolves to original_config_do_not_use, and therefore follows the original configuration rather than necessarily following the current live thread override.

Relevant paths:

• Memory startup passes thread.config():
  

  codex/codex-rs/app-server/src/request_processors/turn_processor.rs

  Lines 542 to 551 in b5314ae

  	if turn_has_input {
  	let config_snapshot = thread.config_snapshot().await;
  	codex_memories_write::start_memories_startup_task(
  	Arc::clone(&self.thread_manager),
  	Arc::clone(&self.auth_manager),
  	thread_id,
  	Arc::clone(&thread),
  	thread.config().await,
  	&config_snapshot.session_source,
  	);

• thread.config() returns the original session config:
  

  codex/codex-rs/core/src/codex_thread.rs

  Lines 598 to 600 in b5314ae

  	pub async fn config(&self) -> Arc<crate::config::Config> {
  	self.codex.session.get_config().await
  	}

  
  

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

  Lines 1581 to 1587 in b5314ae

  	pub(crate) async fn get_config(&self) -> std::sync::Arc<Config> {
  	let state = self.state.lock().await;
  	state
  	.session_configuration
  	.original_config_do_not_use
  	.clone()
  	}

The existing phase-1 test asserts that the request context inherits the live tier, but it does not assert the final serialized service_tier in the request body:

The phase-2 request tests assert the selected model but do not cover service-tier behavior:

It would be useful to add request-body regression coverage for both phases.