Notebookcheck’s new measurement puts a hard number on a claim that has become lazy shorthand in AI discussions: one million tokens is not one million words, and it is not a practical invitation to dump an entire personal knowledge base into every prompt. Its German test text scaled to roughly 543,000 to 649,000 words across OpenAI’s older and newer token encodings; the same English sample would scale to a little over one million words.
The important finding is not the particular German number. It is that the number is model-, tokenizer-, language-, and document-dependent. That turns “this model has a million-token context window” from a storage specification into a capacity figure that has to be tested against the material an organization actually intends to search.
Notebookcheck counted the body text and subheadings of matching German and English versions of one of its own articles with
That is a useful real-world demonstration. It is not a universal German-language conversion chart.
The arithmetic behind Notebookcheck’s German range checks out. At 1,747 tokens for 1,134 words, one million tokens represents about 649,000 words. At 2,088 tokens for the same word count, the equivalent falls to roughly 543,000 words. That is a 16 percent swing in usable text volume before the user has changed models, prompts, or documents.
The English figures underline why the industry’s “750,000 words per million tokens” rule is not safe in either direction. The tested English article used fewer tokens than words: around 0.94 tokens per word. Extrapolated directly, one million tokens would hold approximately 1.06 million words of that particular English prose.
OpenAI’s own tokenizer documentation advises users to treat its common English heuristic as roughly four characters per token, not as a universal words-per-token formula. Its public
The material caveat is sample size. A translated magazine article is a controlled example, but it is still one text. German compound nouns, URLs, source code, log files, PowerShell scripts, registry paths, JSON, Windows event records, tables, and OCR errors can all tokenize differently. An IT department with a corpus of Intune exports, help-desk notes, incident reports, and Markdown runbooks should not use the article’s German ratio as a capacity plan.
It should run its own count against representative files.
That is especially relevant for Windows administrators. A collection of clean prose notes behaves very differently from a repository full of error strings such as
OpenAI’s current GPT-5.6 Sol documentation supports the central pricing premise. Input costs $5 per million tokens, while prompts exceeding 272,000 input tokens are charged at double the normal input rate for the full request. At 616,000 tokens, that works out to about $6.16 before output charges. The model’s listed context window is 1.05 million tokens, so the collection would fit on paper.
But “fits” does not mean “costs $6.16” in every implementation.
The figure assumes that the 616,000-token estimate accurately represents the final request payload and that the user is measuring input only. A production request may also include system instructions, chat history, tool definitions, retrieved passages, file metadata, and other framework overhead. GPT-5.6 Sol output is separately priced at $30 per million tokens, so long answers, extracted tables, or generated reports add to the bill.
The calculation also assumes a direct API workflow. That matters. In a stateless API design, an application that sends the full archive with every request must indeed pay to process that archive repeatedly unless it benefits from prompt caching. OpenAI lists cached GPT-5.6 Sol input at $0.50 per million tokens, and Notebookcheck correctly notes that a strong cache hit can radically reduce the recurring input charge.
Cache hits are an optimization, though, not a knowledge-management strategy. They depend on an unchanged shared prompt prefix and a limited cache lifetime. Change the archive ordering, insert a new note near the front, alter a system prompt, or let the cache expire, and the application can fall back to the full input price.
For a Windows shop, the operational answer is straightforward: treat a full-corpus prompt as an exception for audits, broad trend analysis, or a one-off migration review. Do not make it the default path for “What did we decide about BitLocker recovery escrow last year?” or “Which driver package caused the March failures?”
The cost ratio is actually more dramatic than a raw token comparison suggests because the large request crosses OpenAI’s 272,000-token pricing threshold. That is why a targeted retrieval system is not merely a speed feature. It changes the billing tier.
There is a further distinction that deserves more care than it gets in most “AI second brain” debates: a context window is not a file-management system.
An API context window describes the material an application can submit to a model in one request. It does not store, organize, version, back up, or independently retrieve notes. The model has no durable understanding of an archive merely because it processed it in an earlier API call; an application must provide the relevant information again, or use a retrieval layer, cache, memory feature, or external database.
Consumer products complicate the picture. ChatGPT Projects, NotebookLM, and similar tools may retain uploaded material and retrieve from it internally, rather than injecting every file in full into every visible prompt. Users therefore should not assume that a project’s file count equals the active model context, or that an API token-pricing estimate maps directly to a consumer subscription.
The vendor documentation itself demonstrates why caution is warranted. OpenAI’s current Projects help page says ChatGPT Free supports five files per project, Go and Plus support 25, and Edu, Pro, Business, and Enterprise support 40. Yet OpenAI’s File Uploads FAQ, updated in the same recent period, still says Plus is limited to 20 files per project while listing 40 for Pro and several organizational tiers.
Notebookcheck identified the contradiction correctly. OpenAI has not publicly explained which Plus limit takes precedence. The practical consequence is more mundane than the million-token headline: administrators and heavy users should test the limit enforced by their own tenant and plan before designing a workflow around a 25-file project.
Google’s current NotebookLM help documentation is clearer on source counts: its standard tier permits 50 sources per notebook, upgraded tiers raise the number, and individual sources can contain up to 500,000 words or 200 MB for local uploads. Those limits govern ingestion, not a promise that every word of every source is placed into every model call.
For IT work, a useful collection also creates auditability. A short retrieval set can show which change ticket, knowledge-base article, deployment log, or troubleshooting note supported an answer. A model asked to scan 400 undifferentiated notes can still produce a polished answer, but tracing which obsolete procedure or conflicting note influenced it is far harder.
A sensible implementation does not require elaborate “second brain” rituals. Keep notes as portable text where possible, use consistent titles and dates, reserve tags for categories that actually drive retrieval, and separate live procedures from historical incident records. Then let keyword search or semantic retrieval narrow the candidate set before a model summarizes or compares it.
The million-token era changes the ceiling for occasional analysis. It does not remove the value of curation. For anyone managing a growing Windows knowledge base, the meaningful unit is no longer how much text a model can technically ingest. It is how reliably the system can find the ten records that matter — without reprocessing the other 390 every time.
Notebookcheck counted the body text and subheadings of matching German and English versions of one of its own articles with
js-tiktoken 1.0.20. The German version contained 1,134 words and yielded 1,747 tokens with OpenAI’s o200k_base encoding, used by current GPT-family models, versus 2,088 with the older cl100k_base encoding associated with GPT-4 and GPT-3.5. The English version contained 1,276 words and came out at 1,200 and 1,202 tokens, respectively.That is a useful real-world demonstration. It is not a universal German-language conversion chart.
The tokenizer is the hidden capacity limit
The arithmetic behind Notebookcheck’s German range checks out. At 1,747 tokens for 1,134 words, one million tokens represents about 649,000 words. At 2,088 tokens for the same word count, the equivalent falls to roughly 543,000 words. That is a 16 percent swing in usable text volume before the user has changed models, prompts, or documents.The English figures underline why the industry’s “750,000 words per million tokens” rule is not safe in either direction. The tested English article used fewer tokens than words: around 0.94 tokens per word. Extrapolated directly, one million tokens would hold approximately 1.06 million words of that particular English prose.
OpenAI’s own tokenizer documentation advises users to treat its common English heuristic as roughly four characters per token, not as a universal words-per-token formula. Its public
tiktoken mappings also confirm the broad split Notebookcheck tested: GPT-5-family models map to o200k_base, while legacy GPT-4 and GPT-3.5 mappings use cl100k_base.The material caveat is sample size. A translated magazine article is a controlled example, but it is still one text. German compound nouns, URLs, source code, log files, PowerShell scripts, registry paths, JSON, Windows event records, tables, and OCR errors can all tokenize differently. An IT department with a corpus of Intune exports, help-desk notes, incident reports, and Markdown runbooks should not use the article’s German ratio as a capacity plan.
It should run its own count against representative files.
That is especially relevant for Windows administrators. A collection of clean prose notes behaves very differently from a repository full of error strings such as
0x800f081f, device identifiers, file paths, package names, and command output. Those are precisely the kinds of fragments users want an assistant to find, but their token cost can be much less predictable than an article’s body text.
The $6.16 calculation is plausible — and deliberately incomplete
Notebookcheck then applies its Germano200k_base result to a 350,000- to 400,000-word collection of about 470 notes. At approximately 616,000 input tokens, it calculates a $6.16 cost for one question sent to OpenAI’s GPT-5.6 Sol API.OpenAI’s current GPT-5.6 Sol documentation supports the central pricing premise. Input costs $5 per million tokens, while prompts exceeding 272,000 input tokens are charged at double the normal input rate for the full request. At 616,000 tokens, that works out to about $6.16 before output charges. The model’s listed context window is 1.05 million tokens, so the collection would fit on paper.
But “fits” does not mean “costs $6.16” in every implementation.
The figure assumes that the 616,000-token estimate accurately represents the final request payload and that the user is measuring input only. A production request may also include system instructions, chat history, tool definitions, retrieved passages, file metadata, and other framework overhead. GPT-5.6 Sol output is separately priced at $30 per million tokens, so long answers, extracted tables, or generated reports add to the bill.
The calculation also assumes a direct API workflow. That matters. In a stateless API design, an application that sends the full archive with every request must indeed pay to process that archive repeatedly unless it benefits from prompt caching. OpenAI lists cached GPT-5.6 Sol input at $0.50 per million tokens, and Notebookcheck correctly notes that a strong cache hit can radically reduce the recurring input charge.
Cache hits are an optimization, though, not a knowledge-management strategy. They depend on an unchanged shared prompt prefix and a limited cache lifetime. Change the archive ordering, insert a new note near the front, alter a system prompt, or let the cache expire, and the application can fall back to the full input price.
For a Windows shop, the operational answer is straightforward: treat a full-corpus prompt as an exception for audits, broad trend analysis, or a one-off migration review. Do not make it the default path for “What did we decide about BitLocker recovery escrow last year?” or “Which driver package caused the March failures?”
Context windows and file libraries are different products
The article’s most useful conclusion is that retrieval reduces both cost and noise. Passing ten relevant notes instead of 400 could reduce the stated workload from about 616,000 tokens to roughly 9,000. At standard GPT-5.6 Sol input pricing, that is around 4.5 cents rather than $6.16.The cost ratio is actually more dramatic than a raw token comparison suggests because the large request crosses OpenAI’s 272,000-token pricing threshold. That is why a targeted retrieval system is not merely a speed feature. It changes the billing tier.
There is a further distinction that deserves more care than it gets in most “AI second brain” debates: a context window is not a file-management system.
An API context window describes the material an application can submit to a model in one request. It does not store, organize, version, back up, or independently retrieve notes. The model has no durable understanding of an archive merely because it processed it in an earlier API call; an application must provide the relevant information again, or use a retrieval layer, cache, memory feature, or external database.
Consumer products complicate the picture. ChatGPT Projects, NotebookLM, and similar tools may retain uploaded material and retrieve from it internally, rather than injecting every file in full into every visible prompt. Users therefore should not assume that a project’s file count equals the active model context, or that an API token-pricing estimate maps directly to a consumer subscription.
The vendor documentation itself demonstrates why caution is warranted. OpenAI’s current Projects help page says ChatGPT Free supports five files per project, Go and Plus support 25, and Edu, Pro, Business, and Enterprise support 40. Yet OpenAI’s File Uploads FAQ, updated in the same recent period, still says Plus is limited to 20 files per project while listing 40 for Pro and several organizational tiers.
Notebookcheck identified the contradiction correctly. OpenAI has not publicly explained which Plus limit takes precedence. The practical consequence is more mundane than the million-token headline: administrators and heavy users should test the limit enforced by their own tenant and plan before designing a workflow around a 25-file project.
Google’s current NotebookLM help documentation is clearer on source counts: its standard tier permits 50 sources per notebook, upgraded tiers raise the number, and individual sources can contain up to 500,000 words or 200 MB for local uploads. Those limits govern ingestion, not a promise that every word of every source is placed into every model call.
A local note system still earns its keep
The case for Obsidian, Joplin, OneNote, Notion, or a plain Markdown folder is not that these tools somehow outperform a frontier model at reasoning. It is that they preserve the part of the workflow AI platforms do not replace well: durable ownership of the source material, predictable organization, and a way to select relevant evidence before handing it to an expensive probabilistic system.For IT work, a useful collection also creates auditability. A short retrieval set can show which change ticket, knowledge-base article, deployment log, or troubleshooting note supported an answer. A model asked to scan 400 undifferentiated notes can still produce a polished answer, but tracing which obsolete procedure or conflicting note influenced it is far harder.
A sensible implementation does not require elaborate “second brain” rituals. Keep notes as portable text where possible, use consistent titles and dates, reserve tags for categories that actually drive retrieval, and separate live procedures from historical incident records. Then let keyword search or semantic retrieval narrow the candidate set before a model summarizes or compares it.
The million-token era changes the ceiling for occasional analysis. It does not remove the value of curation. For anyone managing a growing Windows knowledge base, the meaningful unit is no longer how much text a model can technically ingest. It is how reliably the system can find the ten records that matter — without reprocessing the other 390 every time.