Allow service tiers to be configured separately for memory extraction and consolidation
What variant of Codex are you using?
CLI / Codex App shared memory pipeline
What feature would you like to see?
Please add explicit, memory-specific service-tier configuration for the extraction and consolidation stages.
Codex already allows the models for these stages to be configured independently:
[memories]
extract_model = "gpt-5.4-mini"
consolidation_model = "gpt-5.4"The corresponding service tiers should also be independently configurable. For example:
[memories]
extract_model = "gpt-5.4-mini"
extract_service_tier = "default"
consolidation_model = "gpt-5.4"
consolidation_service_tier = "flex"Separate extraction and consolidation settings are useful because the stages may use different models, and those models may advertise different supported service tiers.
The configuration should support the same explicit choices as ordinary Codex turns:
default: Use standard processing and do not inherit the foreground thread's accelerated or reduced-cost tier.fast: Requestpriorityprocessing when the user intentionally wants memory extraction or consolidation to complete sooner and accepts the increased usage or cost.flex: Allow API-key users to run delay-tolerant memory maintenance at a lower API cost in exchange for slower responses and occasional resource unavailability.
Memory generation is a particularly good use case for Flex processing. Extraction and consolidation happen in the background, do not normally block the user's active turn, and generally do not require interactive latency. API-key users could therefore opt into lower-cost Flex processing for memory jobs without making all foreground Codex requests use Flex.
OpenAI's Flex processing documentation describes it as lower-cost processing for lower-priority or asynchronous workloads, with slower responses and occasional resource unavailability:
https://developers.openai.com/api/docs/guides/flex-processing
For example, an API-key user might choose lower-cost background extraction while keeping consolidation on standard processing:
[memories]
extract_model = "gpt-5.4"
extract_service_tier = "flex"
consolidation_model = "gpt-5.4"
consolidation_service_tier = "default"Alternatively, a user who values immediate memory availability could explicitly choose priority processing:
[memories]
extract_model = "gpt-5.4"
extract_service_tier = "fast"
consolidation_model = "gpt-5.4"
consolidation_service_tier = "fast"When these keys are omitted, memory jobs should use the normal/default service tier rather than inheriting the interactive foreground thread's service tier.
An explicitly configured tier should be validated against the corresponding selected model and provider using the same support filtering used by ordinary Responses requests. A memory-specific flex setting should not depend on Fast Mode being enabled, since Flex and Priority represent different processing and cost tradeoffs.
Additional information
This request is related to, but separate from, the bug where memory jobs implicitly inherit the foreground thread's Fast Mode / priority tier- #32429
The bug can be fixed independently by making the default memory behavior omit service_tier. This feature request would then provide an explicit opt-in for users who intentionally want accelerated or alternative service tiers for memory maintenance.
Relevant existing model configuration:
MemoriesConfigalready exposesextract_modelandconsolidation_model:
- Phase 1 resolves
extract_model:
- Phase 2 resolves
consolidation_model:
A single memories.service_tier key would be less flexible because extraction and consolidation can use models with different tier support. Separate keys would mirror the existing separate model controls and make each request's behavior explicit.