Codex Has a 1M Context Window. I Rarely Go Past 200K

OpenAI’s GPT-5.6 Sol has a context window of more than 1 million tokens.

That is a lot of context for Codex.

In theory, I could keep one coding session running for a very long time. Codex could keep reading files, running commands, debugging errors, and discussing implementation while everything stays inside the same context.

But that is not how I usually work.

When my Codex session reaches around 150–200K tokens, I normally save the important state and start a new session.

Even when I still have hundreds of thousands of tokens available.

To make this easy, I built two small skills:

• session-saver
• session-loader

They are built around one simple idea:

Save the state, not the whole conversation.

Having 1M tokens doesn’t mean I need 1M tokens

Large context windows are useful for coding agents.

Codex may need to inspect a lot of code, read documentation, run tools, see errors, and remember decisions from earlier in the task.

More context gives it more room to do that.

But a long coding session also collects a lot of temporary information:

• file reads
• tool outputs
• command results
• debugging attempts
• errors
• repeated explanations
• abandoned ideas
• things that are no longer relevant

Most of this information was useful when it happened.

That doesn’t mean I still need all of it hours later.

Eventually, I stopped asking:

How much context can I keep?

And started asking:

How little context do I need to continue?

That question changed how I manage long Codex sessions.

I need the state, not the entire conversation

Imagine I spend a few hours working with Codex on an authentication refactor.

During that session, maybe we:

• inspect the existing auth flow
• discuss several approaches
• choose one
• modify a few files
• run the tests
• discover one approach doesn’t work
• fix another problem
• hit a blocker
• decide what to do next

The complete session might contain a huge amount of text and tool output.

But if I continue tomorrow, I don’t really need every message from today.

I mostly need to know:

• What are we working on?
• What did we decide?
• What changed?
• What did we already try?
• What failed?
• What is still blocked?
• What should we do next?

That is much smaller than the full conversation.

And that is what session-saver keeps.

session-saver: create a checkpoint

When the session gets large enough, I can simply tell Codex:

Use session-saver and save the current work.

The skill creates a Markdown file under .sessions/.

For example:

.sessions/
└── 2026-08-21-auth-refactor.md

Instead of copying the conversation, it extracts the useful state.

A session file might look like this:

# Session: Auth Refactor

## Status

JWT migration is partially complete.
Login works, but token refresh still fails.

## Objectives

- Finish the JWT migration.
- Keep the existing login flow working.
- Add tests for token refresh.

## Decisions

- Keep refresh tokens in HTTP-only cookies.
- Do not store refresh tokens in localStorage.
- Keep the existing `/api/auth/refresh` route.

## Changes

- Updated `src/auth/session.ts`.
- Added refresh-token validation.
- Updated login tests.

## Tried & ruled out

- Tried handling refresh inside middleware.
- Dropped it because it caused redirect loops.

## Blockers

The refresh token is valid, but the client does not retry
the original request after receiving a 401.

## Next steps

1. Trace 401 handling in `api-client.ts`.
2. Add a retry test.
3. Run the full auth test suite.

That file is tiny compared with the original session.

But it contains most of what I need to continue.

Two sections are especially valuable to me.

Decisions

A fresh Codex session can read the repository and understand what exists.

But the code doesn’t always explain why I chose that implementation.

If the previous session compared three approaches and intentionally chose one, I want to preserve that reasoning.

Otherwise, the next session may spend time rediscovering the same options.

Tried and ruled out

This is probably even more useful.

Without the previous context, a new agent can suggest something I already tested.

Then I have to explain:

We already tried that. It didn’t work because…

Saving failed approaches gives the next session a little negative knowledge.

It knows where not to go again.

Why I usually stop around 150–200K

I don’t wait until the context window is full.

My normal cutoff is somewhere around 150–200K tokens.

There is nothing scientific about that number.

I didn’t benchmark 150K against 300K and discover a magic limit.

It is simply my practical rule.

By that point, the session has usually collected enough history that I would rather save the useful parts than keep carrying everything forward.

GPT-5.6 Sol makes this more interesting because its context window is 1,050,000 tokens.

So I am intentionally leaving most of the available context unused.

And there is one small API pricing detail worth knowing.

OpenAI says that GPT-5.6 Sol prompts above 272K input tokens are priced at 2× the input rate and 1.5× the output rate for the full request.

That is not why I chose my 150–200K rule.

I was already using this workflow before GPT-5.6 Sol.

But if you use the model through the API, my normal cutoff now happens to stay below another interesting boundary.

So there can also be a cost benefit to being intentional about how large a request becomes.

Again, I don’t start a new session at 200K just to avoid that pricing boundary.

It is simply a nice side effect of a workflow I already prefer.

session-loader: start a new session without starting over

Saving the state only solves half of the problem.

I still need to restore it.

That is what session-loader does.

When I start a new Codex session, I can say:

Use session-loader and continue the latest session.

The skill finds the previous session file and loads the useful state.

Now Codex knows what we were working on, what changed, what failed, and what should happen next.

Instead of manually explaining yesterday’s work:

Yesterday we were working on the auth system.

We changed these files...

Then we tried...

It failed because...

After that we decided...

I can basically say:

Continue where we left off.

The new session doesn’t know everything the previous session knew.

That is intentional.

It knows what it needs to know.

The repository still wins

There is one important rule in my loader:

If the saved session and the current code disagree, the code wins.

The session file is only a snapshot.

Maybe I changed something after saving it.

Maybe another agent modified the project.

Maybe I switched branches.

Maybe a collaborator pushed new commits.

Or maybe the previous session summary simply missed something.

So session-loader uses the saved state as memory, but still checks it against the actual project.

I think about it like this:

The session file is memory. The repository is reality.

Should .sessions/ go into Git?

It depends.

For personal projects, I sometimes like the idea of keeping session files in Git because they create a small history of decisions and failed experiments.

For other projects, especially client or team projects, I may prefer:

.sessions/

These files are working memory, not project documentation.

They may also contain temporary details that I don’t want to keep permanently.

Whether I commit them or not, I avoid storing credentials, secrets, or sensitive client data in session files.

So I treat committing them as a project decision, not a requirement of the workflow.

My complete Codex loop

The full workflow is simple:

Start new Codex session
        │
        ▼
Load previous state
        │
        ▼
Work normally
        │
        ▼
Context reaches ~150–200K
        │
        ▼
Save useful state
        │
        ▼
End session
        │
        ▼
Start a new session
        │
        └──────────────► Load previous state

That’s basically it.

No vector database.

No external memory service.

No complicated retrieval system.

Just:

.sessions/*.md

I can read the files myself.

I can edit them.

I can search them.

I can delete them.

And because they are just Markdown, the workflow isn’t tightly coupled to Codex either.

1 million tokens is capacity, not a goal

I like that GPT-5.6 Sol gives me a context window of more than 1 million tokens.

There are tasks where that extra room can be extremely useful.

A large refactor might require a lot of code.

A research-heavy task might need a lot of documentation.

Sometimes I may genuinely want a very large context.

I just don’t treat the maximum context window as something I need to fill.

For normal long-running coding work, I would rather carry forward a small amount of useful state than hundreds of thousands of tokens of conversation history.

That is what these two skills give me.

session-saver keeps the important state.

session-loader gives it to the next session.

The conversation can disappear.

The decisions, failed attempts, blockers, and next steps don’t have to.

Save the state, not the whole conversation.

For me, that has been enough.

Get the skills

• session-saver
• session-loader