ChatGPT Token Limit: What Counts and What to Save

A ChatGPT token limit is a limit measured in the pieces of text an AI processes or produces. It is different from a message allowance, and a published model limit for the API, the interface developers use to connect software, is not automatically the limit for your ChatGPT conversation. Knowing which limit you mean helps you choose between shortening a request, narrowing the answer, or checking your account notice.

For ongoing work, the useful goal is to preserve the decisions behind the conversation. Tools like fenbs keep reviewed project notes and progress outside one AI app, ready for a fresh session. That preserves the work without increasing a model’s capacity.

What does a token actually measure?

A token is a chunk of text, sometimes a word and sometimes part of a word. Spaces, punctuation, and the particular text affect how those chunks are formed. OpenAI’s key concepts guide↗ (opens in a new tab) explains tokenization and provides a tokenizer for inspecting a sample.

This is why a word count is only a rough planning aid. A page of ordinary prose, a page of code, and a page of long identifiers can produce different token counts. A short-looking request with a large pasted appendix can carry much more material than the visible question suggests.

You rarely need to count individual tokens to write a useful work request. Start by identifying the actual task and the few sources needed to complete it. Token counting becomes more helpful when you are building an API application or trying to understand why a specific large input will not fit.

Which limits are people mixing together?

The word limit can refer to several different restrictions. A remedy that helps with one may leave the others unchanged. Use the wording of the notice you actually receive rather than assuming every interruption means the conversation has become too long.

OpenAI’s conversation-state documentation↗ (opens in a new tab) distinguishes context capacity from output tokens for API requests. It explains the concepts; it does not establish your ChatGPT account allowance. For a usage restriction, use the separate guide to ChatGPT daily limits.

Where should you look for the applicable number?

Check the product, selected model, and notice in your own account before relying on a number. An API model page describes that API model. A number copied from another person’s screenshot can describe a different product, account, or configuration. Recording those differences is more useful than collecting several contradictory figures.

If documentation does not establish an exact ChatGPT figure for your setup, keep that uncertainty explicit. Do not turn an estimate into a promise about how many pages a future chat will accept. Pages vary in density, and a conversation contains more than the document you happen to be reading.

Keep coding-product allowances separate too. The article on Codex usage limits owns that question. Shared branding does not make a limit in a coding workflow proof of the allowance in an ordinary ChatGPT chat.

Does saved memory make the token limit larger?

Treat memory as another way useful context may reach a conversation, not as extra working space. OpenAI’s Memories documentation↗ (opens in a new tab) distinguishes ChatGPT web memory from the separate local memory used by Codex clients. It also recommends keeping required guidance in explicit documentation rather than relying on recall alone.

For example, remembering that you write product guides does not supply the approved outline for the guide due today. A rule about tone, the current outline, and an unfinished source check are different pieces of information. Decide where each belongs, then verify the current version before asking for more drafting.

You also need a way to correct a saved fact. If a project’s audience changes, an older audience description should stop directing new work. In fenbs’s project context, people can keep the current rules and task state in an explicit record that connected assistants read.

What should you shorten in a large request?

Shorten repetition and unrelated material before cutting the facts that control the answer. A concise request still needs a goal, the relevant source, the required result, and any boundaries on the work. Removing those can make a request shorter while making the answer less useful.

1. State one deliverable. Replace “finish the whole launch” with a defined task such as reviewing the introduction against the approved outline.
2. Choose the current source. Supply the approved draft and identify which older versions no longer apply.
3. Preserve exact requirements. Keep the wording of a rule when changing a word would change the obligation.
4. Limit supporting material. Include the relevant excerpt with a source reference, and keep the full original available for checks.
5. Ask for a bounded answer. A complete review of one section is easier to inspect than several partial reviews of an entire project.

Do not split a document mechanically if the task depends on relationships across sections. Give an overview first and explain which connections matter. Then work through the sections with a shared checklist so a conclusion in one part does not contradict a requirement in another.

What is worth saving before you start fresh?

Save the state of the work rather than a miniature transcript. A future assistant needs to know what was approved, what exists, what remains unverified, and what it should do first. The full history can remain available as supporting evidence instead of being repeated in every prompt.

Say you are editing a training guide. A useful record names the approved audience, links the current draft, lists the sections already reviewed, and identifies the remaining accessibility check. “We discussed the guide at length” gives the next session almost nothing it can act on.

Ask the next assistant to restate the task and its boundaries before continuing. Correct that restatement when necessary. If you later compare Claude and ChatGPT, or consider ChatGPT alternatives, the same reviewed record gives you a consistent starting point.

How to do this with fenbs

Start with one project whose next step you can verify. You are creating a reliable handoff, not trying to preserve every sentence ever written about the work.

1. Create a free account, then add the project and its current task to your personal kanban board.
2. Record the choices a person approved in Decisions and rules. Keep suggestions clearly separate from those choices.
3. Add a short context note with the current source references, then save Where we left off with the unfinished work and the first next step.
4. Follow the relevant integration guide to connect your assistant through MCP, a standard way for an AI app to use an outside tool.
5. In the fresh session, ask the assistant to read the project context, explain what remains, and continue only after you verify its understanding.

fenbs does not import ChatGPT conversations or change account allowances. It is not the right fit when you only need to shorten a single prompt and have no ongoing work to preserve. For broader techniques, browse the context engineering guides.