DEV Community: NAN

The settings that produced your output are not in your output

NAN — Wed, 09 Sep 2026 04:39:43 +0000

Somebody drops this in a channel:

Gemini handles the edge case fine, look: [screenshot of an AI Studio response]

Three weeks later you try the same thing and get something else. Who was wrong?

Neither of you, probably. You ran a different experiment and had no way to know, because the thing that was shared was the output, and the output does not carry the conditions that produced it.

AI Studio is not a chat app

That framing matters. ChatGPT and Claude are products; you have a conversation and the conversation is the artifact.

AI Studio is a bench. You are tuning a prompt, and the responses are samples, not the point. The thing you are actually building lives around the transcript:

the system instruction, in its own collapsible panel above
the model and version, in a dropdown
temperature, top-p, top-k, output length, safety settings — in the configuration panel on the right
optionally a structured output schema

None of that is in the message stream. The transcript is one variable in an experiment whose other variables sit in surrounding UI.

Copy the transcript and you have copied the readout of a meter without noting what you were measuring.

The reproducibility bill

For a colleague to actually reproduce a result, they need every one of these:

Component	Where it lives	Survives a copy-paste?
The turns	message stream	yes
System instruction	collapsible panel	only if expanded
Model + version	dropdown	no
Temperature / top-p	right-hand config	no
Output schema	config	no
Seed	not exposed	n/a

Four of six are furniture, not content. And temperature above zero means even a perfect replication gives a different sample — which is fine, as long as everyone knows that is what happened.

The failure mode is not dramatic. Nobody notices the conditions are missing, because the output looks complete. It reads like a finding. It is a single draw from a distribution whose parameters nobody wrote down.

What to do about it

Put the parameters in the prompt file, not in your memory. If you are iterating seriously, keep a text file next to the work: model, version, temperature, top-p, and the system instruction verbatim. It is thirty seconds and it is the difference between an experiment and an anecdote.

Quote the system instruction when you share a result. It is the single highest-value piece of context. A response without it is uninterpretable — you cannot tell whether the model was clever or whether the prompt did the work.

Say the temperature out loud. "Temperature 0.2, three of three runs agreed" is a claim. A screenshot is a vibe. If you ran it once at 1.0, say that too; it is still useful, just differently.

Ask for structured output as a code block. If you want JSON to survive into a document as formatted JSON, it has to be rendered as a code block. Ask for it inside fences. Prose-shaped JSON exports as prose, because there is no block for anything to preserve.

Never share a screenshot as evidence. It captures the fewest variables of any method available and cannot be searched, quoted or diffed.

Disclosure

I build an export tool for this, so read the next part with that in mind.

Chat Exporter for AI Studio writes a session to Word, PDF, Google Docs, Notion, Markdown or JSON. It captures the system instruction alongside the turns, keeps every user turn and model response labelled and in order, and preserves code blocks and structured output as blocks rather than wrapped text. Free tier, paid for unlimited.

Here is the honest part, and it is the reason this article is not a pitch: it does not capture the model parameters. Temperature, top-p and the rest live in the configuration panel, which is not part of the conversation, so they are not in the exported document. If reproducibility is what you need, you still have to write those down yourself.

Same for the system instruction if its panel is collapsed — it has to be expanded to be on the page at all. And the export buttons only appear once there is at least one response, since they attach per message.

I would rather say that plainly than have you find out from a document that was missing half the experiment.

The general shape

This is not really about AI Studio. Any tool where configuration is separate from output has the same hole, and prompt benches are the current example.

The question worth asking of anything you export: could someone reproduce this from what I just saved? If the answer is no, the missing pieces are almost always the settings — and settings are exactly what interfaces put in side panels, where no export reaches.

If you run prompt experiments seriously, how do you version the config? I keep a plain text file per prompt, which works and is clearly not the right answer.

A Claude conversation is not a transcript any more

NAN — Wed, 09 Sep 2026 04:34:22 +0000

Export a Claude session that used Artifacts and read the result. It goes something like:

Me: Can you write the parser?
Claude: Here's a parser that handles the nested case.
Me: It breaks on empty input.
Claude: Good catch — I've added a guard clause.

Four turns, no parser. It reads like the commentary track of a film with the film missing.

The code was never in the message stream. It was in the Artifact panel the whole time, and the panel is a different document.

Two documents, one session

A plain chat log is one thing: an append-only list of turns. Whatever happened is in the list, in order. That model held for years and every export tool assumed it.

Artifacts break the assumption. You now have:

The conversation — append-only, chronological, and increasingly about something rather than containing it.

The artifact — a single document, revised in place. Turn three does not append to it; turn three replaces it. What you see is the current state, not the accumulation.

The relationship between them is not containment, it is reference. The chat discusses the artifact the way a code review discusses a diff.

Why this makes "export the conversation" ambiguous

There are at least three defensible things you could mean, and they produce genuinely different documents.

The transcript only. Faithful to the message stream. Useless on its own if the substance lived in the panel — that is the commentary-track output above.

The final artifact only. The thing you actually built. Loses every constraint you discovered along the way, which is often the expensive knowledge. Six months later "why is there a guard clause here" has no answer.

Both, stitched. The transcript with the artifact's final state attached, or interleaved at the point it was created. Most useful, most work, and requires deciding where the document goes in a stream that never contained it.

There is a fourth, mostly hypothetical: transcript plus every artifact revision. That would be the complete record. It is also not available to anything running on the page, because superseded versions are application state, not DOM — the same reason you cannot select text that has scrolled out of a virtualised list.

The panel has to be open

A practical consequence that catches people: if the Artifact panel is collapsed when you export, the artifact is not on the page to capture.

This is not a tool being lazy. Panels that mount their contents on open are the normal pattern, and an extension reads the rendered document, same as your clipboard does. Closed panel, no nodes, nothing to read.

Same story for extended thinking. Claude folds the reasoning away once the answer lands. Expand it first or it is not in the export.

The habit that fixes both: before you export, open everything you want to keep. Artifact panel, thinking block, any collapsed section. It takes five seconds and it is the difference between a record and a commentary track.

Long code is a separate problem

Claude will happily return several hundred lines in one block, which surfaces a formatting question rather than an extraction one.

In Word, long lines wrap rather than truncate. People see a line break mid-statement and conclude the export cut their code off. It did not — the content is there, the renderer is wrapping it. It is still miserable to read.

If the code matters more than the prose around it, export to Markdown and open it somewhere that does horizontal scrolling properly. A word processor is a poor code viewer and no export setting changes that.

Disclosure

I build one of these tools, so weigh this accordingly.

Chat Exporter for Claude writes a conversation to Word, PDF, Google Docs, Notion, Markdown or JSON. Long code blocks come out whole with indentation and language intact, rendered maths becomes a real equation object rather than a picture, extended thinking stays a separate marked block, and nested lists and tables map to their proper equivalents. Free tier, paid for unlimited.

It reads what is rendered, which is the honest limit. A collapsed Artifact panel is not in the export because it is not on the page. Superseded artifact versions are gone for the same reason. And long code in a .docx still wraps, because that is Word.

The shift underneath

We are past the point where a chat log is the record of what happened. The interesting output increasingly lives in a side panel, a canvas, an artifact — a document with its own lifecycle, referenced by the conversation rather than contained in it.

Every tool built on "a conversation is a list of messages" is going to keep quietly dropping the part you cared about. Worth checking what yours captured before you rely on it.

Has anyone found a workflow for keeping artifact history rather than just its final state? Copying to a repo at each step is the only thing I have, and it is manual.

Where does the answer end and the interface begin?

NAN — Wed, 09 Sep 2026 04:28:18 +0000

Paste a Microsoft Copilot answer into a document and read it back:

The endpoint returns JSON2 and supports cursor pagination3. Rate limits apply per key1.

Those digits are citation markers. On screen they are small superscript chips you click to see a source. In your document they are noise welded to the last word of each clause, and you get to pick them out by hand.

The obvious reading is "the clipboard mangled it". The more useful reading is that nobody ever decided what counts as the message.

A chat reply is not one thing

Open devtools on any assistant reply. The container holding "the answer" also holds:

the prose
inline citation references, inside the sentence flow
a sources list, usually collapsed
copy / thumbs-up / regenerate buttons
suggested follow-up chips
sometimes a model badge or timestamp

All of it lives in one subtree. There is no attribute that says this part is the answer and that part is furniture. The distinction exists in your head and in the CSS, nowhere else.

So when anything walks that subtree — the clipboard, an extension, a screen reader — it has to guess. And the guesses differ, which is why the same answer comes out differently depending on how you took it.

Why citation markers are the hard case

Most interface elements sit around the text. Buttons come after. Chips come below. A naive "take the paragraph" rule handles them fine.

Citation markers sit inside it:

<p>
  The endpoint returns JSON<sup class="citation"><a href="…">2</a></sup>
  and supports cursor pagination<sup class="citation"><a href="…">3</a></sup>.
</p>

That is one paragraph. The reference is a child of the sentence. Take the paragraph's text content and the digits come with it, because as far as the DOM is concerned they are the sentence.

This is also why they survive a paste that drops everything else. They are not decoration attached to the message; they are inline content inside a text node's neighbourhood.

Perplexity has the mirror-image problem, incidentally. There, the same structure means references get flattened to bare numbers and the links are lost — you keep the marker and lose the source. With Copilot in a document you tend to keep the marker and not want it at all. Same markup, opposite complaint, depending on whether you are archiving research or drafting prose.

There is no correct answer, only a choice

Three defensible positions, and which is right depends entirely on what the document is for:

Strip them. You are writing prose. The references were never going to be clickable in a printed doc anyway, and clean text matters more. This is what most people want most of the time.

Keep them as real footnotes. You are writing something that gets reviewed or cited. Convert each marker into a proper footnote and append the sources. More faithful, more work, and the output format has to support footnotes.

Keep them inline as links. You are pasting into Notion or a wiki where a numbered link still functions. Least transformation, but only works where links are live.

A tool that only does one of these will be wrong for somebody. Worth knowing which one yours picked.

The rest of the furniture

Once you start looking, the boundary question shows up everywhere in a chat export.

Follow-up chips are the sneakiest, because they read like content. "Would you like me to compare these?" is a sentence, sits in the message container, and lands in your document as though the assistant said it. It did not — the interface offered it.

Copy and feedback buttons usually contribute nothing to text content, so they vanish quietly. Usually.

Collapsed sources are absent unless expanded, which is a different failure again: the boundary was drawn correctly, but the content had not mounted.

Disclosure

I build an export tool, so read on accordingly.

Chat Exporter for Copilot takes the first position above: citation markers are stripped from the body so the exported text reads as prose. It writes to Word, PDF, Google Docs, Notion, Markdown or JSON, converts Copilot's KaTeX maths into a real equation object rather than an image, and keeps Markdown tables as tables. It works on both consumer Copilot and Microsoft 365 Copilot. Free tier, paid for unlimited.

Two things it does not hide. Follow-up chips are part of the message container, so if you export everything they come too — there is an answers-only mode precisely because that boundary is a preference, not a fact. And exporting mid-stream catches the pre-render state, so maths that has not been typeset yet exports as source.

The takeaway

Copy operations do not know what a message is. They know what a DOM subtree is. Everything you think of as "the answer" is a convention layered on top of markup that was designed for display, not extraction.

When an export brings along something you did not want, it is rarely a parsing failure. It is usually a boundary drawn in a different place than the one in your head.

If you export chats regularly: strip citations, footnote them, or keep them inline? I lean strip, but I suspect that says more about what I write than about what is right.

Getting maths out of ChatGPT and into Word without it turning into backslashes

NAN — Wed, 09 Sep 2026 04:04:47 +0000

Ask ChatGPT to derive something. You get a clean equation on screen. Copy it into a document and you get one of three outcomes:

\frac{-b \pm \sqrt{b^2-4ac}}{2a}

…or a jumble of characters that looks like the equation went through a blender…

…or, occasionally, a picture.

None of these is what you wanted, and which one you get is close to arbitrary. The reason is that "the equation on screen" is not one thing. It is several representations layered on top of each other, and copying picks one more or less by accident.

What is actually sitting there

The model emits LaTeX. A renderer — KaTeX and MathJax are the common ones — turns that string into something a browser can paint.

The important part is what the renderer leaves behind. KaTeX output looks roughly like this:

<span class="katex">
  <span class="katex-mathml">
    <math><semantics>
      <mfrac>…</mfrac>
      <annotation encoding="application/x-tex">\frac{a}{b}</annotation>
    </semantics></math>
  </span>
  <span class="katex-html" aria-hidden="true">
    <!-- dozens of absolutely-positioned spans -->
  </span>
</span>

Three representations, all present at once:

MathML — semantic. <mfrac> means "this is a fraction". Machines understand it.
The original LaTeX, tucked inside <annotation>.
Visual spans — the thing you actually see, built from positioned glyphs.

That third one is marked aria-hidden="true" because it is meaningless to a screen reader. It is a drawing.

Now the three bad outcomes make sense. Grab the visual layer and you get the blender output — those positioned glyphs in document order, which is not reading order. Grab the annotation and you get raw LaTeX. Only the MathML carries the structure, and it is invisible, so nothing grabs it by accident.

Why Word cannot just take MathML

Word does not store equations as MathML. It uses OMML — Office Math Markup Language, its own XML dialect living inside the .docx package.

So a faithful conversion is a chain:

LaTeX  →  MathML  →  OMML  →  equation object in Word

Word can do the middle step itself when you paste MathML, though which paste path triggers it is inconsistent across versions and platforms. Doing the conversion before the document is written is more predictable.

Google Docs is a separate problem again: its equation support is thinner, so the realistic target there is a rendered image or plain text, not an editable object.

That difference is worth knowing before you pick a destination. If you need to edit the maths later, Word is the format that can hold it.

The streaming trap

There is a timing failure that catches people and looks like a tool bug.

ChatGPT streams tokens. The LaTeX source appears in the DOM first, and the renderer runs a beat later. Copy during that window and you copy the source, because the rendered form does not exist yet.

This is why "it exported as backslashes that one time" is usually not random. Let the answer finish rendering, then take it.

What each route actually gives you

Ctrl+C into Word. Unpredictable. Depends on what your selection covered and which clipboard flavour Word asked for. Sometimes fine, often not.

Copy the LaTeX deliberately. If your destination speaks LaTeX — Obsidian, Notion, a repo, Overleaf — this is the best outcome, not a failure. Many renderers expose a copy-as-LaTeX affordance for exactly this.

Screenshot. Always works, always dead. Fine for a slide, useless in anything you will edit or search.

A converter that walks the chain. Reads the MathML that is already in the page and writes OMML into the .docx directly.

Disclosure

I wrote one of those, so weigh this accordingly.

Chat Exporter for ChatGPT exports a conversation to Word, PDF, Google Docs, Notion, Markdown or JSON. The maths path is the LaTeX → MathML → OMML chain above, so equations land in Word as real equation objects you can click into, rather than images or source strings. Code blocks keep their language label, and Markdown tables come out as actual tables. Free tier, paid for unlimited.

Its limits follow from the same mechanics. Export mid-stream and you get the pre-render state, same as copying mid-stream. Google Docs still cannot hold an editable equation, because that is a Docs constraint and no extension changes it. And images generated inside ChatGPT sit on short-lived URLs — on an old conversation those may already have expired at OpenAI's end, in which case there is nothing left to fetch.

The rule worth remembering

Rendered maths is a drawing next to a description. Copy tends to take the drawing. Anything that produces an editable equation is reading the description instead — the MathML that was sitting there the whole time, hidden behind aria-hidden.

When an export gives you backslashes, it read the annotation. When it gives you gibberish, it read the drawing. Neither is broken; both grabbed the wrong layer.

If you work with maths-heavy notes, which destination have you settled on? I have not found anything that beats Word for editability, and I would be glad to be wrong.

Your Grok research has a shelf life, and nobody warns you about it

NAN — Mon, 07 Sep 2026 08:15:25 +0000

Most AI answers are built from training data. They age, but they age quietly — the model said what it said, and that text is stable.

Grok is different in a way that matters if you keep notes. It reaches into live X posts and runs real-time search, so a lot of its answers are assembled from things that exist right now and may not exist next quarter.

I noticed this the boring way: I went back to a thread from a few months earlier, followed three citations, and got two "post unavailable" pages and one account that had gone private.

What decays, and how fast

Web link rot is well documented — studies of news and academic citations repeatedly land somewhere around a quarter of links breaking within a few years. Social posts are a harsher case than the average web page, for reasons that have nothing to do with servers going down:

Deletion is normal behaviour. People delete posts they regret, prune old accounts, or clear timelines wholesale. On the open web, deleting a page is unusual. On social, it is routine.
Edits are invisible after the fact. A post can change after it was cited. What Grok read and what you find later are not guaranteed to match, and there is no diff to consult.
Accounts go private or get suspended. The content still exists; you just cannot see it. This breaks a citation as thoroughly as deletion.
Visibility is account-dependent. Whether a given post resolves for you can depend on who you are logged in as.

None of that is a failure of Grok. It is what happens when an answer is grounded in a medium where the primary sources are individually owned and freely deletable.

Why this is worse than a normal dead link

A dead footnote in an article is annoying. A dead citation inside an AI answer is worse, because of what surrounds it.

The answer is still there, still fluent, still confident. The reasoning still reads as sound. Only the evidence underneath is gone — and prose does not visibly degrade when its sources vanish. You end up with something that looks exactly like a well-researched note and functions like an unsourced claim.

If you are using these threads for anything that gets revisited — a decision log, competitive research, a piece you will write later — that gap is the whole problem.

What archiving actually has to capture

Saving "the answer" is not enough. Three layers matter, and most quick methods drop at least one.

The claim. The prose. Every method gets this.

The evidence. The DeepSearch sources and the citations attached to specific statements. This is the layer that rots, so it is the layer worth capturing while it resolves.

The reasoning. Grok's Think mode output — the working, not just the conclusion. Six months later this is often the most useful part, because it tells you what the model considered and what it discarded. It is also the part most likely to be missing, since it collapses once the answer arrives.

A screenshot gets layer one and a picture of layers two and three that you cannot follow. A copy-paste usually gets layer one and drops the rest.

Practical habits

Archive at read time, not at need time. The moment you decide a thread is worth keeping is the moment its sources are most likely to still resolve. Coming back later is the failure mode.

Save the sources as URLs, not as numbers. A citation that survives as the character "3" is not a citation.

Push important sources to a web archive. For anything load-bearing, submit the URL to the Wayback Machine yourself rather than assuming someone else did. This is the single highest-value habit here and costs about ten seconds.

Keep the reasoning. Expand Think mode before you save. Future-you wants the working.

Timestamp it. "Grok, March" is a materially different claim from "Grok, today" when the underlying corpus is a live feed.

Disclosure

I build an export tool for this, so weigh the next paragraph accordingly.

Chat Exporter for Grok writes a thread out to Word, PDF, Google Docs, Notion, Markdown or JSON, with DeepSearch citations still attached to the statements they support and Think mode reasoning kept as its own block instead of folded away. It is one way to do the archiving-at-read-time habit without it being a chore.

It captures what a page can capture. It does not resurrect a post that was already deleted, and it cannot read an embedded X post, which renders in a cross-origin iframe. For anything you truly need to survive, the Wayback submission is the step that actually protects you, tool or no tool.

The short version

An answer grounded in a live feed inherits that feed's mortality. The text stays; the evidence leaves. If a thread is worth returning to, capture the claim, the evidence and the reasoning while all three still resolve — because the one that disappears silently is the one you will want.

Curious how others handle this. Do you archive AI research threads at all, or treat them as disposable?

Why Perplexity citations break the moment you paste them (and what to do about it)

NAN — Mon, 07 Sep 2026 08:02:34 +0000

A Perplexity answer is worth reading because of the little numbered chips scattered through it. Take those away and you are left with confident prose from an unnamed source — which is exactly what you get when you select an answer, hit Ctrl+C, and paste it into a document.

I kept hitting this while collecting research notes, so I went and looked at what the browser is actually doing. The answer turned out to be more interesting than "copy-paste is lossy".

What a citation actually is on the page

Those [1] [2] markers are not text. In the rendered DOM each one is roughly an anchor wrapping a styled span:

<a href="https://example.com/source" target="_blank" rel="noopener">
  <span class="citation-chip">1</span>
</a>

The number you see is a label. The value is the href next to it, plus the entry it points at in the sources list further down the page.

When you copy a selection, the browser puts several representations on the clipboard at once. The two that matter:

text/plain — a flattened string. Every element becomes its text content. The anchor disappears; 1 survives as the character "1".
text/html — a serialised fragment of the selected DOM, anchors and all.

So the information is not lost at copy time. It is lost at paste time, depending on what the destination asks for.

Why the destination decides

Paste into a plain-text field and you get text/plain. That is the whole story — the URLs were never offered.

Paste into Word or Google Docs and it asks for text/html, which does carry the anchors. In practice you still lose them, for two reasons.

First, the sources list lives outside your selection. Unless you deliberately scrolled down and included it, the chips now point at URLs while the reference list they belong to stayed behind in the tab.

Second, editors rewrite what they accept. Google Docs keeps simple <a href> but discards the surrounding classes, so a numbered chip collapses into a bare digit with a link buried under it. Word's HTML importer is more aggressive again. Neither is a bug exactly — they are sanitising foreign markup, which is the right instinct in general and unhelpful here.

There is a third failure mode people hit with Pro Search. A multi-step search renders progressively. Select while a step is still resolving and you copy the DOM as it exists at that instant, which is a partial answer with dangling references.

The options, honestly assessed

Print to PDF. Fastest thing that works. Ctrl+P renders the whole page, sources included, and the links stay clickable in most PDF viewers. The output is a screenshot of a web page — page furniture, sidebars, awkward breaks — so it is fine for an archive and poor for anything you intend to edit.

Paste as HTML deliberately. In Google Docs, paste normally rather than as plain text, then scroll up and copy the sources list separately. Tedious, but it costs nothing and the links survive.

Markdown by hand. If you already work in Obsidian or a repo, rewriting the citations as reference-style links gives you the cleanest artifact. It also takes the longest, so it only pays off for something you will reread.

A browser extension. Reads the DOM before the clipboard flattens it, walks the anchors, and writes a document with the references and the source list already reconciled.

Disclosure

I build one of those extensions, so treat the next paragraph as what it is.

I wrote Chat Exporter for Perplexity after doing the manual dance one time too many. It exports a thread to Word, PDF, Google Docs, Notion, Markdown or JSON, keeps the inline references pointing at their sources, and brings the source list along instead of leaving it in the tab. Pro Search threads come out as one document with the order of the investigation intact, and it behaves the same inside Spaces. Free tier, paid plan for unlimited exports.

Two honest limits. It reads what is rendered, so if the sources panel is collapsed those links are not on the page to capture — expand it first. And exporting mid-stream on a Pro Search gets you the steps that finished, same as selecting mid-stream does.

The part worth keeping

Whatever route you take, the rule underneath is the same: the citation is the href, not the number. Anything that reduces the page to its text content has thrown the answer's provenance away and kept its confidence, which is the worst half to keep.

If you do nothing else, expand the sources list before you copy. Most of the loss people blame on the AI is really the clipboard doing exactly what it was asked.

Curious what the other tools do here — if you have a workflow for keeping research citations intact across Perplexity, NotebookLM or similar, I would like to read it.

The moment you edit the Canvas, the document stops knowing who wrote it

NAN — Thu, 02 Jul 2026 10:10:49 +0000

Gemini drafts something in Canvas. You read it, disagree with a paragraph, and rewrite it in place. Then you fix a heading, delete a bullet, tighten the conclusion.

Export the result and you have a clean document. What you do not have — anywhere — is a record of which sentences were yours.

That is not a gap in the export. The document itself does not carry it.

Canvas is an editor, not a panel

This is the distinction that matters and it is easy to miss, because visually it looks like any other side panel.

A read-only panel holds output. Whatever is in it came from the model, so the provenance question never arises — the container answers it.

Canvas hands you a cursor. The moment you use it, the panel holds a document with two authors and no way to distinguish them. Your paragraph and the model's paragraph are the same kind of node in the same tree, styled identically, because in the editor's model they are the same kind of thing. It is a text editor. Text is text.

The transcript does not save you

The intuitive fix is that the chat records what the model produced, so you could diff.

You cannot, for two reasons.

The transcript records the model's turns, not the document's states. Gemini says "I've tightened the introduction" — that sentence is in the stream; the introduction it produced is in the panel, which has since been overwritten by the next revision.

And your edits leave no turn at all. You typed into a text box. Nothing was sent, nothing was logged, nothing appears in the conversation. From the transcript's point of view, your edits did not happen.

So the two records drift apart from the first keystroke. The transcript is a partial account of one author's contributions; the document is the merged result of two.

Why anyone should care

Disclosure. Plenty of contexts now ask you to declare AI assistance — coursework, journals, some workplaces. Try answering "which parts" honestly a week after a Canvas session. The truthful answer is usually "I no longer know", which is uncomfortable when the question was asked in good faith.

Review. A reviewer's attention is finite and should go where it is needed. Model-drafted passages want checking for confident wrongness; your own want checking for the things you always get wrong. A document that hides the seam gets uniform, thinner attention.

Your own memory. This is the one that bites soonest. Six months on, you cannot remember whether a claim was something you knew or something you accepted. Those are different epistemic states and the file records neither.

What actually helps

Edit outside the Canvas. Export first, then revise in your own editor. Now the export is a clean record of what the model produced, and your changes live in a file with a history.

If you must edit in place, do it in one pass at the end. Export before you start. Two artifacts, in order, and the diff between them is your contribution.

Say what you did, not what you used. "Drafted by Gemini, restructured and fact-checked by me" carries more than a checkbox, and you can write it honestly at the time — which is the only time you still know.

Disclosure

I build an export tool, so weigh this accordingly.

Chat Exporter for Gemini puts an export button in the Canvas toolbar, so the Canvas document exports on its own with headings, lists and code intact, separately from the surrounding chat. It also handles Gems, carries grounded sources across, and turns Gemini's KaTeX maths into a real equation object. Free tier, paid for unlimited.

It cannot tell you who wrote what, and neither can anything else that reads the page. That information was never recorded. What it can do is make the export-first workflow above cheap enough that you actually do it — which is the only version of this problem that has a solution.

The general point

Read-only output has provenance by construction. Editable output does not, and the interfaces are converging on editable.

Any surface where you can revise the model's work in place has this property, and none of them are tracking authorship at the span level. Until one does, the only reliable record of what you contributed is the one you make yourself, at the moment you make the change.

Genuinely curious whether anyone has solved this rather than worked around it. Span-level attribution in a collaborative editor is not a new problem — Google Docs has had suggestion mode for years — so the absence feels like a choice.

Export Your DeepSeek Chats to Word, PDF, Google Docs, Markdown & Notion in One Click

NAN — Thu, 21 May 2026 14:51:47 +0000

I Built a Chrome Extension to Export DeepSeek Chats

I use DeepSeek a lot for:

coding
documentation
research
writing But exporting conversations was frustrating.

Copy-paste usually breaks:

code blocks
tables
formatting
Markdown structure

So I built DeepSeek Exporter — a Chrome extension that exports DeepSeek chats into:

PDF
Word (.docx)
Google Docs
Markdown (.md)
Notion all in one click.

Features
Export entire chats or selected messages

You can export:

full conversations
only selected messages
only prompts
only AI responses
Markdown support

One feature I cared about most was preserving:

code blocks
tables
headings
lists

Useful for:

Obsidian
GitHub README
MkDocs
Logseq
Direct Notion export

You can push conversations directly into a Notion database.

Good for:

knowledge bases
research logs
AI archives
Custom styling

Before exporting, you can customize:

fonts
heading sizes
colors
alignment
Challenges While Building

Some difficult parts:

preserving Markdown formatting
converting tables consistently
handling nested code blocks
keeping exports clean across PDF/Word/Docs
Why I Built This

I wanted a faster workflow for saving AI conversations without messy formatting or manual cleanup.

Would love feedback from:

developers
writers
researchers
heavy AI users

What export format or integration should I add next?