In July we made our search accent-insensitive. Type “skoda” and you find “Škoda”. Type “cafe” and you find “café”. It took one line, the same line most JavaScript developers reach for, and it fixed search for every user writing in French, Czech, Polish or Vietnamese.

For the next three months, that line also meant a Korean user searching their chat history got results whose preview did not contain the word they searched for. Sometimes the preview was just “…”. The search was right. The preview was cut in the wrong place.

I co-founded AI Toolbox, a Chrome extension used by 40,000 people that adds full-text search to ChatGPT, Gemini, Claude and Grok. Each search result shows a snippet: a short window of the message with your word in the middle. This is the story of how a famous one-liner broke that window for Korean and Japanese text, why our tests never noticed, and the small change that fixed it.

The One-Liner Everyone Copies

The Stack Overflow question “Remove accents/diacritics in a string in JavaScript” had been viewed 592,224 times as of October 2026. Its top answer, at a score of 2,101, is this:

const str = "Crème Brûlée"
str.normalize("NFD").replace(/[̀-ͯ]/g, "")
> "Creme Brulee"

normalize("NFD") splits a precomposed letter into a base letter plus a combining mark, so "è" becomes "e" followed by U+0300. The regular expression then deletes every mark in the range U+0300 to U+036F. Our version lowercased first and mapped a few atomic letters such as "ł" and "ø", and we ran it on both the query and the text, so "skoda" and "Škoda" both became "skoda".

The answer is correct for what it was asked: comparing strings. The bug came from what we did next. To build a snippet, we found the match in the folded text and then cut the original text at the same position. Our own comment said why that was safe:

“the folded string keeps the SAME length and the SAME character offsets as the lowercased original. That length-preservation is deliberately relied on by the snippet/highlight code”

And it said why other scripts were not at risk:

“Non-Latin scripts (CJK, Arabic, Hebrew, Cyrillic) carry no combining marks to strip and pass through unchanged”

Both sentences were wrong. Here is the snippet code from our Gemini module, as it shipped in July:

export function getContextSnippet(content: string, query: string, contextChars: number = 58): string {
  // Accent-folded, length-preserving lookup: an accent-insensitive query still
  // centres the snippet on the match, and the offset is valid on the original.
  const matchIndex = foldAccents(content).indexOf(foldAccents(query));

  if (matchIndex === -1) return content.substring(0, contextChars * 2);

  const start = Math.max(0, matchIndex - contextChars);
  const end = Math.min(content.length, matchIndex + query.length + contextChars);
  let snippet = content.substring(start, end);

matchIndex comes from one string. content.substring cuts another. The ChatGPT, Claude, Grok and cross-app search modules each had their own copy of the same pattern, five in all.

What NFD Actually Does to Korean

NFD does not only split accented Latin letters. It decomposes anything that has a canonical decomposition, and the regular expression only removes marks in one block.

Every Korean syllable decomposes. “한” becomes three jamo, U+1112 U+1161 U+11AB. “가” becomes two. The Unicode normalization report, UAX #15, notes that “the decompositions and compositions for Hangul syllables are algorithmic”: a syllable splits into two jamo, or three when it has a final consonant. None of those jamo are in U+0300 to U+036F, so the regular expression keeps all of them.

Japanese voiced kana do the same thing. “が” becomes “か” plus U+3099, and “パ” becomes “ハ” plus U+309A. Arabic alef with madda, “آ”, becomes alef plus U+0653. Even MDN’s page on normalize() states it plainly: the NFD form of "ñ" has a length of 2.

So folding is not length-preserving at all for Korean. “한국어” is 3 characters and folds to 8. In the sentence “결론적으로 데이터베이스”, the word “데이터베이스” sits at position 6 in the original and at position 14 in the folded text, and the whole sentence grows from 12 characters to 26.

One more claim in that comment was off. Cyrillic does not pass through unchanged: “й” decomposes to “и” plus U+0306, so it folds to “и”, and “ё” folds to “е”. Searching Russian is still accent-insensitive in the way Russian readers expect for “ё”, so we kept that behavior and corrected the comment.

Three Months of Previews That Missed the Word

Feed a position from the folded text into the original, and the snippet window lands two to three times too far along a Korean message, because every syllable before the match counts as two or three.

I ran the July code against a Korean message with “데이터베이스” in the middle. The word starts at position 138; the folded text put it at 274, so the window it returned was a stretch of the message well after the word, and the preview never showed it. With the word near the end of a message, the computed start fell past the end of the text, substring returned an empty string, and the preview was just "...". Japanese text drifted by one position for every voiced kana before the match, so its previews were off-centre rather than empty.

Nothing else looked wrong, which is why it lasted. Matching folded both sides the same way, so Korean searches found the right messages. Our tests checked matching and highlighting, and none of them sliced Korean text. Before July 23 every snippet builder used toLowerCase().indexOf(), which keeps the length for these scripts, so the bug arrived in the same commit that made search accent-insensitive.

The Second Bug Hiding Next to It: \b

Exact Match, a Premium option in our Advanced search, matches whole words only, and JavaScript’s word boundary does not know what a word is outside English.

MDN’s word boundary page defines a word character as a letter from A to Z or a to z, a digit from 0 to 9, or an underscore. So /\bкот\b/.test("мой кот спит") returns false. A Korean, Cyrillic, Greek or Arabic term has no boundary for \b to find.

Our search already knew this. One helper adds \b only on a side where the term starts or ends with an ASCII word character, and otherwise falls back to a substring match:

export function exactWordPattern(term: string): string {
  const lead = /^\w/.test(term) ? "\\b" : "";
  const trail = /\w$/.test(term) ? "\\b" : "";
  return `${lead}${escapeRegExp(term)}${trail}`;
}

But the snippet builders in the ChatGPT and Claude modules, and the highlighter shared by all four, built their own \b...\b patterns. With Exact Match on, search found the Russian message and then the preview code could not find the word in it. In ChatGPT and Claude the result showed the whole message with nothing highlighted; in Gemini and Grok the window was right but the word was not highlighted. The fix was to use the same rule in all three places, so a term cannot match in search and then fail to match in its own preview.

The Fix: Return a Map, Not an Offset

Any transform that can change a string’s length has to give you a way back to the original. Ours now does, in one shared function that all five snippet builders call:

export function locateFolded(original: string, query: string | RegExp): FoldedMatch | null {
  if (!original) return null;
  const folded = foldAccents(original);
  let at = -1;
  let len = 0;
  if (typeof query === "string") {
    const needle = foldAccents(query);
    if (!needle) return null;
    at = folded.indexOf(needle);
    len = needle.length;
  } else {
    const hit = new RegExp(query.source, query.flags.replace("g", "")).exec(folded);
    if (hit) {
      at = hit.index;
      len = hit[0].length;
    }
  }
  if (at < 0 || len === 0) return null;
  if (folded.length === original.length && !HAS_MARK.test(original)) {
    return { index: at, length: len };
  }
  const stop = at + len;
  let pos = 0;
  let index = -1;
  for (const m of original.matchAll(CLUSTER)) {
    const start = m.index ?? 0;
    const next = pos + foldedLength(m[0]);
    if (index < 0 && next > at) index = start;
    if (next >= stop) return { index, length: start + m[0].length - index };
    pos = next;
  }
  return null;
}

Matching itself barely changed. It still folds the whole string once and calls indexOf; the only difference is Greek final sigma, below. What changed is that a match is translated back into the original before anything is sliced. Three details carry the weight.

It walks clusters, not characters. CLUSTER is /\P{M}\p{M}*|\p{M}+/gu: a base character plus the marks after it. NFD only reorders marks inside such a cluster, so folding cluster by cluster gives exactly the same string as folding the whole text. The one context-sensitive lowercase rule in JavaScript, Greek final sigma, would break that, so we now fold "ς" to "σ" as well.

It skips the walk when it can prove nothing moved. Folding only ever deletes combining marks. If the original has none, every character folds to at least its own length, so if the total length is unchanged, every character folded to exactly its own length and the offsets are already correct. That covers nearly all English and European text.

It counts Korean syllables with arithmetic. Korean text cannot take the shortcut, so foldedLength computes a syllable's folded length directly, two jamo or three, instead of normalizing it. A test checks that shortcut against normalize for all 11,172 Hangul syllables.

The first version of the fix walked every cluster of every message and took 29ms on a 100,000 character English message, against 0.6ms for the old code. With the shortcut it takes 1.1ms. A 100,000 character Korean message with the match at the very end, the worst case, takes 9.8ms. Real messages are far shorter, and the snippet runs once per visible result.

The Korean message whose preview missed the word now shows the sentence it sits in, 결론적으로 데이터베이스 마이그레이션은 미루기로 했습니다, with the word in the middle.

What I Would Tell Anyone Copying That Answer

The Stack Overflow answer is fine. It answers “make these two strings compare equal”, and for that it works. The bug is using its output as a coordinate system.

• If you only compare, you may not need to fold at all. new Intl.Collator(undefined, { sensitivity: "base" }).compare("cafe", "Café") returns 0, with no string changed. It cannot find a substring position, which is why search code folds instead.
• If you fold and need positions, keep a map back. Any offset found in a transformed string belongs to that string only.
• Test the scripts your users write in, not the ones you write in. One Korean sentence and one Japanese sentence in the snippet tests would have caught this in July.
• A comment that states an invariant needs a test that checks it. Ours said “length-preservation is deliberately relied on” in capital letters, and no test checked the length.

Key Takeaways

• normalize("NFD") changes string length for far more than accented Latin letters: every Korean syllable, Japanese voiced kana, and some Arabic letters.
• An offset found in a folded or normalized string is not an offset in the original. Map it back before you slice.
• JavaScript’s \b only recognizes the letters A to Z and a to z, the digits 0 to 9, and underscore, so whole-word patterns built from it never match Korean, Cyrillic, Greek or Arabic terms.
• Search, snippet and highlight code should share one matching rule. When they disagree, the result list contradicts itself.
• A fast path that proves offsets are unchanged keeps the fix nearly free for Latin text.

FAQ

Does normalize("NFD") change a string's length? Yes. NFD splits precomposed characters into a base plus combining marks, so "ñ" goes from length 1 to 2. Stripping U+0300 to U+036F restores the length only for accented Latin letters. Korean syllables become two or three jamo and Japanese voiced kana gain a sound mark, so those strings get longer.

Why does \b not work for Korean or Russian in JavaScript? In JavaScript a word character for \b is a letter from A to Z or a to z, a digit from 0 to 9, or an underscore. Korean, Cyrillic, Greek and Arabic letters are not word characters, so there is no boundary next to them, and /\bкот\b/ never matches "кот".

How do you make search accent-insensitive without breaking highlight positions? Fold the query and the text the same way for matching, then map the match back to the original string before slicing or highlighting. Folding cluster by cluster, a base character plus its marks, lets you record where each folded character came from.

Resources

• Remove accents/diacritics in a string in JavaScript, Stack Overflow
• String.prototype.normalize(), MDN
• Word boundary assertion, MDN
• UAX #15: Unicode Normalization Forms
• Intl.Collator, MDN

AI Toolbox adds full-text search to ChatGPT, Gemini, Claude and Grok, in whatever language your chats are in, Korean and Japanese included. Search is on the free plan. Exact Match and Advanced search are on Premium, at $9.99 a month, $59 a year or $99 lifetime per AI app, or $199 lifetime for all four with All Access. Add AI Toolbox to Chrome.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

AI Toolbox | Medium | Twitter/X | LinkedIn

The Accent-Stripping One-Liner Broke Our Search Results in Korean was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Editor’s note: I wrote this from my own audit of our website.

Disclosure: I co-founded AI Toolbox, and its website is the case study here.

On 26 October 2026 I ran Lighthouse on our homepage and it reported Accessibility: 100. On that same page, one word in a 36px heading sat at 2.94:1 against its background, where WCAG asks for 3:1. The white label on our footer’s main button sat between 3.6:1 and 4.4:1, where WCAG asks for 4.5:1.

Neither failure came from a bad color. Every color involved passes some test on its own. They fail as pairs, and a pair only exists where a color lands on a background.

That gap is not rare. WebAIM’s 2026 scan of the top one million home pages found low contrast text on 83.9% of them, up from 79.1% in 2025, with an average of 34 instances per page. It is the most common failure in that report. Our site gives each of the four AI apps our extension works with its own accent color, and puts those accents on white, on pale tints and on gradients. That is a lot of pairs. Over two audits, one in September and one this week, I found five ways a passing color still made a failing pair, or a failing pair still got a pass.

1. A brand color is not a text color

A color chosen for recognition usually fails as text on white, so a design system needs two tokens per brand color: one for decoration and one for text.

Our three borrowed accents measure, on white: Gemini blue #4285f4 at 3.56:1, Claude orange #d97757 at 3.12:1, and X blue #1d9bf0, which we use for Grok, at 3.00:1. WCAG success criterion 1.4.3 asks for 4.5:1 for normal text and 3:1 for large text, which it defines as 18 point, or 14 point bold, about 24px and 18.5px. Criterion 1.4.11 asks for 3:1 for the parts of a component you need to see. So all three accents are fine as borders, focus rings, icons and large headings, and none of them is fine as a paragraph or a button label.

X blue clears 3:1 by four ten thousandths: 3.0004. WCAG does not round. Its own guidance says a computed “4.499:1 would not meet the 4.5:1 threshold”, so a value just under the line is a fail, and any color even slightly lighter than X blue would fail as a border too.

Our fix is two custom properties per accent:

.accentGemini {
  --accent: #{$gemini-blue};
  --accent-strong: #{$gemini-blue--text}; // 5.4:1 with white
}

--accent paints tints, borders and glows. --accent-strong goes anywhere text meets the color, including white text on a solid accent fill. The text twins are #1967d2 at 5.37:1, #a8502e at 5.45:1 and #1177c9 at 4.66:1, so every one passes 4.5:1.

One more thing turned up while I checked these. Two files in our codebase disagreed about the same ratios. One comment said Gemini blue was 3.3:1 and another said 3.6:1. Both are plain comments that nothing checks, and the real value is 3.56. A comment that holds a computed number goes stale, so generate it or leave it out.

2. A tint is a new background

A color that passes on white has passed on white and nowhere else. Every tinted surface is a different background, and every text token has to be tested on each one it can land on.

Our muted gray #737373 measured 4.74:1 on white, a pass. Our sections sit on pale tints, so this is one gray, four backgrounds. On #f6f7fb it measured 4.43:1. On #eff8fe, 4.41:1. On #eef0f7, 4.16:1. That is three fails from one passing token, on backgrounds most people would call white. We replaced it with #666666, which measures 5.74:1 on white and 5.36, 5.34 and 5.04 on those three tints. In the proof sheet below, each number is printed in the gray it measures, on the background it was measured against.

The text twins from section 1 have the same weakness. Our X blue text color is 4.66:1 on white and 4.33:1 on its own 7% tint, #eff8fe, which is the panel we put behind its feature row. So that one surface got a third token, #0f66ab, at 5.57:1 on the tint.

So a text token’s comment should name its worst surface, not just white. Our muted gray’s comment now gives 5.7:1 on white and 5.0:1 on the #eef0f7 tints, which tells the next designer where the margin runs out.

3. Our own audit script turned failures into passes

A contrast checker that cannot read a color will usually guess, and the usual guess is white. Ours did, and it cleared two elements that Lighthouse had correctly flagged.

In September I wrote a script that starts at each text element, walks up through its ancestors to find the first solid background, and computes the ratio. It read colors from getComputedStyle() with a regular expression for rgb() and rgba(). Our tinted panels are built with CSS color-mix(), and Chrome reports a mixed color in a different form. I checked it again on 26 October in Chrome 156:

color(srgb 0.937961 0.972549 0.995882)

The regular expression never matched that string. The script skipped the tinted panel, kept walking up to the white page, and measured the text against white.

The fix was to stop parsing color strings and let the browser convert them, by painting each color onto a one pixel canvas and reading it back:

const ctx = document.createElement('canvas').getContext('2d', {willReadFrequently:true});
const norm = css => { ctx.clearRect(0,0,1,1); ctx.fillStyle = css; ctx.fillRect(0,0,1,1);
  const d = ctx.getImageData(0,0,1,1).data; return {r:d[0],g:d[1],b:d[2],a:d[3]/255}; };

The lesson is not about regular expressions. Before you trust a checker’s pass, show it a known failure and watch it fail. I had never done that, so I had no idea it could pass something by mistake.

4. Gradients are where automated checks stop

axe-core, the engine behind Lighthouse’s accessibility audits, does not measure text on a gradient. It sets the element aside for a person to review, and Lighthouse only counts passes and fails.

Deque’s documentation for the color contrast rule says: “This rule will not report on text elements that have a background-image". A CSS gradient is a background image. Lighthouse's scoring documentation says: "Each accessibility audit is pass or fail." An element that axe could not decide is neither, so it never touches the score.

On 26 October I ran axe-core 4.13.0 on our homepage with only the contrast rule switched on. It returned 0 violations, 340 passes and 99 results that need review. Ten of the 99 sat in our footer’s closing section, and every one of the ten carried the same message: “Element’s background color could not be determined due to a background gradient.” I measured those ten by hand. Eight passed. Two failed.

The first is the word “Claude” in the footer headline. It is 36px and extra bold, which makes it large text, so it needs 3:1. Its orange measured 3.12:1 on white, a pass. But the section has a 5% tint of our brand colors behind it, and at the word’s position the background was just dark enough to bring it to 2.94:1. A tint most readers would never notice took a passing heading under the line.

The second is the footer’s main button. Its label is white, 15.2px and bold, which is under the large text size, so 4.5:1 applies. The button’s three gradient stops measured 5.77, 3.71 and 3.12 against white, and behind the label the background ran from 3.66 to 4.41:1. No part of the label passed.

The fix for the heading already existed in our own stylesheet, two lines below the mistake:

&--claude { color: $claude-orange; }

&--grok { color: $grok-blue--text; }

The Grok accent used its text token. The Claude accent used the raw brand color. We swapped in $claude-orange--text, and the word now measures 5.14:1 at the same spot.

For the button, a gradient can be checked by hand, and which points you check depends on the text color. For light text on a gradient between hex colors, test the stops. The browser blends hex colors in sRGB, and that blend is never lighter than its lighter end, so the lowest contrast with white always sits on a stop. For dark text, stops are not enough. The middle of a blend can be darker than both ends, as a mix of pure red and pure green is darker than the red, so sample along it. I tested 20,000 random color pairs: white text never hit its worst point between two stops, and black text did in 5,002 of them. The chart below plots white text across the footer button’s gradient, from its left stop to its right stop.

The fixed button keeps the hue and darkens two stops: #5e6292 to #7d5aa8 to #a8502e, which measure 5.77, 5.38 and 5.45. By the rule above, every point between them is at least 5.38:1, and behind the label it now runs from 5.39 to 5.57:1.

5. A screenshot eyedropper reads a different color

A screenshot is not always in the color space WCAG measures, so eyedropping one can make a failing pair look like a pass.

To check the gradient math, I took a screenshot with the label hidden and measured its pixels. The numbers came back higher, from 4.18 to 5.20:1, which would have put part of the label above 4.5. The screenshot carried the display’s ICC color profile, and its pixels were 7 to 12 levels darker per channel than the CSS colors. At the label’s left edge the CSS gradient was rgb(131, 108, 181). The raw screenshot pixel said rgb(122, 95, 169). One pixel, three readings, once you count the corrected one below.

Converted back to sRGB through the profile embedded in the file, that pixel became rgb(131, 107, 180), within one level of the CSS, and the range across the label dropped to 3.61 to 4.44:1, within a few hundredths of the math. WCAG defines relative luminance for the sRGB color space, so sRGB is where the measurement has to happen.

The error ran in the dangerous direction. A darker background makes white text look better, so the screenshot made a fail look like a partial pass. Measure from the CSS values, or convert a screenshot to sRGB before you trust an eyedropper on it.

What we changed, and what the tools saw

We shipped two tokens for every brand color, a new value for the muted gray token, a third token for the one tint the X blue text color could not survive, and an audit script that converts colors through a canvas. After this audit we also fixed both footer failures from section 4, plus one more gradient I found while fixing them: a full-width purchase button elsewhere on the site, whose white label sat at 2.96:1 at its lightest point. It now measures 5.00:1 there.

Then I ran both tools again on the fixed homepage. Lighthouse reported Accessibility: 100, the same score it gave the page when both elements failed. axe marked the same ten footer elements for review, with the same gradient message. The fixes are real, and the tools could see them no better than they saw the failures.

These are the four checks I now run on every audit:

• Show the checker a known failure first, and confirm it fails.
• Test each text token on the darkest surface it can sit on, not on white.
• List every result the tool marked for review, and measure those by hand.
• Measure text on a gradient at the stops for light text, and along the blend for dark text, always in sRGB.

A score of 100 meant that every pair the tool could finish measuring had passed, before the fix and after it. It never said every pair on the page had been measured.

Key takeaways

• Contrast is a property of two colors. A design system that stores single colors cannot know whether its pairs pass, so test each text token on every surface it can land on.
• Give every brand color two tokens: one for decoration and one for text. Brand colors chosen for recognition rarely reach 4.5:1 on white.
• A pale tint is a new background. Ours moved a 4.74:1 gray to 4.16:1 and a 3.12:1 heading to 2.94:1.
• axe-core does not measure text on gradients, and Lighthouse scores only pass or fail, so a page can score 100 with failing text on a gradient.
• For light text on a gradient, check the stops. For dark text, sample along the blend. Measure in sRGB, not from a raw screenshot.

If you build design systems or audit them, follow me here on Medium. I write about what breaks between the design file and the shipped page.

About the author: Adi Leviim is a full-stack engineer and product builder with 7+ years of experience shipping commercial software to global audiences. He writes about AI UX, building for millions of users, and the design reality of shipping production AI tools. Follow him on Medium for essays on AI UX, founder engineering, and the gap between AI demos and production AI.

Medium | LinkedIn | Personal site

A 5% tint broke our contrast, and Lighthouse still scored us 100 was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our backend VM sat at 100% CPU for four days in September 2026. One user with about 50 ChatGPT tabs open sent 5,751 request batches in 28 minutes, and almost all of them were fetching data the browser already had.

The bug was not in the code that ran. It was in the number of places that ran it. I co-build a Chrome extension for AI chat apps, so the details below are ours, but the shape is not specific to extensions: it appears anywhere N clients share one piece of state and each one reacts independently to a signal they all receive.

The Trigger Belonged to Somebody Else

ChatGPT requests /backend-api/settings/user on every page load, and started doing it more often in late September 2026. We listened for that request because it carries the user's token, which makes it a natural signal that the signed-in account may have changed. Listening was reasonable. Treating it as rare was not.

That is the first transferable lesson, and it is the one I would tattoo on a junior engineer: if you key work off somebody else’s request pattern, you have taken a dependency on a number they can change without telling you, without a version bump, and without appearing in your changelog. When an input rate moves under a fixed multiplier, the result looks identical to a regression on a dashboard and is invisible in a diff.

The honest version of the postmortem is that the fan-out was always wrong. The vendor’s change did not create the bug. At most it raised the input. The multiplier was ours.

One Request Became N Times Ten

Here is what each of those signals did. The extension cleared its shared store, then told every open ChatGPT tab to reload its settings and libraries. That reload is up to ten requests per tab, each to a different endpoint: five for settings (language, theme, sound, default export format, OS preference) and five for libraries (prompts, prompt chains, pinned chats, pinned folders, smart tag rules). Users who switched prompts off skip two of them and free users skip the tag rules, so ten is the ceiling.

So with N tabs open, each tab’s page load triggered one settings request, and each settings request fanned out to all N tabs at up to ten requests each. Loading N tabs cost N times N batches.

Now the part that stings. The extension’s store lives in chrome.storage, which is shared by every tab in the browser and broadcasts changes through chrome.storage.onChanged. One tab's reload already refills the store for all of them. Every one of the other N minus 1 reloads was pure waste, however often ChatGPT asked. We had written a broadcast where a single assignment would have done, and the architecture that made it cheap to share state was the same architecture that made the broadcast pointless.

The Fix Is an Election, Not a Cache

The instinct in that situation is to add a cache. The right move was to stop doing the work N times, which means electing one actor and letting the shared medium do its job.

The refresh now reaches only the tab that made the request, at most once per tab per cooldown for the same account. A real account switch still reaches every tab, because correctness beats thrift: every tab must drop the previous account’s data immediately. The whole decision is one pure function:

export function planAuthRefresh(input: {
  tabId: number | null;
  previousEmail: string | null;
  tokenEmail: string | null;
  marks: ReadonlyMap<number, RefreshMark>;
  now: number;
  cooldownMs?: number;
}): AuthRefreshPlan {
  const cooldown = input.cooldownMs ?? REFRESH_COOLDOWN_MS;
  const prev = norm(input.previousEmail);
  const next = norm(input.tokenEmail);

  if (prev && next && prev !== next) return { kind: "all", slot: null };

  const unknown = !prev || !next;
  const slot = unknown ? UNKNOWN_ACCOUNT_SLOT : input.tabId ?? NO_TAB_SLOT;
  const mark = input.marks.get(slot);
  if (mark && norm(mark.email) === next && input.now - mark.at >= 0 && input.now - mark.at < cooldown) {
    return { kind: "skip" };
  }
  if (unknown || input.tabId === null) return { kind: "all", slot };
  return { kind: "tab", tabId: input.tabId, slot };
}

Two details in there are easy to miss. The cooldown is keyed by a slot, not always by a tab id, because two cases need a slot of their own. A request with no tab, which can come from a worker, has no tab id to key on, so it gets slot -1. A request whose account cannot be read refreshes every tab, so it is rate limited as one shared slot, -2, whichever tab sent it. Both therefore still get a cooldown and cannot spin. And the comparison input.now - mark.at >= 0 exists because a clock that jumps backwards produces a negative age, which would otherwise count as inside the cooldown and suppress refreshes until the clock caught up.

Electing a tab introduces a failure the broadcast did not have: the elected tab can close or navigate away before it does the work, and then no tab refills the store and every tab would read an empty prompt list until its own next refresh. So delivery is tried up to five times, 500 milliseconds apart, while the content script boots, and if the chosen tab disappears within a 15 second grace window, another tab is elected in its place. An election needs a re-election.

Put the Guard Under Every Trigger, Not Under the One You Found

This is the part I would want a reviewer to insist on. Deduplicating the trigger we had just debugged would have been a patch. Instead the decision sits in a second pure function that every path has to pass, whatever called it:

export function shouldLoadBackendData(
  last: BackendLoadMark | null,
  current: { email: string | null; resetId: unknown; now: number },
  cooldownMs = REFRESH_COOLDOWN_MS
): boolean {
  if (!last) return true;
  if (norm(last.email) !== norm(current.email)) return true;
  if (last.resetId !== current.resetId) return true;
  const age = current.now - last.startedAt;
  return age < 0 || age >= cooldownMs;
}

Four reasons to load, and everything else is a repeat of a load that already happened. The note at the top of that source file is the actual design document: That holds for every trigger, including any added later. A guard that lives next to one caller protects one caller. A guard that lives under all of them protects the code nobody has written yet, which in a codebase with several entry points into the same work is most of the risk.

On top of that sits a single-flight loader: one load at a time, and a request that arrives while a load is running is decided again when that load finishes rather than queued blindly, because the store may have been reset, or the account switched, in between. The subtle line is that the loader claims the running slot synchronously after its only await, so two requests arriving together cannot both start a load.

The Second Fan-Out Was a Cache Keyed Wrong

While fixing the first one we found a smaller version of the same shape, with a different cause. The extension captures a workspace header from ChatGPT’s requests, and it used to remember one value for the whole browser.

Two tabs open on different workspaces then alternated that single value on every request they made, and each flip was read as a real workspace change, which told every tab to refetch its folders and pins. One user, two tabs, and a memo that was supposed to prevent work became the thing generating it.

The fix is three lines, and the lesson is worth more than the code: a memo whose key is coarser than the fact it stores does not merely fail to help, it inverts into an amplifier. Remembering the header per tab means only a real change in a tab counts.

export function isNewHeaderForTab(seen: Map<number, string>, tabId: number, header: string): boolean {
  if (seen.get(tabId) === header) return false;
  seen.set(tabId, header);
  return true;
}

Why the Policy Is a Pure Function

Every piece of policy above takes its inputs as arguments and returns a decision: what to refresh, whether to load, whether this header is new. None of them touch the DOM, chrome.*, or the network. The plumbing that does touch those things is kept as thin as it can be.

That split is why there is a test file for this at all. You cannot write a unit test for “every tab reloaded and the VM caught fire”, but you can absolutely write one for “a request from tab 7 for the same account 1,000 milliseconds later should be skipped”. The suite asserts the cooldown boundary from both sides, a clock that moves backwards, case-insensitive email comparison, a refresh for a new account in a tab whose last mark belongs to the old one, and the two negative slots. I re-ran it before publishing this and it passes.

If you take one habit from the whole incident, take that one. Extract the policy from the plumbing, even when the policy is a handful of if statements, because a handful of if statements is exactly what you will get wrong at 2am while the graphs are red.

Conclusion

Everything in this story was individually correct. ChatGPT was right to ask who the user is. We were right to listen for it. Each tab was right to want its data. chrome.storage was right to broadcast. The outage lived in the multiplication, which is the one place nobody reviews, because the multiplication is not written down anywhere in the code.

So the question worth asking in review is not “is this call necessary?” but “how many copies of this will be running, and who told them to run?” From inside each tab, the answer to the first question looked like yes every time. The answer to the second was fifty.

Key Takeaways

• A shared store plus a broadcast is a quadratic fan-out waiting for an input rate to rise. One tab’s write already reached every tab through chrome.storage.onChanged; the other N minus 1 reloads were waste every time.
• If you key work off a third party’s request pattern, your amplification factor is a dependency on a number they can change silently. When ChatGPT started calling one endpoint more often, that change multiplied straight through our fan-out.
• Elect one actor instead of telling everyone, and then handle the failure an election creates: ours tries delivery up to five times and re-elects another tab inside a 15 second grace window if the chosen one closes.
• Put the guard under every trigger rather than next to the one you just debugged, so paths nobody has written yet inherit it.
• A memo whose key is coarser than the fact it stores inverts into an amplifier. Ours was browser-wide for a per-tab value, and two tabs on different workspaces flip-flopped it into a refetch storm.

FAQ

Why does a Chrome extension fan out to every tab at all? Because each tab runs its own content script with its own in-page state, so the obvious way to update the UI everywhere is to message every tab. It is unnecessary when the data lives in chrome.storage, which is shared across tabs and broadcasts through chrome.storage.onChanged, so one tab's write already reaches all of them.

How do you stop repeated reloads without breaking account switches? Separate the two cases in the policy. For the same account, refresh only the tab that asked, with a cooldown per tab, five minutes in our case. For a different account, refresh every tab with no cooldown at all, because every tab must drop the previous account’s data immediately.

What breaks when you elect a single tab to do shared work? The elected tab can close or navigate away before it finishes, leaving the shared store empty for everyone. Delivery needs retries while the content script boots, and a grace window, ours is 15 seconds, after which another tab is elected. An election without a re-election is a single point of failure.

Resources

• chrome.storage.onChanged, the shared, broadcasting store this bug was fighting against
• Message passing in Chrome extensions, including the connection errors the retry loop handles
• A cookie banner is an analytics outage, not a legal checkbox, on four other ways our own measurements were wrong
• ChatGPT’s API listed 775 of 10,500 chats and said that was all, on a vendor endpoint that misreports its own completeness

What is the largest amplification factor hiding in your codebase right now, and do you know what it is multiplied by? If you have ever had a vendor’s traffic pattern change underneath you, I would like to hear what it broke.

Follow me for more posts about building and measuring AI products. I write up the real incidents, including the ones where the bug was mine.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

AI Toolbox | Medium | Twitter/X | LinkedIn

Our Backend Ran Hot for Four Days. Every Open Tab Was Doing the Same Work. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a year the advice I followed was about access. Allow the crawlers in robots.txt. Ship an llms.txt. Add schema. Make the content machine-readable so the models can find you.

Then I read our server logs. In one week, ChatGPT-User, the bot that fetches a page live when somebody asks ChatGPT about it, hit our site 12,755 times across 499 distinct pages. Over the same period we appeared in about 4% of the answers the engine gave on our own subject area.

Access was never the problem. We were being read constantly and quoted almost never, and those are two entirely different events with two entirely different causes. I co-founded a Chrome extension company, so our site is the dataset here. Every figure below is ours, dated, and measured twice where I could manage it.

Your Crawl Log Already Says You Are Being Read

The bot that matters is probably not the one your robots.txt argues about. Ahrefs Bot Analytics recorded 338,935 bot visits to our site in the seven days to 2 September 2026. AI bots were 37,559 of those, 11.1% of all bot traffic, and the split inside that group is the finding.

GPTBot, OpenAI's training crawler and the one every "should I block AI?" blog post is about, visited 148 times. ChatGPT-User, which fires at the moment a real person asks ChatGPT something, visited 12,755 times. The retrieval bot outnumbered the training bot by roughly 86 to 1.

Before you act on that, read OpenAI’s own crawler documentation, because the three agents do genuinely different jobs and only one of them is the lever people think it is. GPTBot is the training crawler: "Disallowing GPTBot indicates a site's content should not be used in training generative AI foundation models." OAI-SearchBot is the one that governs whether you can show up at all: "Sites that are opted out of OAI-SearchBot will not be shown in ChatGPT search answers." And ChatGPT-User, the 12,755, is neither: "ChatGPT-User is not used for crawling the web in an automatic fashion. Because these actions are initiated by a user, robots.txt rules may not apply."

So the decision most sites agonize over, blocking GPTBot, has no effect on whether you appear in ChatGPT's answers today. The one that does is OAI-SearchBot, which visited us 2,958 times in the same week. And the volume leader, the user-initiated fetch, is not something you can tune at all. It is a readout, not a dial.

That reframes what a high retrieval count means. It is not a success metric. It means the index already considers you a candidate and real people’s questions keep reaching your pages. Everything after the fetch is a different fight.

One more detail from the same export, which I did not expect: our author page was the third most fetched page on the whole site by AI bots, behind only the homepage and a service worker file. Something in these systems is checking who wrote the thing.

Being Fetched and Being Cited Are Different Events

Citation share is the number that matters, and it is not one number. Pulling Ahrefs Brand Radar for the prompts in our category, our domain held 4.6% of cited responses on ChatGPT, against 32.1% for help.openai.com. An earlier pull, taken on 1 September 2026 when the dataset came back complete rather than capped, gave 4.2%. Two samples six weeks apart, the same answer.

Here is the part worth internalizing. Those are the same pages, the same domain, the same schema, measured across seven engines on the same day:

Claude cites us five times more often than ChatGPT does, on identical content. Google’s two surfaces, AI Overviews and AI Mode, disagree with each other by a factor of nearly three. Whatever “optimizing for AI” means, it does not mean one thing.

A caveat I owe you, because it changes how much weight the numbers carry: Ahrefs caps that endpoint at 250 pages per engine, and only the smaller datasets come back under the cap. The ChatGPT and Claude figures from September were complete. The rest are top-250 samples, so treat the middle of that chart as directional and the two ends as solid.

I Asked the Engine Why, and It Answered

In June 2026 we ran 65 category queries through ChatGPT and logged every citation. About 22% of them cited us at all. Then I did the obvious thing and asked it directly why it was not using pages it had plainly retrieved.

It said it discounts them. The words it used were “marketing-heavy”, “partially promotional”, “not neutral documentation”, and “third-party, not official”, and it said it cross-checks our claims against the official OpenAI, Anthropic and Google documentation rather than treating us as ground truth.

A model describing its own behavior is a self-report, not a mechanism, and I would not publish that on its own. What makes it worth reporting is that the prediction it implies is testable, and the test agreed. We win the queries where no official documentation exists, the gaps a vendor fills. We lose, consistently, every query where an official help page covers the same ground. That is the same sentence as “help.openai.com holds 32.1%", viewed from the other side.

If your category has thorough official docs, your ceiling is lower than the GEO blog posts imply, and no amount of schema markup changes it. Find the questions the official documentation does not answer. That is the whole strategy, and it is less satisfying than a checklist.

The Measurement That Changed How We Write

Citations per page flatters long pages. Citations per thousand words of prose does not, and it reorders the table completely. I measured prose only, the text inside paragraph tags, so navigation and footers could not inflate anyone.

Four competitors scored between 7.9 and 10.7 citations per thousand prose words. Our export pages scored 3.7. Our search pages scored 0.9. This is not a coverage problem: we had 36 export pages and 9 search pages at the time, more than anyone we measured. The winning pages clustered around 1,400 words of prose. Ours ran 2,100 to 2,900, with up to 243 list items and a heading roughly every 80 words.

We had been writing for a reader who scans, and producing something no engine wants to quote: a page with no quotable middle, only an index.

Then I found the control, which is the single most useful thing in this entire exercise. Two pages on the same domain, same author, same schema, same template, differing mainly in their first sentence:

The page that opened with Exporting a ChatGPT conversation means saving your chat history as a local file earned 11 citations. The page that opened with AI Toolbox, formerly ChatGPT Toolbox, adds full-text search to ChatGPT earned 2. Honest caveat: those two pages sit in different demand pools, 311 responses against 140, so the ratio is not attributable to the opening alone. But every winner we examined opened with the user’s problem or with the native method, and none of them opened with a product name.

We rewrote the second page. It now opens ChatGPT has built-in search that reads message text, not just conversation titles, which names the native behavior first and leaves the product to earn its place later. I would love to end this section with the lift that produced. I cannot: our measurement account has not refreshed since 24 September, so the after number does not exist yet. Treat the rewrite as a hypothesis with good odds, not a result, and be suspicious of anyone whose GEO case study never has that paragraph in it.

We also found a structural version of the same mistake. Our shared blog template rendered a full install card, complete with rating and user count, above the article body on every single post. An engine parsing the page met a sales widget before it met a fact. We moved it below the intro. That change is unmeasured too, and it is still the first one I would make on any site, because it costs an afternoon and it changes what a parser sees first.

Two Theories I Had to Throw Away

Negative results are the cheapest thing to publish and the rarest, so here are the two I was most confident about and both were wrong.

Promotional schema hurts you. We emit Product, AggregateRating and AggregateOffer markup from the root layout, which means it is on every page, including the page cluster that holds 62% citation share in its category and the one that holds 5%. Identical schema, opposite outcomes. Whatever is separating those pages, it is not the structured data.

Brand-named URLs get discounted. Neutral hub pages averaged 0.51 citations per page and brand-named hubs averaged 0.43, which looks like support until you notice the most neutrally named hub in the set scored 0.10, the worst of all of them. The naming convention is noise.

What survived testing was duller and harder: the opening sentence, the prose-to-scaffolding ratio, and cross-source agreement. That last one is the lever I had completely missed. A claim that appears only on your own domain reads to these systems as single-source and unverified, and duplicating it across your own pages still counts as one source. Getting a true, specific claim independently stated somewhere else is worth more than another page saying it louder at home.

What I Would Check First on Any Site

If you want to know where you actually stand, five measurements, in this order, will tell you more than any audit tool:

1. Split the AI bots by job, not into one “AI traffic” line. OAI-SearchBot is the one you can actually gate, ChatGPT-User is a readout of live demand, GPTBot is about a future model. Ours ran 2,958, 12,755 and 148 in the same week, and averaging them would have told me nothing.
2. Measure citation share per engine, never as an average. Ours ranges from 4.2% to 22.2% on the same content.
3. Compute citations per thousand words of prose. Per page rewards padding, which is how we spent a year writing 2,900-word pages that nothing quoted.
4. Read your own first sentence out loud. If it names your product before it names the reader’s problem, that is the cheapest fix available to you.
5. Look at what renders above your article body in the DOM, not in the design. Ours was a sales card, on 256 pages, for months.

Conclusion

The industry sold a crawling problem because crawling is easy to sell: it has a checklist, a file you can upload, and a yes or no outcome. Our logs say the crawling was solved long before we started worrying about it. What is left is a selection problem, and selection is editorial. These systems are deciding, every time somebody asks a question, whether your page reads like a source or like an advertisement. Ours read like an advertisement, and the engine said so in plain language when I asked.

That is a harder problem than schema markup, and it has the advantage of being the same problem good technical writing always had.

Key Takeaways

• Retrieval is not the bottleneck. ChatGPT-User fetched our site 12,755 times in seven days, across 499 pages, while we held about 4% of the engine's citations in our category.
• GPTBot visited 148 times in the same week, and blocking it affects training, not answers. OpenAI documents OAI-SearchBot as the agent that decides whether you appear in ChatGPT search answers, and says robots.txt "may not apply" to the user-initiated ChatGPT-User at all.
• There is no single “AI visibility” number. Identical content scored 4.2% on ChatGPT and 22.2% on Claude in the same measurement.
• Citations per thousand words of prose beat citations per page as a diagnostic. Competitors scored 7.9 to 10.7, our export pages 3.7, our search pages 0.9, and the winners clustered near 1,400 prose words.
• Asked directly, ChatGPT described our pages as “marketing-heavy” and “not neutral documentation” and said it cross-checks them against official vendor docs. That is a self-report, but the prediction it implies held up: we lose every query an official help page already answers.

FAQ

Does blocking GPTBot remove me from ChatGPT answers? No. OpenAI documents GPTBot as the training crawler, and says sites opted out of OAI-SearchBot "will not be shown in ChatGPT search answers". OAI-SearchBot is therefore the agent that controls visibility. In our logs for the week to 2 September 2026, GPTBot visited 148 times, OAI-SearchBot 2,958 times and ChatGPT-User 12,755 times.

Why does an AI engine crawl a page and then not cite it? Because retrieval and selection are separate steps. The index decides which pages become candidates, and the model then chooses among them. Our site was fetched 12,755 times in a week while holding roughly 4% of ChatGPT citations in its category, which is a selection outcome, not a crawling one.

Which pages get cited most by AI engines? In our measurements, pages that open with the reader’s problem or the native method, run near 1,400 words of prose, and make verifiable specific claims. Pages that open with a product name, run 2,100 to 2,900 words and carry heavy list scaffolding scored between 0.9 and 3.7 citations per thousand prose words, against 7.9 to 10.7 for the pages beating them.

Resources

• Ahrefs Bot Analytics, the source of the per-bot crawl counts used here
• OpenAI’s crawler documentation, which distinguishes GPTBot, ChatGPT-User and OAI-SearchBot
• A deep dive into Search Console performance data filtering and limits, on why dimensional reporting undercounts
• ChatGPT’s API listed 775 of 10,500 chats and said that was all, on trusting what an API reports about its own completeness

Which bot is actually fetching your pages, and have you ever separated it from the training crawler in your logs? If you have citation-share numbers across more than one engine, I would like to know how wide your spread is.

Follow me for more posts about building and measuring AI products. I publish the real numbers, including the ones that proved me wrong.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

AI Toolbox | Medium | Twitter/X | LinkedIn

I Optimized Our Site So AI Could Find It. Finding It Was Never the Problem. was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

In June our GA4 property reported three different purchase counts for the same 28 days. One event recorded 9 purchases for every 100 that actually happened. Another recorded 167. The third was correct, and it was the one nobody had put on a dashboard.

Four months later the same property lost 78% of its sessions in two weeks, and the traffic was fine.

I co-found AI Toolbox, a Chrome extension used by more than 40,000 people, so every number below comes from properties I own and re-queried this week rather than from a vendor’s case study. Four separate undercounts over five months, four different mechanisms, and one thing in common: a number in an analytics UI is the output of a pipeline you assembled yourself, and these pipelines fail quietly and almost always downward.

The Tag That Loaded After the Event Fired

A client-side analytics event that fires on component mount will lose a race against any tag loaded with a deferred strategy, and the loss is total rather than partial. In our case the gtag.js snippet was mounted through Next.js as <Script strategy="lazyOnload">, while trackPurchase ran in a useEffect on the mount of /payment-success. For the 28 days to 9 June 2026, the browser purchase event recorded 8.8 purchases for every 100 that the server-side Measurement Protocol mirror recorded.

The ugly part is that nothing errors. window.gtag is simply undefined at the moment you call it, the event evaporates, and the dashboard renders a confident, wrong, much smaller number.

The fix is to separate the queue from the loader. Google’s snippet is two lines that touch no network, so they can run synchronously in the document head while the 100KB script arrives whenever it likes:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

With the stub inline, an event fired at mount is pushed onto an array and replayed when the real script lands. We moved it out of the deferred <Script> and into an inline tag in the root document in June 2026, and the client count converged on the server count.

The transferable rule is wider than Google Analytics. Any SDK you load asynchronously needs a synchronous queue in front of it, because the events you most want are the ones that happen earliest: a purchase on mount, an error on first paint, a bounce at 400 milliseconds. Those are exactly the events a loader race deletes.

The Metric With No Code Behind It

An analytics property can mint metrics that exist nowhere in your repository, so a code search is not an audit. Our third purchase number, purchase_completed, reported 167 events for every 100 real purchases, from a user count that matched the success page's page_view user count exactly. I grepped the site, the backend and the extension for the string and found nothing, because it was not code. It was a GA4 Admin rule under Data display, Events, Create event, cloning page_view on /payment-success.

That number had been sitting in a report for months. It was never a bug in the sense of a broken line; it was a metric somebody created in a web UI in 2025 and then forgot, and it inflated conversions by two thirds.

Four places can mint a metric without touching your codebase, and all four need checking when a number looks wrong: GA4’s created and modified events, a Google Tag Manager container, server-side tagging, and the SDK’s own automatic events. Write them into your onboarding notes, because the next engineer will grep, find nothing, and conclude the dashboard is correct.

The same comparison exposed a second gap worth knowing. For every 100 purchases the server mirror recorded, only about 83 users reported a page view on the success page at all, which puts roughly a sixth of our buyers behind a blocker or a failed script. If you key an ad platform’s conversion off a browser event, that is the fraction of your own customers you are bidding without.

The Consent Banner Is a Measurement Change

A consent banner that gates the tag changes what your analytics property measures, from traffic to the product of traffic and consent rate, and the step change looks exactly like a traffic collapse. We shipped ours on 16 September 2026 after a privacy scan flagged GA4 loading before consent. Our implementation is deliberate: the inline snippet in the root document only defines the dataLayer queue and sets every consent type to denied, and consent.ts injects gtag.js and Microsoft Clarity only once the visitor accepts.

Then the floor fell out. In the week of 7 September the site property recorded 19,596 sessions and 6,965 install_click events. In the week of 21 September it recorded 4,283 sessions and 2,254 install_click events, a 78% drop in sessions and a 68% drop in the event we treat as intent to install.

Over the same weeks the Chrome Web Store developer property, which Google maintains and our banner does not touch, recorded 2,020 real installs in the week of 7 September and 2,401 in the week of 12 October, the highest of the quarter. One button, two dashboards, opposite directions.

There is no modeled backfill for an implementation like ours, and Google says so in the prerequisites for behavioral modeling: consent mode must be enabled across all pages, and “Google tags load in all cases, not only if the user consents.” The property also needs “at least 1,000 events per day with analytics_storage='denied' for at least 7 days" plus at least 1,000 daily users sending granted events, over at least 7 of the previous 28 days. We send nothing while consent is denied, by design, so there are no cookieless pings to model from and no gap filling.

Our server-side mirror did not rescue the numbers either, because it honors the same gate: the Measurement Protocol call is wrapped in hasAnalyticsConsent(). That was the right call rather than an oversight. A server-side mirror that ignores the banner is not a measurement win, it is a consent bug with better uptime.

So the bug here was never the banner. The bug was that for four weeks we kept reading the property as if it described visitors, until I sat down to work out why a record month looked like the worst month of the year. Annotate the property on the day the banner ships, write the new definition of the metric next to the chart, and stop comparing across the boundary.

A Dimension Does Not Slice the Data, It Changes Which Data Exists

Adding a high-cardinality dimension to a Search Console query changes the population you are measuring, not just its breakdown, so a dimensional sum is never a total. Our weekly report used to call the Search Analytics API with dimensions=["page","query"] and sum the rows. The API caps rowLimit at 25,000 and defaults to 1,000, and a truncated response is a successful response, so the first version of that report quietly undercounted every page in the site.

Pagination fixes the truncation and reveals the bigger problem underneath. For 18 September to 15 October 2026, paged to exhaustion, the two calls disagree like this:

• dimensions=["page","query"]: 83,253 rows, 873,659 impressions, 6,641 clicks
• dimensions=["page"]: 845 rows, 3,235,252 impressions, 24,374 clicks

The query breakdown accounts for 27% of the clicks. The missing three quarters are not lost, they are withheld: Google defines anonymized queries as “those that aren’t issued by more than a few dozen users over a two-to-three month period,” and states that “while the actual anonymized queries are always omitted from the tables, they are included in chart totals, unless you filter by query.” There is no row for them in the API, so no amount of paging will produce them. The same post is explicit about where the data is complete: “For requests that don’t involve query or URL dimensions, such as countries, devices, and Search Appearances, Search Console will display and export all the data.”

For a long-tail site the ratio is brutal, and ours is long tail by construction. Keyword-level reporting is still the most useful view we have for deciding what to write, and it is a 27% sample of the traffic it is describing. Both statements are true at once, which is the only honest way to use it.

Even the two defensible totals disagree. The same window with no dimensions returns 3,110,784 impressions, about 4% below the page-grouped sum, because grouping by page changes the unit of aggregation from the property to the URL. When two correct queries differ by 4%, any analysis that hinges on 4% is not an analysis.

The rule I now apply everywhere: totals come from an undimensioned query, dimensions are for composition only, and an aggregate built by summing a paginated API is a hypothesis until a second query confirms it. I learned the same lesson the hard way from a listing endpoint that claimed to have reached the end of a 10,500 chat history after 775 rows. An API’s answer about how much data exists is a claim, not a proof.

Pick a Witness That Is Not in Your Pipeline

The cheapest protection against a silent undercount is a second source for each number that matters, chosen so that it cannot fail the same way as the first. The site property and the server mirror share a consent gate, so neither can audit the other. The Chrome Web Store developer property shares nothing with our site: different owner, different collection path, no banner of ours in front of it, which is why it was the thing that settled the argument in October.

Four practices came out of this, and all four are cheap:

Name the witness before you build the report. For installs it is the store’s own developer property. For orders it is the payment processor, not an event on a thank-you page. For search clicks it is an undimensioned Search Console total. For requests it is the CDN or server log, which no client-side blocker can touch.

Treat every instrumentation change as a data boundary. A banner, a tag migration, a consent update or an SDK upgrade all deserve an annotation on the property and a note in the weekly report, because six weeks later nobody remembers the deploy date and everybody can see the cliff.

Reconcile once a month, not once a crisis. Two numbers from independent sources, written down with the date. The gap itself becomes the metric: measured at the step change, our site property now records something like a quarter to a third of the traffic it used to record for the same or better demand, and knowing that ratio is nearly as good as having the true number.

Write down which numbers you have decided not to measure. We chose a stricter privacy posture over modeled analytics, and that choice costs us modeled sessions permanently. A documented blind spot is a design decision. An undocumented one is a bug waiting for someone to report a disaster that is not happening.

Key Takeaways

• A consent banner that gates the tag turns your analytics property into a measure of traffic times consent rate. Ours fell 78% in sessions in two weeks while real installs rose to a quarterly record.
• Behavioral modeling cannot fill that gap unless tags load before consent, which a strict implementation deliberately prevents. Google’s own prerequisite is that tags “load in all cases, not only if the user consents.”
• An async analytics SDK needs a synchronous queue in front of it. Our client purchase event caught 8.8 per 100 real purchases until the gtag stub moved inline.
• Metrics can be created in an analytics admin UI, a tag manager or a server container, so grep is not an audit. One of ours inflated purchases by 67% and existed in no repository.
• A dimensional sum is not a total. Grouping Search Console data by query returned 27% of the clicks for the same window, because anonymized queries have no row in the API.

FAQ

Why did GA4 sessions drop after we added a cookie banner? Under basic consent mode the Google tag loads only after the visitor accepts, so sessions from everyone who ignores or rejects the banner are never collected. The property now measures traffic multiplied by consent rate. Our site GA4 property fell from 19,596 sessions to 4,283 in two weeks with no change in real traffic.

Will behavioral modeling recover the missing GA4 data? Only with an advanced implementation. Google requires that consent mode run on all pages, that Google tags “load in all cases, not only if the user consents,” and that the property collect at least 1,000 events per day with analytics_storage='denied' for at least 7 days, plus 1,000 daily granted users. A tag that never loads sends no cookieless pings, so there is nothing to model.

Why does the sum of Search Console query rows not match the totals? Anonymized queries, which Google defines as queries not issued by more than a few dozen users over a two to three month period, are omitted from tables and from any query-filtered view while remaining in unfiltered totals. In our 28 day sample, page and query rows summed to 6,641 clicks against 24,374 for the page dimension alone.

Where should purchase or conversion events be measured instead of the browser? In a source that does not depend on the visitor’s browser: the payment processor for orders, the store’s developer dashboard for installs, server logs for requests. Our client-side purchase event recorded 8.8 events per 100 real purchases before the loader race was fixed, and roughly a sixth of buyers never reported a page view at all.

Resources

• Behavioral modeling for consent mode, prerequisites and thresholds
• Consent mode implementation guide, basic and advanced
• Search Analytics API query reference, rowLimit and startRow
• A deep dive into Search Console performance data filtering and limits
• Performance report, troubleshooting data discrepancies
• ChatGPT’s API listed 775 of 10,500 chats and said that was all
• I built a context meter for four AI chat apps, counting tokens was the easy part

Which of your dashboards has a witness that cannot fail the same way it does? If you have reconciled two independent sources recently and found a gap, I would like to hear the size of it.

Follow me for more posts about building and measuring AI products. I write up the real numbers, including the ones that turned out to be wrong.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

AI Toolbox | Medium | Twitter/X | LinkedIn

A Cookie Banner Is an Analytics Outage, Not a Legal Checkbox was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In July 2026 a customer told us our search was missing most of their ChatGPT history. Their account held about 10,500 chats. Our index held 775.

We assumed our sync was broken, because it usually is when numbers disagree like that. It wasn’t. ChatGPT’s own listing endpoint had served exactly 775 chats and then ended the list the way it ends every list, with nothing to say it had stopped early.

I co-founded AI Toolbox, the Chrome extension involved, so this is partly a story about our product and you should read it with that in mind. The engineering lesson travels further than the product: a paginated API you don’t own can tell you it is finished when it isn’t, and no amount of careful paging will catch it.

What the Listing Endpoint Actually Returned

ChatGPT’s web app loads chat history from an internal endpoint, GET /backend-api/conversations, paged with offset and limit and sorted with order=updated. It is not a public API. Everything below was measured live in July 2026 on two accounts, ours at about 1,980 chats and the customer's at about 10,500, and the behaviour could change at any time.

On the large account, the listing stopped at exactly 775 chats. Every offset past 775 returned a clean, empty page. Nothing failed, nothing returned an error, and the result was stable across repeated runs.

The detail that killed our first idea was which 775 chats came back. They were not the newest. On a list sorted by last update, the final page of the 775 covered December 2022 to July 2023, so the served set was scattered across the whole history. “Just sync from the old end” was dead on arrival, because there was no old end to reach.

Two smaller facts from the same session are worth knowing if you ever touch this endpoint. order=created returns a 500, so the list only sorts by update time. And the archived list (is_archived=true) is a separate set, which was complete on every account we checked.

Why the total Field Couldn't Warn Us

The response carries a total field, and our first instinct was to compare it with what we had collected. That doesn't work, because total is not the size of the library. On both accounts it behaved like a has-more flag dressed up as a count:

// What `total` measured on both accounts (July 2026):
//   more pages exist:  total === offset + items.length + 1
//   final page:        total === offset + items.length
const isLastPage = page.total === offset + page.items.length;

That rule is a reliable end-of-list signal, and on the 10,500-chat account it fired at 775. The API wasn’t lying about its own pagination. It was accurately describing a list that had been cut short somewhere we couldn’t see.

This is the general trap. A client that pages until the server says “done” has verified the server’s statement, not the data. If the only source of truth is the paginated list, a hidden cap and a complete list look identical from the client side. You need a second, independent index to compare against.

ChatGPT’s Own Search Had the Whole History

ChatGPT’s search, opened from Search in the sidebar, runs on a different endpoint, GET /backend-api/global/search, and its index covered the full history, including everything the listing hid. On the customer's account, native search found 2023 chats that no listing walk could reach, and those chats opened normally by URL.

OpenAI’s help center says the same thing in its own words: “An older chat that is no longer visible in the sidebar has not necessarily been deleted. Search for a word or phrase from the conversation to find and reopen it.” If old chats seem to have vanished from a large account, search for a word you remember before assuming they are gone.

For a recovery tool, the search endpoint had three useful properties:

• limit tops out at 40. A request for 41 returns a 422 with a clean validation message.
• Cursor walks had no depth cap we could find. One query walked 54 pages to natural exhaustion on the 1,980-chat account.
• One common token covered most of a library. A single walk for the letter “a” returned 95% of the known chats (1,881 of about 1,980 unique conversation ids).

So the fix was not to page the list harder. It was to treat search as a second index, walk it, and diff it against what we already had.

Turning Search Into a Recovery Walk

AI Toolbox’s Deep Import walks the search cursor to exhaustion for a handful of high-coverage single tokens, collects every conversation id the local cache doesn’t know, then fetches those chats through the same batch endpoint and save pipeline the normal sync uses. Simplified, the discovery loop looks like this:

const TOKENS = ["a", "e", "i", "o", "1", "и", "的", "ה", "ال"]; // Latin, digits, Cyrillic, CJK, Hebrew, Arabic

for (const token of TOKENS) {
  let cursor: string | null = null, pages = 0, added = 0;
  do {
    const page = await globalSearch(token, { limit: 40, cursor });
    for (const item of page.items) if (!known.has(item.conversationId)) { pending.add(item.conversationId); added++; }
    cursor = page.hasMore ? page.cursor : null;
  } while (cursor && ++pages < 500);
  walks++;
  // Stop once another full walk stops paying for itself.
  if (walks >= 2 && added < Math.max(10, Math.ceil(0.01 * librarySize))) break;
}
// Then: fetch `pending` 10 ids at a time and save through the normal sync pipeline.

Three choices in that loop did most of the work:

• Discovery is proportional to search pages, never to chats. On a 10,500-chat account a walk is about 265 pages, so finding the hidden chats costs several hundred requests, not ten thousand.
• The token list spans scripts. A Hebrew or Japanese history may barely contain the letter “a”, so the walk includes tokens that cover other alphabets.
• The stop rule is about marginal yield. After at least two walks, it stops when the latest walk adds fewer new chats than 1% of the library or 10 chats, whichever is larger.

Once fetched, recovered chats are ordinary cached chats. The sync’s prune step already refuses to delete chats just because a later, truncated listing doesn’t mention them, so the import runs once per device and never has to repeat.

Rate Limits Were the Real Design Constraint

The hardest requirement had nothing to do with search. A user must never get rate-limited by ChatGPT because of us. A one-time recovery that locks someone out of their own chats for an hour would be worse than the missing history.

So every Deep Import request goes through the same cross-tab request queue as the rest of the extension, which allows about 1.2 requests a second, and Deep Import adds its own 900 millisecond gap on top. That puts a long import at roughly half the rate a normal sync is allowed, and the user’s own chatting still goes first. A 429 pauses the whole queue and honours Retry-After. If a request stays rate-limited through every retry, the run parks itself as resumable instead of continuing to push.

The price of being polite is time. On a 10,500-chat account the scan and fetch take roughly 30 to 45 minutes of background work. Progress is saved to chrome.storage.local as it goes, so closing the tab pauses the run rather than losing it, and a heartbeat stops two open tabs from running it twice.

Detect for Free, Recover on Premium

Deep Import is part of AI Toolbox’s ChatGPT module, and the split between free and paid follows the cost of each step. Detection is free: after a full sync, at most once a week, the extension spends one search request, diffs that page against its cache, and shows an Older chats found card if 3 or more chats are missing from the list. Running the recovery itself is Premium.

You can also start it by hand. In AI Toolbox Settings, the last section, Data & Storage, has a row called Missing very old chats? (large accounts) with a Scan and recover button.

Before a fresh scan starts, a dialog says what will happen and how long it can take, because a silent 45-minute job is exactly the kind of wait people assume is broken.

When it finishes, the button reports how many chats it recovered, or “No hidden chats found” if the account was never capped. To install it, AI Toolbox is free on the Chrome Web Store. Premium for the ChatGPT module is $9.99 a month or $99 lifetime, and All Access for all four modules is $199 lifetime. Premium unlocks the extension’s features. It does not include ChatGPT itself.

On the 10,500-chat account that started all this, Deep Import has since run to completion. The cap was real, it was stable, and search reached past it.

Four Rules for Paginating an API You Don’t Own

These came out of this bug, but none of them are specific to ChatGPT:

1. “End of list” is a claim, not a proof. If completeness matters, compare the list against a second, independent index, even a sampled one. One search page a week was enough for us to detect the cap.
2. Look at which items you got, not just how many. The scatter of the 775 told us more than the count did. A cap that returns the newest items calls for a different fix than one that returns a random-looking slice.
3. Make discovery cost scale with pages, not items. Walking a search cursor and diffing ids kept discovery on a 10,500-chat account to several hundred requests.
4. Treat politeness as a hard requirement. Running below the host’s rate, yielding to the user and parking on persistent 429s cost us half an hour of wall-clock time and saved us the one failure users would never forgive.

Key Takeaways

• On a very large account measured in July 2026, ChatGPT’s /backend-api/conversations listing stopped at exactly 775 of about 10,500 chats and ended like a normal, complete list.
• The listing’s total field tracks pagination, not library size, so it cannot reveal a cap.
• ChatGPT’s own search index covered the full history, so searching for a remembered word is the first thing to try when old chats seem gone.
• AI Toolbox Deep Import walks that search index to recover hidden chats into search, folders and export. Detection is free and the recovery is Premium.
• The design constraint that shaped everything was never rate-limiting the user.

FAQ

Why are my old ChatGPT chats missing from the sidebar? On very large accounts, ChatGPT’s chat listing can stop early while looking complete. In July 2026 we measured one 10,500-chat account whose listing ended at exactly 775 chats, spread across its history. The other chats still existed, opened by URL and were found by ChatGPT’s own search.

How do I find an old ChatGPT chat that is not in my history list? Open Search from the ChatGPT sidebar and type a word you remember from the chat. OpenAI’s help center says an older chat missing from the sidebar has not necessarily been deleted, and search can find and reopen it. To bring all hidden chats back into one searchable index, AI Toolbox Deep Import, a Premium feature, recovers them.

What is AI Toolbox Deep Import? Deep Import is a Premium feature in the AI Toolbox Chrome extension’s ChatGPT module. It walks ChatGPT’s own search index to find chats the history list no longer shows, then adds them to AI Toolbox search, folders and export. Detection is free. A recovery on a 10,500-chat account takes about 30 to 45 minutes.

Can Deep Import get my ChatGPT account rate-limited? It is built not to. Every Deep Import request shares the extension’s request queue, about 1.2 requests a second, plus an extra 900 millisecond gap, so it runs at about half the normal sync rate. It pauses on rate-limit responses, honours Retry-After, and parks itself as resumable if limits persist.

Resources

• How to recover very old ChatGPT chats that are missing, AI Toolbox tutorial
• Finding your chats, projects, and files in ChatGPT, OpenAI Help Center
• chrome.storage API, Chrome for Developers

If your ChatGPT history is large enough to have hit this, try AI Toolbox free on the Chrome Web Store. The free plan detects hidden chats and searches every message it has indexed, and Premium runs the recovery for $9.99 a month or $99 lifetime.

Have you hit a paginated API that ended early without saying so? I’d like to know how you caught it.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

AI Toolbox | Medium | Twitter/X | LinkedIn

ChatGPT’s API Listed 775 of 10,500 Chats and Said That Was All was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Someone typed this sentence into Google, word for word:

“i’m looking for a tool that can connect to my chatgpt account and create individual transcripts for all the chat threads in a designated project.”

Google’s AI Overview answered by naming one tool. Within ten minutes, that person had subscribed, installed it and exported 65 threads from a single ChatGPT Project.

I know this because the tool is AI Toolbox, a Chrome extension I co-founded, and the buyer described the search to us afterwards. Read everything below with that bias in mind. I have tried to make the native route and the limits as clear as the product, because the request itself is one every heavy ChatGPT user eventually makes.

A ChatGPT Project is where the chats for one client, one course or one book end up living together. When that work is finished, handed over or about to be deleted, the project is the unit you want to keep. ChatGPT has no button for it.

ChatGPT Can Export Your Account, Not a Project

ChatGPT has no export option for a single Project. Its only self-service export covers the whole account: Settings, Data controls, Export, then Confirm export. OpenAI’s help article “Exporting your ChatGPT history and data” says “Exports can take up to 7 days to arrive” and “The download link expires 24 hours after you receive it.” It also says self-service export is not available in Business, Enterprise or ChatGPT for Healthcare workspaces.

Inside a project, OpenAI offers two related actions, and neither is an export. You can share a single chat, and “People with the link can view only the shared chat, not the project’s other chats, files, instructions, or history.” And you can delete the project, which OpenAI describes plainly: “Deleting a project permanently removes its chats and instructions, along with files stored only in the project.” The same paragraph ends with “This action cannot be undone.”

So the native path to keeping one project is to request everything, wait for an email, download it within a day and dig the project’s chats out of the archive yourself. I wrote about that wait in more detail in ChatGPT’s Export Can Take Seven Days. The Link Dies in One. Now What?, so here I will stay on the project case.

Why One Project Is the Unit People Want to Keep

A project is the natural unit to export because it already matches a real piece of work. The requests we see fall into four groups:

• A knowledge repository. The buyer above wanted one transcript per thread, so the project could live as files next to their other notes.
• A handover. A consultant finishing an engagement wants to give the client the project’s chats, not their entire ChatGPT history.
• Before deleting. Deleting a project is permanent, so the files are the only copy that survives.
• Shared projects. OpenAI’s help page says members “can archive or delete chats they own,” and when they do, other members “can no longer see it.” A file on your own disk does not depend on anyone else’s cleanup.

OpenAI does cover one of these cases natively. When you leave a shared project, you get the option to copy your chats into a new project named “Copy” plus the original name. That keeps the chats inside ChatGPT, which is useful, but it is not a file you can open anywhere else.

How to Export One ChatGPT Project as Separate Files

AI Toolbox adds an Export project item to the menu ChatGPT already shows for every project. Clicking it downloads one ZIP file that holds one file per chat, in Text, Markdown, JSON or PDF. It needs a Chromium browser, such as Chrome, Edge, Brave or Arc, and it runs on chatgpt.com.

1. Install AI Toolbox from the Chrome Web Store, then open chatgpt.com.
2. Open the project’s menu. In the left sidebar, move your mouse over the project and click its three dots. The three dots at the top of the project’s own page open the same menu.
3. Click Export project. It is the first item, above Share project.

1. Pick a format in the Select Export Format window and click Export.
2. Watch the count. A progress window counts each chat as it is written. If you stop it early, the archive keeps every chat that finished.

1. Open the ZIP. The file is named bulk_conversations_ plus the date. Inside is a folder named after the project, with one file per chat named after the chat's title.

Three behaviours are worth knowing before you rely on it. Very large exports ask where to save and write straight to disk, so a big project does not have to fit in memory. If ChatGPT stops returning the project’s chat list partway through, the export stops with an error instead of quietly handing you part of the project. And when two chats share a title, the second file gets a short ID added so neither overwrites the other.

What Is Inside Each File

Every exported chat carries its title, a link back to the chat on chatgpt.com, its dates and every message in order with who wrote it and when. The four formats package that differently:

The Markdown header is the part that makes a folder of transcripts behave like a database. Each file starts like this, with a model line added when ChatGPT reports one:

---
title: "Q3 launch plan"
date: 2026-08-03
created: 2026-08-03T09:12:44.000Z
updated: 2026-09-18T16:40:02.000Z
exported: 2026-10-14T08:30:11.000Z
url: https://chatgpt.com/c/<chat id>
source: AI Toolbox
---

Obsidian and most other Markdown tools read that block as properties, so you can sort a project’s chats by when they were last updated. The JSON format carries the same created_at, updated_at and exported_at fields for scripts.

What Is Free and What Is Premium

Exporting a whole project with more than one chat is a Premium feature of AI Toolbox. On the free plan you can export any single chat as Text, and a project that holds exactly one chat exports the same way. Markdown, JSON and PDF are Premium for every export.

AI Toolbox Premium for the ChatGPT module costs $9.99 a month or $99 once for lifetime access. All Access, which covers the ChatGPT, Gemini, Claude and Grok modules, is $199 lifetime. Premium is a subscription to the extension’s features. It does not include access to any AI model, and you keep paying OpenAI for ChatGPT as usual. AI Toolbox has 40,000 users and a 4.8 out of 5 rating from 996 Chrome Web Store ratings as of October 2026.

If you only need one project once, and you can wait, the native export is free and complete. It is the better choice when you want everything, including account data AI Toolbox does not touch.

The Question I Could Not Answer With a Feature

After the export, the buyer asked how to keep the transcripts current as the project keeps growing. They guessed they would have to remember to export each new thread by hand. The honest answer is that AI Toolbox has no scheduled or incremental export today. I checked the extension source before writing this, because I wanted the answer to be yes.

What works instead is re-exporting the whole project and extracting the new ZIP over the old folder. Because each file is named after its chat’s title, a chat that grew since last time replaces its older file, and the updated line in the Markdown header tells you which ones changed. It has three rough edges:

• A renamed chat arrives as a new file. The file with the old name stays behind until you delete it.
• A deleted chat’s file stays. For an archive that is usually what you want, but the folder stops being an exact mirror of the project.
• Same-titled chats can swap names. Which of two identically titled chats gets the ID suffix depends on the order of that export, so check those two by their url line.

That is a workable routine for a weekly or monthly refresh. It is not the same as a folder that updates itself, and I would rather say so here than have someone find out after paying.

What the AI Overview Got Right

The answer that sent us this customer ended with: “exporting a full grouped Project into a compressed ZIP file is a feature restricted to their Premium plan ($9.99/month or lifetime options).” It told the searcher what was paid before they ever reached our site.

That is one buyer, so I would not build a theory on it. But it matches what we see elsewhere: when a page states plainly what is free and what is paid, an AI summary repeats it accurately, and the buyer arrives ready. When a page is vague, the summary fills the gap with a guess, and the guess becomes a refund request. Writing the gating down clearly turned out to be a sales decision, not a legal one.

Key Takeaways

• ChatGPT has no export for a single Project. Its self-service export covers the whole account, can take up to 7 days, and the link expires 24 hours after you receive it.
• Deleting a ChatGPT Project is permanent, so export its chats first if you might need them.
• AI Toolbox adds Export project to ChatGPT’s own project menu and saves one file per chat in a ZIP, in Text, Markdown, JSON or PDF.
• Whole-project export is Premium. One chat, or a project holding one chat, exports free as Text.
• There is no scheduled export. Re-exporting and extracting over the old folder keeps a repository current, with three rough edges.

FAQ

Can you export a single ChatGPT Project? Not natively. ChatGPT’s self-service export covers the whole account and can take up to 7 days to arrive. The AI Toolbox Chrome extension adds an Export project item to each project’s menu that downloads one ZIP with a file per chat, in Text, Markdown, JSON or PDF. Exporting a project with more than one chat is a Premium feature.

What happens to the chats when you delete a ChatGPT Project? OpenAI’s help center says deleting a project permanently removes its chats and instructions, along with files stored only in the project, and that the action cannot be undone. Files saved separately in Library are not deleted. Export the project’s chats before deleting it if you might need them later.

Is exporting a ChatGPT Project free with AI Toolbox? Partly. AI Toolbox’s free plan exports any single ChatGPT chat as Text, and a project that holds exactly one chat exports the same way. Exporting a whole project with more chats, or using Markdown, JSON or PDF, needs Premium at $9.99 a month or $99 lifetime for the ChatGPT module.

Can AI Toolbox keep a ChatGPT Project export up to date automatically? No. AI Toolbox has no scheduled or incremental export as of version 5.0.54. To refresh a repository, export the project again and extract the ZIP over the old folder. Files are named after chat titles, so updated chats replace older copies, while renamed chats arrive as new files.

Resources

• Exporting your ChatGPT history and data, OpenAI Help Center
• Projects in ChatGPT, OpenAI Help Center
• How to export a ChatGPT Project, the full guide on ai-toolbox.co

If you keep work in ChatGPT Projects, try AI Toolbox free on the Chrome Web Store. The free plan includes folders, search and single-chat Text export, and Premium unlocks whole-project export for $9.99 a month or $99 lifetime.

I am still deciding whether a scheduled export is worth building. If you keep a project as files, would you want it refreshed on a schedule, or is exporting on demand enough? Tell me in the comments.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

AI Toolbox | Medium | Twitter/X | LinkedIn

Go to ChatGPT, open Settings, Data controls, Export data, and confirm. Then read what OpenAI’s help centre tells you to expect:

“Exports can take up to 7 days to arrive.”

“The download link expires 24 hours after you receive it.”

So the official way to get a copy of your own conversations is a queue you cannot see, followed by a window you can miss. If the email lands while you are away for the weekend, you start again.

There is a third line worth knowing before you plan around it:

“An export cannot restore chats that have already been deleted.”

And self-service export is not available at all in ChatGPT Business, Enterprise or Healthcare workspaces. Those go through the workspace owner.

I co-build a Chrome extension that exports AI conversations, so I have an obvious interest here. I will keep the claims to things you can check, and I will tell you plainly where the official export is still the better tool.

What the Official Export Is Actually For

It is a complete account archive. Not just conversations: the full ZIP of eligible account data, which is what you want if you are exercising a data right, leaving the platform, or need everything in one audited package. You can also request it through OpenAI’s Privacy Portal.

If that is the job, use it, and start it early because of the seven days.

What it is not good for is the ordinary case. You finished a long chat, you want that chat, as a readable file, now. For that, waiting a week for a ZIP of your entire account and then digging through JSON is the wrong shape of tool.

The Problem Underneath the Waiting

The seven days is the symptom. The reason people go looking for an export in the first place is usually something else, and a buyer described it to me more precisely than I would have:

“The problem is the access to the numerous chats. For example, in ChatGPT I can have projects as the main categorization and then it cannot directly read the full chat list even within a project, the only capability is to search and that is not friendly enough.”

That is the real complaint. Once you are past a few hundred conversations, the sidebar is not a list you can work with, search is the only instrument you have, and there is no way to select a set of chats and do one thing to all of them. ChatGPT has no multi-select. So “export” becomes the escape hatch: if I can get these out, at least I can grep them.

Which is why the official export disappoints twice. It takes a week, and when it lands it is a ZIP of your whole account rather than the fifteen conversations you actually wanted.

The Faster Path, Step by Step

This is the flow I use. It runs in the browser, against the conversation already on screen, so there is no queue and no email.

Step 1. Open Manage Chats. It lives behind the round AI Toolbox button at the bottom right of ChatGPT, not in the sidebar.

If you want to follow along, install the extension from the Chrome Web Store first. It is free and the first export below costs nothing.

Step 2. Tick the chats you want. Search and filters narrow the list first, which matters once you are past a few hundred conversations.

Step 3. Pick a format and export. Text, Markdown, JSON or PDF.

Step 4. You get files, not a queue. One file per chat, and a ChatGPT project comes out as its own folder.

What This Costs, Exactly

I would rather you read the real split than find it at the moment you click.

Free: one chat, as TXT. On every platform, from the export dialog, as a plain .txt file rather than a ZIP. That is the whole free export, and it is permanent, not a trial.

Premium: anything beyond that. A second chat in the same action, or any other format, so Markdown, JSON and PDF are paid, and so is exporting many chats at once.

It is $9.99 a month or $99 one time for a single platform, and $199 one time for all four. These are extension features, not an AI subscription, and they do not change anything about your ChatGPT plan.

If all you need is this one conversation as a text file, take the free one and do not pay me anything.

The Part That Decided It for Most People Who Tell Me

The same flow runs on Claude, Gemini and Grok.

A buyer put the reason better than my own marketing page does. They searched for how to create folders in ChatGPT, got two results, and told me afterwards: “I chose yours because I want it to work across Claude, Gemini, ChatGPT, etc.”

That is the honest differentiator. Single-platform tools are fine until you are the sort of person who has a research thread in Claude, a draft in ChatGPT and a search in Gemini, and wants one archive at the end of the week.

AI Toolbox is a Chrome extension used by 40,000+ people across 150+ countries to search, organize and export conversations in ChatGPT, Claude, Gemini and Grok, rated 4.7 out of 5 across 900+ Chrome Web Store ratings, with a permanently free plan. Cross-device sync of your folders and prompts is free on every plan.

Install it free on the Chrome Web Store, or read the full export guide with every format compared.

When to Still Use OpenAI’s Export

Three cases, and I would use it in all of them.

You want everything, including account data that is not conversations. The official ZIP is the only complete copy.

You are making a formal data request. Use the Privacy Portal, keep the record.

You are on a Business, Enterprise or Healthcare workspace, where self-service export is not available to you and the workspace owner has to run it anyway.

In every one of those, start it a week before you need it, and watch for the email, because of the 24 hours.

Key Takeaways

• OpenAI publishes both numbers: exports can take up to seven days to arrive, and the download link expires 24 hours after you get it.
• The official export cannot restore deleted chats, and is not self-service on Business, Enterprise or Healthcare workspaces.
• For a single conversation or a selected batch, an in-browser export returns files immediately, in TXT, Markdown, JSON or PDF.
• One chat as TXT is free on every platform. More than one chat, or any other format, is Premium.
• If you use more than one assistant, pick a tool that covers all of them, because the archive you actually want at the end of the month is not one platform’s.

FAQ

How long does a ChatGPT data export take? Up to seven days, per OpenAI’s help centre. The email can arrive sooner, but seven days is the published ceiling, and the download link then expires 24 hours after you receive it.

Can I export just one ChatGPT conversation? Yes. Open the chat’s three dot menu and export it. As a TXT file this is free on the free plan; Markdown, JSON and PDF are Premium.

Does the export include deleted chats? No. OpenAI states plainly that an export cannot restore chats that have already been deleted. Export before you delete, not after.

Does any of this work on Claude, Gemini or Grok? Yes, the same export flow runs on all four, which is the reason most people who write to me say they chose it.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

Try AI Toolbox free | AI Toolbox | Medium | LinkedIn

Three weeks ago I wrote about OpenAI retiring custom GPTs, because we build features that reference them and I wanted to know what would break. I assumed that was a story about one company.

Then on September 30, Google announced skills and said Gems are going away too.

Two of the three largest assistant vendors have now deprecated the same category of feature, the thing that lets you save a set of instructions as a named assistant, within three months of each other. I co-build a browser extension that syncs and searches conversations across ChatGPT, Gemini, Claude and Grok, so I had to go and read both migration notices properly. Here is what they actually say, where they differ, and the one thing worth doing about it this month.

Two Retirements, Eight Months

Google’s help page is blunt about the consumer side: “Starting in November 2026, Gems will go away on personal Google accounts and automatically transition to skills.”

The Workspace schedule is longer and comes with a hedge. Google’s own key dates put skills rolling out from October 5 in Workspace and October 13 in the Gemini app, Gems moving into the Settings panel on November 17, then “no sooner than March 1, 2027” for business and enterprise and “no sooner than June 1, 2027” for education.

OpenAI’s page is similarly specific: “Custom GPTs are scheduled to retire on Dec 11, 2026. For affected Enterprise workspaces with an approved deferral, the retirement date is Feb 11, 2027.”

If you are on a personal plan at either vendor, your deadline is this quarter.

What OpenAI’s Migration Actually Moves

OpenAI’s path is manual. You go to My GPTs and select Migrate to plugin, per GPT.

Three details in that FAQ are worth reading twice.

“Migration uses the GPT’s latest published version. Drafts and unpublished edits do not transfer.” If your best version of a GPT is an unpublished draft, it is not coming with you.

“Allow extra time for GPTs that use custom actions. Those integrations do not transfer automatically.” Custom actions are the part you wrote code for.

“After a GPT is migrated, the original remains usable until retirement but becomes read-only.” So migration is one-way in practice, and the clock on the original keeps running.

Google’s Is Automatic, Which Does Less Than It Sounds

Google’s path looks friendlier. Gems “automatically transition to skills”, and the Workspace post confirms it will “auto-migrate any Gems remaining in the Gemini app to draft skills in the Gemini app.”

Read that noun. Draft skills.

And the sentence after it is the one that matters if you work in Workspace: “Because skills in the Gemini app won’t automatically appear in Workspace, you’ll also need to recreate them in Workspace if you want to use them in Workspace apps.”

So the automatic migration produces a draft, in one surface, and does not cross into the surface where a lot of organisational use actually happens. Automatic is doing less work in that sentence than it appears to.

Why Both Landed on the Same Replacement

It is worth noticing that the two replacements are described almost identically.

Google calls skills “reusable prompts that guide Gemini.” OpenAI says plugins “can bring reusable instructions, reference files, and connected apps together, so your guidance can work alongside the tools and information a task needs.”

Strip the branding and both sentences describe the same thing: a block of reusable instructions that can be attached to whatever tools a task happens to need, rather than a standalone assistant you open on purpose.

That is a real architectural shift, and in fairness it is probably the right one. A custom GPT and a Gem were both destinations. You went to them. Skills and plugins are modifiers: they apply inside the conversation you were already having. Once an assistant can call tools, search the web and read your files on its own, a separate named bot for each job starts to look like a workaround for a capability the base model did not have yet.

The cost of that shift is borne by whoever built on the old shape. Which is the part the migration notices are about.

The Pattern Is the Point

Put the two migrations side by side and the common denominator is obvious.

Your instructions survive both. The text you wrote, the system prompt, the thing you actually spent an afternoon getting right, carries across in both cases.

Everything around it is negotiable. Custom actions do not transfer at OpenAI. Workspace placement does not transfer at Google. Unpublished edits do not transfer at OpenAI. Live status does not transfer at Google, because what lands is a draft.

That is not a criticism of either company. Migrating a container between two different architectures while preserving every integration is genuinely hard, and both of them published dates and details well in advance, which is more than a lot of deprecations get.

It is, however, a clear statement about what you own. You own the prose. The container holding it belongs to someone else, and it has a return-by date you did not choose.

What I Changed on Our Side

I will declare the interest plainly: I co-build AI Toolbox, a Chrome extension that syncs and searches conversations across four assistants, so this is not a neutral observation for me.

Here is the part of our code that made the Gems announcement land as a problem rather than a headline. Gemini keeps each Gem’s conversations in a separate bucket that the main conversation list never returns. To make Gem chats searchable at all, our sync has to enumerate the user’s Gems through Gemini’s own undocumented list call, then page each Gem’s history scoped to its own path.

We wrote that enumeration to fail quietly. If the call errors, or the response shape changes, it returns an empty list and Gem sync simply does nothing, while the main conversation sync carries on untouched. At the time that was ordinary defensiveness about an undocumented endpoint. In hindsight it is the only reason a platform-side rename does not take the whole sync down with it.

That is the transferable lesson for anyone building on top of someone else’s container: assume the container is temporary, and make every integration with it degrade to a no-op rather than an exception.

What we do not know yet is what the skills surface looks like from the outside: whether skill conversations get their own bucket the way Gem conversations do, whether there is an equivalent list call, or whether skill chats simply land in the main history and the special handling stops being necessary. I would rather the last one were true. Until the rollout finishes in mid-November there is no way to find out except by watching what the client actually requests, so that is what we are doing, and we are not shipping a guess in the meantime.

What to Do This Month

Four things, and the first one is the only one that really matters.

Save the instructions. Open every Gem and every custom GPT you rely on, copy the Instructions field, and put the text somewhere you control. A notes app, a repository, a prompt library, a text file. This costs ten minutes and it is the only step that makes the rest of the deadlines uninteresting.

Note what will not travel. If a GPT uses custom actions, write down what they called and how. If you use Gems inside Workspace, plan to rebuild them there.

Publish before you migrate, at OpenAI. Drafts do not transfer, so finish the edits first.

Check the drafts afterwards, at Google. An auto-migrated skill arrives as a draft, which means somebody has to look at it.

Key Takeaways

• Google is replacing Gems with skills and OpenAI is replacing custom GPTs with plugins. On personal accounts the dates are November 2026 and December 11, 2026.
• Workspace and Enterprise timelines run into 2027, with Google hedging as “no sooner than” March 1 for business and June 1 for education, and OpenAI offering February 11, 2027 only to approved Enterprise deferrals.
• OpenAI’s migration is manual and uses the latest published version. Drafts, unpublished edits and custom actions do not come with it.
• Google’s migration is automatic but produces draft skills, and it does not carry into Workspace, where you have to recreate them.
• The instructions text survives both. Keep a copy of it outside the vendor, because that is the only part you actually own.

FAQ

Are Gemini Gems going away? Yes. Google is replacing Gems with skills, which rolled out from September 30, 2026. Gems go away on personal Google accounts starting November 2026, no sooner than March 1, 2027 for business and enterprise, and no sooner than June 1, 2027 for education.

Do I need to migrate my Gems manually? Not in the Gemini app, where remaining Gems are auto-migrated to draft skills. You do need to recreate them in Workspace, because skills created in the Gemini app do not automatically appear there.

What happens to a custom GPT I already migrated? The original stays usable until the retirement date but becomes read-only, so finish any essential edits before you migrate.

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

Related: I Built Features on Top of Custom GPTs. OpenAI Is Retiring Them.

Try AI Toolbox free on the Chrome Web Store. The free plan includes folders, search and TXT export. Premium is $9.99 a month or $99 lifetime per module, and All Access is $199 one time for all four. These are extension features, not an AI subscription.

AI Toolbox | Medium | Twitter/X | LinkedIn

I co-build a browser extension that exports AI conversations, so people write to us about this a lot: they want a chat on paper. A transcript for a lawyer, a research log for a supervisor, a record of a diagnosis conversation to take to an appointment.

Last week I went looking for the Print button in ChatGPT, Claude and Grok. There isn’t one. Not in any of them, and not documented anywhere by any of the three vendors.

So I pressed Cmd+P. Chrome prepared a 17-page print job, and every page was blank.

This is the story of what the apps do give you instead, why the browser’s own print capture fails, and the one-line Express configuration mistake that made our replacement for it fail in exactly the same way, for completely different reasons.

Nobody Ships a Print Button

Start with what is actually documented, because the gap is wider than it looks.

ChatGPT has no print option. What it added instead, in a February 13, 2026 release note, is a change to text selection: Cmd+A “now selects only the conversation content, excluding surrounding interface elements.” That is a copy-to-clipboard improvement, shipped by a team that clearly knows people are trying to get the text out. It is not printing. Deep research reports download as PDF, Word or Markdown, but ordinary conversations do not.

Claude has no print option either. Public share links are view-only. Artifacts created from a template export properly (Documents to Word, PDF, Markdown or Google Docs; Decks to PPTX or PDF), and Claude can create files directly. But the conversation around the artifact is not covered by any of it.

Grok has a share link, revocable at grok.com/share-links, and a full account data download in Settings under Data Controls whose format is not documented anywhere. There is no single-chat export.

Three products that people use for hours a day, and the only documented way to get one conversation out as a document is to make it into something else first.

Why Ctrl+P Comes Out Blank

The browser can always print a page, so why 17 blank sheets?

Because the transcript is not there. ChatGPT renders messages as you scroll, and the print capture takes the page in its unrendered state. The DOM the printer serialises contains the scroll container and almost nothing else.

This is not a bug in the usual sense. Virtualising a long transcript is the correct call for scroll performance, and every chat UI of any size does it. But virtualisation makes an implicit trade that nobody writes down: the document only exists in the places you have looked at. Print, Find in page, Reader mode and “save page as” all assume the opposite.

The workaround everyone discovers is to scroll from the first message to the last, slowly, so the whole thing is realised, and then print. That works. It is also an instruction you cannot give a non-technical user with a straight face.

Worth saying plainly: I tested this on ChatGPT. I have not run the same test on claude.ai or grok.com, so treat the print preview as the proof on any app. If the pages are blank or the end is missing, the capture failed.

So We Built the Export Instead

Our extension renders a conversation to PDF server-side, which sidesteps the virtualisation problem entirely: the messages come from the API, not the DOM, so there is nothing to scroll.

That worked until a paying customer told us it did not. They had bought the plan specifically to export one long chat as a PDF, and got this instead:

“This chat is too long to build as a PDF in your browser”

Three Limits, Three Units

The reason that message appeared turned out to be three separate ceilings, none of which knows about the others.

A Chrome extension’s background worker gets about 30 seconds for a fetch. A server render of a very long conversation takes longer than that, so the request died in flight. The export then fell back to the in-browser rasteriser, which refuses anything above 200 pages. The customer saw the 200-page refusal and reasonably concluded the product could not do the thing they had paid for.

The Fix: Render It as a Job

The fix was to stop trying to do it in one request. Above a threshold, the conversation goes to the backend as a job: start it, poll, download.

/**
 * Content characters above which a conversation is rendered as a job.
 *
 * Equal to the backend's PART_BUDGET_CHARS: below it the backend would print
 * the job as a single part anyway, and the single request is measured at about
 * 1.2s there, far inside every timeout. Above it, the job path.
 */
export const LONG_PDF_CHARS = 300_000;

export function shouldRenderAsJob(messages: readonly HasContent[]): boolean {
  return contentChars(messages) > LONG_PDF_CHARS;
}

Three requests, each of which answers immediately, so none of them can outlast the 30-second worker limit. The backend prints the document in parts and joins them. Everything below the threshold keeps the single request it always had.

That shipped, and it worked.

The Bug the Fix Created

Now the part I actually want to write about.

Our Express app caps request bodies globally. Two routes legitimately carry a whole conversation as JSON, so they are exempted:

// The global parsers below cap bodies low (jsonWithRawBody defaults to 100kb;
// express.json to 1mb), so they'd reject a long conversation with 413 *before*
// it reached the route's own larger parser.
const LARGE_BODY_PATHS = new Set(["/export/pdf", "/context-mentions/summarize", "/usage/sync"]);

const skipLargeBody =
  (mw: RequestHandler): RequestHandler =>
  (req, res, next) =>
    LARGE_BODY_PATHS.has(req.path) ? next() : mw(req, res, next);

app.use(skipLargeBody(jsonWithRawBody));
app.use(skipLargeBody(express.json({ limit: "1mb" })));

Read the set, then read the route the fix added:

router.post("/export/pdf/jobs", exportJson, extensionAuth, pdfExportRateLimit, handler);

Set.has() is an exact match. /export/pdf/jobs is not /export/pdf. The route carries its own 10MB parser, but the global 100KB parser runs first and rejects the body before the route's parser is ever reached.

The whole point of the jobs route is conversations too big to render in one request. It is, by construction, the route with the largest bodies in the application. And it is the one route not on the list of routes allowed to have large bodies.

One 413, Four Steps to the Error

What makes this worth a thousand words is not the mistake. It is that the mistake is invisible.

Follow the 413 through:

export function readJobStart(status: number | null, body: unknown): JobStart {
  if (status === 404) return { kind: "unsupported" };
  if (status === 429) return { kind: "busy" };
  // ...
  return { kind: "failed" };
}

A 413 is not 404, so the client does not conclude the backend is too old. It is not 429, so it does not retry. There is no job id, so it returns failed. renderPdfAsJob then returns undefined, which is the same value it returns for any render that genuinely could not be produced, and the caller does what it does for every failed render: falls back to the in-browser rasteriser, which refuses above 200 pages.

So the user gets the exact error the job path was built to eliminate. No alert fires. The 413 never surfaces as a 413. A graceful degradation path, which is a good thing to have, is also a very effective way to hide a configuration bug for weeks.

What I Would Take From This

Four things, in rough order of how much they would have saved me.

An allowlist keyed on an exact path is a trap the moment a route grows a sub-path. req.path.startsWith() over a prefix list, or attaching the limit to the router rather than to a central set, both survive the next route. A Set of strings does not, and nothing warns you.

Put the limit next to the thing it limits. The body cap for /export/pdf/jobs lives in index.ts, about four hundred lines from the route it governs. Anyone adding a route in routes/export.ts sees the route's own 10MB parser and reasonably assumes that is the operative number.

Treat every fallback as a place a bug can hide. A fallback converts a loud failure into a quiet degradation, which is exactly what you want in production and exactly what you do not want while finding this. If a fallback fires, log why, with the status code, at a level someone actually reads.

Test the case the feature exists for. Every test we had used a normal conversation. The jobs route exists only for abnormal ones, and a fixture above 300,000 characters would have caught this on the first run.

Key Takeaways

• None of ChatGPT, Claude or Grok documents a Print option for a conversation. Printing from the browser is the only universal route, and on a virtualised transcript it can produce blank pages.
• Virtualised rendering silently breaks Print, Find in page and save-as. The document only exists where the user has scrolled.
• A Set.has(req.path) allowlist stops covering a route the moment that route gains a sub-path, and the failure mode is a 413 that looks like something else entirely.
• Keep request-size limits next to their routes, not in a central list in the app entry point.
• A fallback path is a bug silencer. Log the reason it fired.

FAQ

Can you print a ChatGPT conversation? Not with a built-in option, because there isn’t one. Press Ctrl+P or Cmd+P in a desktop browser, but scroll the whole conversation first and check the print preview before sending it, because a long chat can come out blank.

Why does my ChatGPT printout come out blank? ChatGPT renders messages as you scroll. If the print capture happens before a message has been rendered, that message is not in the DOM and does not reach the page.

Is there a free way to get a long chat onto paper? Yes. Export it as plain text and print that from any text editor. TXT export is on the free plan in our extension; the formatted PDF is the paid one.

Resources

• How to print a ChatGPT, Claude or Grok conversation, the step-by-step version of this, with the per-app detail
• Chrome Help: print from Chrome
• Express body-parser limits

About the author: Adi Leviim is the co-founder of AI Toolbox (formerly ChatGPT Toolbox), a Chrome extension with four modules (ChatGPT, Gemini, Claude, Grok) used by 40,000+ people across 150+ countries to search, organize, and export their AI conversations. He writes about the reality of building AI products with 7+ years of full-stack development experience. Follow him on Medium for honest takes on SaaS, AI tools, and shipping software that people actually use.

Try it free on the Chrome Web Store. TXT export is on the free plan; Markdown, JSON and PDF are Premium at $9.99 a month or $99 lifetime per module, and All Access is $199 one time for all four. These are extension features, not an AI subscription.

AI Toolbox | Medium | Twitter/X | LinkedIn

Four AI Apps, Zero Print Buttons, and One 100KB Cap in the Wrong Place was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.