Feature Request: Personalized Context Window Defaults for Codex via a Simple Skill

Codex’s default context window is tuned for most users, but different users—and even different projects belonging to the same user—can have very different context requirements.

Instead of relying on a single global default, why not let Codex help users personalize their settings based on their actual usage history?

Proposal: Provide an official Codex Skill with a lightweight local configuration script.

The workflow could be straightforward:

  1. Analyze local session history: Examine context usage, compaction events, and project associations using existing Codex session records.

  2. Recommend per-project defaults: Estimate an appropriate context window for each project based on its historical workload.

  3. Apply configurations: With user approval, update each project’s .codex/config.toml. Sessions without a project association can use an estimated user-level default.

  4. Update on demand: Users can rerun the Skill periodically as their workloads evolve.

The important part is that much of the necessary infrastructure already exists.

Codex already supports project-level configuration overrides, including model_context_window and model_auto_compact_token_limit. Its local session records also contain useful context usage statistics and compaction information.

An initial implementation could therefore be remarkably small: one Skill and one local script, with no need for major architectural changes.

Most of the analysis could run locally using session metadata, without additional model calls, minimizing extra usage costs and unnecessary exposure of session content. Recommendations would be approximate rather than guaranteed optimal, but even simple, conservative heuristics could provide a useful starting point.

This would also preserve the value of OpenAI’s carefully tuned defaults: they would remain the fallback for new users and projects without sufficient history.

Good defaults are important. But when Codex already has the information and configuration mechanisms needed to personalize them, why should the same defaults apply to every project?

I think this would be a relatively low-cost improvement with meaningful benefits for users managing diverse or long-running projects.

Related proposals

Related proposals have discussed per-thread context profiles (#40429) and adaptive context-window expansion (#41538).

This suggestion focuses on a much smaller, immediately actionable approach: using existing session history and project-level configuration support through a simple, reusable Skill.

I’d separate the model’s supported capacity from the project’s preferred compaction threshold. The docs treat model_context_window as model metadata, while model_auto_compact_token_limit controls when history is compacted. A skill could tune the second from project history while keeping the first tied to the selected model’s supported limit.

Appreciate your suggestion, @Hubery_Stellan!

I can see how usage-based recommendations would help when your projects have different context needs.

As you noted, the configuration options already exist. For anyone interested in building a custom version, the skills guide explains how to create a skill with optional scripts using $skill-creator.

That provides a starting point for building this workflow. I’ll pass on your request for an official skill to recommend project-specific context settings. I can’t promise if or when it might be added.

-Yash