ChatGPT o1 and o3 Export — What Appears in conversations.json and What's Hidden

What o1 and o3 reasoning models do differently

Standard language models (GPT-4, GPT-4o, Claude 3.5 Sonnet) produce responses by predicting tokens left-to-right from the prompt context. Reasoning models — o1, o1-mini, o3, o3-mini, o4-mini — add an internal deliberation step before producing the final response. This internal step, implemented as a sequence of "thinking tokens" not directly visible to the user, allows the model to explore solution paths, consider alternatives, and self-correct before committing to a final answer.

For architecture and engineering decisions, this has a practical consequence: reasoning models are better at tasks that benefit from explicit comparison of alternatives — database selection, infrastructure trade-off analysis, API design choices, security model evaluation. The deliberation that GPT-4 typically performs implicitly (and incompletely), o1/o3 performs explicitly in the reasoning chain before composing the final response.

The reasoning chain is not visible to users in the ChatGPT web UI

In the ChatGPT web UI, reasoning model responses show a collapsed "Thinking…" indicator while the model is reasoning, and then expand to show only the final response. The reasoning steps that appear during the thinking animation are a UI artifact — a streaming preview of the reasoning process, not the raw thinking tokens. After the response completes, the thinking animation is no longer accessible. The final response is what gets stored in the conversation history.

This is a deliberate design choice by OpenAI: the reasoning tokens are computed per-inference and are not persisted to the conversation history that backs the ChatGPT export. From the perspective of the conversation storage system, a reasoning model response is structurally identical to a GPT-4 response — a message with role "assistant" and a text content string.

What appears in conversations.json for o1/o3 conversations

The conversations.json export for o1/o3 model conversations uses the same schema as any other ChatGPT conversation. Each conversation is a JSON object with:

• id: UUID for the conversation
• title: Auto-generated or user-edited conversation title
• create_time / update_time: Unix timestamps
• mapping: A dict of message nodes, each with author (role, metadata), content (text or content parts), and create_time

For a reasoning model response, the message node looks like this:

{
  "id": "msg_abc123",
  "author": {
    "role": "assistant",
    "name": null,
    "metadata": {
      "model_slug": "o1-2024-12-17"
    }
  },
  "content": {
    "content_type": "text",
    "parts": [
      "To evaluate the trade-offs between PostgreSQL and CockroachDB for this
       workload, I need to consider three dimensions: consistency requirements,
       geographic distribution, and operational complexity...\n\n[full response
       text — typically 800-2000 words for a thorough architecture analysis]"
    ]
  },
  "create_time": 1733500800.0
}

What is not present in this node: no reasoning_tokens field, no thinking_steps array, no internal_reasoning object. The reasoning chain is absent from the export. The model_slug field in the author metadata is the only marker that distinguishes this from a GPT-4 response.

The model_slug field is not always present

The metadata.model_slug field appears in author objects for messages generated after OpenAI began including model metadata in conversation exports — approximately late 2024 and later. Older o1 conversations (o1 launched in September 2024) may not have the field. For conversations where the model_slug is absent, content-based heuristics are the only identification method.

How to identify o1/o3 conversations in your export

Method 1 — grep for model slugs

The most reliable identification method when the metadata field is present:

# List conversations that contain o1/o3/o4-mini model slugs
python3 -c "
import json, sys

with open('conversations.json') as f:
    conversations = json.load(f)

reasoning_models = {'o1', 'o1-mini', 'o1-preview', 'o3', 'o3-mini', 'o4-mini'}

for conv in conversations:
    title = conv.get('title', '')
    mapping = conv.get('mapping', {})
    models_used = set()
    for node in mapping.values():
        msg = node.get('message')
        if not msg:
            continue
        slug = msg.get('author', {}).get('metadata', {}).get('model_slug', '')
        if any(r in slug for r in reasoning_models):
            models_used.add(slug)
    if models_used:
        print(f'{conv[\"id\"]} | {list(models_used)} | {title[:60]}')
"

Method 2 — content-based heuristics

When model_slug is absent, look for these patterns in assistant message content that are characteristic of reasoning model responses:

• Explicit enumeration of alternatives: "There are three main options here: [A], [B], [C]." Reasoning models consistently name and enumerate options; GPT-4 often frames trade-offs without naming them as discrete alternatives.
• Rejection with stated reason: "I would not recommend [B] because [specific reason]." Reasoning models explicitly reject non-chosen options with reasons; GPT-4 typically describes trade-offs without explicit rejection statements.
• Structured deliberation headers: Responses often use headers like "Trade-offs", "Considerations", "Recommendation" in architecture conversations — o1/o3 responses are more likely to structure their reasoning visibly.
• Response length: Architecture analysis responses from o1/o3 tend to be 800–2500 words. The same question to GPT-4 typically produces 300–800 words.

These heuristics are not definitive — GPT-4 with a well-crafted system prompt can produce similar output. But for bulk identification across an export with thousands of conversations, they prioritize the high-signal conversations for manual review.

Why the missing reasoning chain matters less than it sounds

The reasoning chain omission sounds catastrophic for decision extraction. In practice, it is less severe than for Grok or other platforms with no export at all, because o1/o3 models compensate in their final responses.

Reasoning models make their deliberation visible in the final response

Unlike GPT-4, which frequently reaches a conclusion without showing the elimination process, o1/o3 models are trained to produce final responses that document the consideration path. This is partly a product of the reasoning training — a model that has explicitly deliberated over alternatives is more likely to reference those alternatives in its final response. For architecture sessions, this means the final response typically includes:

• Named options that were considered (not just the chosen option)
• Explicit rejection reasons for non-chosen options ("MongoDB was rejected because the payment audit trail requires ACID guarantees")
• Stated trade-offs for the chosen option (both positive and negative consequences)
• Explicit caveats and conditions ("this recommendation changes if you need >100K TPS")

This is exactly the content that architecture decision records require — the Considered Options section, the rejection reasons, and the honest downsides. It is in the final response, not the reasoning chain. And it is in conversations.json.

The reasoning chain would have been redundant for decision extraction

The reasoning chain is the internal scratchpad — it includes backtracking, discarded paths, and exploratory thinking that did not survive to the final response. For decision record extraction, this is noise. The final response is the model's curated conclusion: the alternatives it considered seriously enough to name, the rejection reasons it found strong enough to state, and the trade-offs it believed were worth documenting. This is a better input for structured decision extraction than the raw reasoning tokens would be.

Export characteristics by model — comparison table

The export process — identical to standard ChatGPT

Exporting o1/o3 conversations uses the same path as any ChatGPT export — there is no separate export for reasoning model conversations:

1. Open ChatGPT (web UI or app) and navigate to Settings.
2. Go to Data controls (or Privacy and data in some UI versions).
3. Click Export data. Confirm the export request.
4. Wait for the email from OpenAI (typically minutes to hours depending on data volume).
5. Download the ZIP file from the email link. The link expires after a few days.
6. Unzip the file. The conversations.json file contains all conversation history, including o1/o3 sessions, in a single flat array.

The resulting conversations.json file contains every conversation regardless of which model generated the responses. o1/o3 responses and GPT-4 responses are in the same file, same format, same schema. No separate export is needed or available for reasoning model sessions.

Data retention

OpenAI retains ChatGPT conversation history subject to account data deletion and the standard ChatGPT data retention policy. Reasoning model conversations are retained on the same schedule as non-reasoning conversations. If you use the temporary chat feature in ChatGPT, those conversations — regardless of model — are not retained in the export.

GDPR and data subject rights

The standard ChatGPT data export (Settings → Data controls → Export data) satisfies GDPR Article 20 (data portability) for EU users. Reasoning model conversations are included in the export under the same data portability right. There is no separate GDPR path for o1/o3 data — it is part of the same ChatGPT account data.

Practical guidance for engineers using o1/o3 for architecture work

Treat o1/o3 architecture sessions as priority extraction targets

If you use o1, o3, or o4-mini for architecture deliberation — database selection, infrastructure design, API trade-off analysis, security model evaluation — these sessions are the highest-priority candidates for decision record extraction. The final responses contain more explicit alternatives, more stated rejection reasons, and more structured trade-off analysis than comparable GPT-4 sessions. The WhyChose extractor surfaces these sessions and structures their content as ADR-shaped records.

Prompt o1/o3 to show the elimination process

While the reasoning chain itself is not in the export, you can increase the explicit deliberation content in the final response by prompting the model to show its work: "Evaluate the trade-offs between [A], [B], and [C] for this use case. For each option you don't recommend, state the specific reason it was rejected." o1/o3 models respond to this prompt structure by making the rejection reasons explicit in the final response — which is where they will appear in the export.

Export promptly after significant sessions

The practical risk with reasoning model sessions is the same as any ChatGPT session: if you delete the conversation, use temporary chat, or lose account access, the session is unrecoverable. The reasoning chain being absent is less important than the final response being preserved. Export your ChatGPT data on a regular cadence — monthly is a practical minimum for engineers who use ChatGPT for architecture work.

If you need the full reasoning chain: use the API

For cases where the reasoning chain itself is needed — compliance documentation, audit trails, research — the correct approach is to use the OpenAI API (api.openai.com) rather than the ChatGPT web UI. The API for o1/o3 exposes reasoning token metadata and, in some model versions, reasoning summaries via the response object. This data is available at inference time in the API response and must be captured at that moment — it cannot be retrieved retroactively. API conversations are stateless (no server-side history), so the API-based workflow requires your own conversation persistence layer.

WhyChose and o1/o3 architecture sessions

The WhyChose extractor processes conversations.json exports and surfaces the sessions where architecture alternatives were evaluated. For o1/o3 conversations, the extractor performs particularly well because the final responses contain explicit alternatives enumeration and stated rejection reasons — the content that maps directly to the ADR Considered Options section and the rejection rationale for non-chosen options.

The extraction workflow for o1/o3 sessions: export ChatGPT conversations → run the WhyChose extractor → filter results to o1/o3 model sessions (using the model_slug field or the content heuristics described above) → use the extracted output to populate the Considered Options and Decision Outcome sections of an architecture decision record. The extractor identifies decision-rich sessions and structures their content — so an o1/o3 session on database selection produces a structured record with the named options, the rejection reasons for PostgreSQL vs CockroachDB vs DynamoDB, and the stated rationale for the chosen option. Copy that into the ADR before opening the review PR.