What is gizmo_id in my ChatGPT conversations.json export?

The gizmo_id field in conversation metadata identifies which Custom GPT was used for that conversation. It appears in the per-conversation object alongside title and create_time. You can use it to group conversations by GPT using jq, producing a summary of which Custom GPTs you've used most. However, the standard data export does not include a GPT manifest file — there's no lookup table mapping gizmo_id values to GPT names in the ZIP. You must cross-reference manually against MyGPTs, or against the shared-gpts/ directory if you're on a Team plan.

Topic: chatgpt custom gpts export

How to Export Your ChatGPT Custom GPTs — What's Included and What's Not (2026)

There are two completely separate flows for "exporting Custom GPT data," and most guides conflate them. The first is exporting conversations you've had with Custom GPTs — this uses the standard ChatGPT data export and gives you transcript content plus a gizmo_id identifier, but never the GPT's system prompt or knowledge files. The second is exporting Custom GPT configurations you've built — this uses an entirely different path inside the GPT Builder, gives you the system prompt and action schemas, but omits knowledge file contents. Understanding which flow you need, what each contains, and what's permanently missing from both prevents the most expensive discovery: realising the gap after you've already deleted the GPT or switched accounts.

TL;DR

To export conversations you've had with Custom GPTs: use the standard data export (Settings → Data Controls → Export data); conversations.json will contain gizmo_id identifying which GPT was used, but the GPT's system prompt, knowledge files, and actions are never included. To export Custom GPT configurations you've built: go to MyGPTs → select GPT → Edit → ⋮ → Export; this gives you the system prompt and action schemas but not knowledge file contents — download those separately first. On Team plans: workspace-scoped GPTs appear in shared-gpts/ in the workspace export with full configuration including system prompt.

The two export flows, side by side

The confusion originates in OpenAI having two separate data models for Custom GPTs: the conversation (what happened when you used the GPT) and the configuration (what the GPT is — system prompt, knowledge, actions). These are distinct objects with different owners, different privacy rules, and different export paths.

	Flow 1: Conversations WITH GPTs	Flow 2: GPT Configurations you BUILT
What you get	Conversation transcripts with `gizmo_id` per-conversation metadata and per-turn tool call records	System prompt, instructions, model settings, knowledge file names (not contents), action schemas
Access path	Settings → Data Controls → Export data → download ZIP	MyGPTs → [GPT name] → Edit → ⋮ menu → Export
System prompt included?	No — OpenAI respects the GPT builder's privacy settings	Yes — if you built the GPT
Knowledge file contents?	No	No — file names only; download contents separately before deleting
Who can access?	Any user, for GPTs they've used	Only the GPT's builder (or workspace admin for shared GPTs)
GPT built by someone else?	Transcript available; configuration never available	Configuration not available to non-builder
Team plan variant	Workspace conversations in workspace export	Workspace-scoped GPTs in `shared-gpts/` in workspace export (full configuration)

Flow 1: What's in conversations.json for Custom GPT conversations

When you use a Custom GPT, the conversation is stored and exported via the standard data export identically to a regular ChatGPT conversation — with two additions to the per-conversation object.

The gizmo_id field

Each conversation that used a Custom GPT has a top-level gizmo_id field alongside title and create_time. The value is a string like "g-abc123def" — the GPT's stable identifier. This identifier is stable across GPT renames and version updates; it uniquely identifies the GPT for the life of the account. A conversation with a regular (non-GPT) model has gizmo_id: null.

// Per-conversation object in conversations.json
{
  "id": "abc-conversation-uuid",
  "title": "Architecture review session",
  "create_time": 1717012345.678,
  "gizmo_id": "g-Xf3k9Rp2m",     // ← Custom GPT identifier
  "mapping": { ... }               // conversation DAG
}

The model_slug field

Individual messages in the conversation tree carry a model_slug field in their metadata when the model used was a Custom GPT. The format is "gpt-4-gizmo-g-Xf3k9Rp2m" — the underlying model plus the GPT identifier. This is useful for two cases: inferring which underlying model version the GPT was running (the text before -gizmo-), and for cross-referencing against the conversation-level gizmo_id to confirm they match.

What is permanently absent

The system prompt, knowledge files, and action configurations of the Custom GPT are never present in conversations you've had with it — regardless of whether you built the GPT or whether it's a public GPT you found in the store. OpenAI enforces this as a privacy protection for GPT builders: a builder's system prompt is their intellectual property and competitive asset. Even after 500 conversations with a Custom GPT, you have transcripts of what the GPT said but no access to the instructions that shaped its behaviour. This is the correct behaviour from a platform perspective; it is surprising to most users who assume their own data export would include the full context of their conversations.

Per-turn tool calls are present in the conversation tree — you can see which tools fired and what arguments were passed — but tool call records don't reconstruct the action schema (which endpoint was configured, what authentication the action used, what the action's name was inside the GPT's configuration).

Flow 2: Exporting Custom GPT configurations you built

If you built the Custom GPT, you have access to its full configuration via the GPT Builder export path. This is a separate per-GPT operation, not part of the main data export.

The export path

Go to ChatGPT.com → Explore GPTs → My GPTs (or click your profile → My GPTs)
Find the GPT you want to export and click the pencil / Edit icon
In the GPT Builder, click the ⋮ (three-dot) menu in the top-right area
Select Export. A JSON file downloads immediately.

The export JSON is not the same format as conversations.json — it is a GPT definition object with the following top-level structure:

{
  "name": "Architecture Review GPT",
  "description": "Reviews PRs for architectural patterns and ADR gaps",
  "instructions": "You are a senior staff engineer...",  // ← system prompt
  "model": "gpt-4o",
  "tools": [
    { "type": "code_interpreter" },
    { "type": "retrieval" }
  ],
  "files": [
    { "name": "adr-standards.pdf", "size_bytes": 84201 }   // ← name only, no content
  ],
  "actions": [
    {
      "name": "fetch_pr_diff",
      "description": "Fetches the diff for a PR from GitHub",
      "url": "https://api.github.com/repos/{owner}/{repo}/pulls/{number}",
      "auth": { "type": "oauth" }                           // ← schema included
    }
  ]
}

What's included in the configuration export

System prompt (instructions field) — the full text you wrote in the Instructions box. This is the primary recovery target; losing the system prompt means rebuilding the GPT's behaviour from scratch.
Action schemas — full endpoint URLs, parameter schemas, and authentication type (OAuth / API key / None). Note that API key values are not exported even if stored in the builder — they're secrets and OpenAI does not include them in exports. You'll need to re-enter any API keys after a restore.
Model and tool settings — which underlying model (gpt-4o, gpt-4o-mini), which tools are enabled (code interpreter, file search, web browsing).
Knowledge file names and sizes — a manifest of uploaded files. File contents are not included. Download files first (see below).

Downloading knowledge file contents before export

Knowledge file contents are the one gap that matters most in practice. The configuration export gives you file names and sizes, which lets you verify the file manifest — but if you've deleted the source files elsewhere, you can't recover the bytes from the export JSON alone. The recovery path:

In the GPT Builder, go to the Knowledge section
Click each uploaded file to view it, then download via the browser's download button or the file's contextual menu
Save files to your local archive before running the configuration export

Do this before deleting the GPT, migrating accounts, or cancelling a Team plan. After any of those actions, the Files section is no longer accessible and the knowledge file contents are unrecoverable.

jq recipe: summarise Custom GPT usage from conversations.json

The following 22-line jq recipe processes conversations.json to produce a usage summary: how many conversations used each Custom GPT, when the most recent conversation was, and the GPT's identifier for cross-referencing. Run it after downloading your standard ChatGPT data export.

#!/usr/bin/env bash
# Usage: bash gpt-usage.sh conversations.json [optional: cutoff year e.g. 2026]
set -euo pipefail
FILE="${1:-conversations.json}"
YEAR="${2:-}"

jq --arg year "$YEAR" '
  # Filter to conversations that used a Custom GPT
  [ .[] | select(.gizmo_id != null) ]
  # Optionally filter by year
  | if $year != "" then
      [ .[] | select((.create_time | todate | .[0:4]) == $year) ]
    else . end
  # Group by gizmo_id
  | group_by(.gizmo_id)
  # Build per-GPT summary
  | map({
      gizmo_id:   .[0].gizmo_id,
      count:      length,
      last_used:  (max_by(.create_time).create_time | todate | .[0:10]),
      first_used: (min_by(.create_time).create_time | todate | .[0:10]),
      titles:     [.[].title] | unique | .[0:3]   # first 3 distinct titles as sample
  })
  | sort_by(.count) | reverse
' "$FILE"

The output is a JSON array sorted by usage frequency, descending. The titles field shows up to three sampled conversation titles per GPT — useful for manually cross-referencing the gizmo_id against your MyGPTs list when you don't have a manifest.

One known gap: the standard data export does not include a GPT manifest mapping gizmo_id values to GPT names. If you have many Custom GPTs or use GPTs built by others, the gizmo_id is the only identifier in the export. The Team workspace export's shared-gpts/ directory provides this lookup for workspace-scoped GPTs; for personal GPTs it remains a manual cross-reference against the MyGPTs page.

The OpenAI Assistants API backup route

If you created your Custom GPT via the OpenAI Assistants API rather than the GPT Builder UI, you have a programmatic backup path that the UI-only route doesn't provide:

# Retrieve a specific Assistant (Custom GPT) configuration
curl https://api.openai.com/v1/assistants/{assistant_id} \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "OpenAI-Beta: assistants=v2"

# List all Assistants in your account (max 100 per page)
curl "https://api.openai.com/v1/assistants?limit=100&order=desc" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "OpenAI-Beta: assistants=v2" | jq '[.data[] | {id, name, model, created_at: (.created_at | todate)}]'

The API response includes the full instructions (system prompt), tool configurations, and the file IDs of attached knowledge files. Critically: the API also lets you download knowledge file contents via the Files API (GET /v1/files/{file_id}/content), which the GPT Builder UI export does not provide in any form. If you manage Custom GPTs programmatically, build a nightly backup script that calls both endpoints and archives the results.

The Assistant ID and the GPT's gizmo_id in conversations.json are not the same identifier. The Assistants API uses a format like asst_xyz123; the GPT Builder UI's gizmo_id uses g-xyz123. There is no API call to convert between them — the mapping is maintained in OpenAI's internal system. If you need to correlate a GPT Builder GPT with its Assistants API representation, the most reliable method is matching by name and creation date.

Team workspace export: workspace-scoped Custom GPTs

On ChatGPT Team plans, Custom GPTs created via Workspace Settings → GPTs → Create are scoped to the workspace. These workspace-scoped GPTs appear in the Team workspace export's shared-gpts/ directory with their full configuration — including system prompt:

workspace-export.zip
├── workspace.json
├── members.json
├── audit-log.jsonl
├── shared-gpts/
│   ├── <gpt_id>.json      ← full configuration, system prompt included
│   └── ...
└── ...

This is the most convenient path for workspace administrators: one workspace export request archives all shared Custom GPT configurations alongside the conversation transcripts and audit log. Individual members still need to use the per-GPT Builder export for any personal Custom GPTs they built outside the workspace scope.

Three things workspace-scoped GPTs still don't export via this path: knowledge file contents (same as personal GPTs — names in the manifest, bytes require the Files API), per-GPT conversation analytics (which workspace members used this GPT and when — the audit log has gpt.shared events but not per-conversation usage), and the GPT Builder conversation history (the conversations you had while building and testing the GPT inside the Builder — these are in the personal account's standard export if enabled, not the workspace export).

Three things not exported anywhere

Across both export flows and the Assistants API, three items are not available through any standard export path:

Knowledge base file contents for UI-built GPTs. The GPT Builder export JSON contains file names and sizes; the UI has no bulk-download button for knowledge files. The only recovery path is downloading each file individually from the Knowledge section of the GPT Builder before the GPT is deleted. The Assistants API's Files endpoint does provide content download — but only if the GPT was created via the API, not the GPT Builder UI. If you're building Custom GPTs with significant knowledge files, maintain the source files in your own storage and treat the GPT's knowledge base as a derived artifact.
The system prompt of a Custom GPT you didn't build. A GPT built by another user or the OpenAI team — even one you've used extensively — never exposes its system prompt through any data export path. This is enforced at the platform level. The conversation transcripts are yours; the GPT's instructions are the builder's intellectual property. Tools that claim to "extract" or "reveal" system prompts from conversations work by prompting the model to repeat its instructions — which is a model behaviour (some models comply, some don't), not a data export feature.
GPT Builder session conversations. The conversations you had with the GPT while building and testing it inside the GPT Builder UI are stored, but they are not labelled as "GPT Builder sessions" in the standard data export. They appear as regular conversations in conversations.json with the relevant gizmo_id of the GPT being built. Filtering by gizmo_id and time-range (before the GPT's first published use) is the only way to isolate them.

How WhyChose fits in

The gizmo_id field in conversations.json is a first-class filter column in the WhyChose extractor. Every decision extracted from a Custom GPT conversation is tagged with the gizmo_id that produced it — which means "show me every architecture decision I made using the Architecture Review GPT" is a one-filter query on the extracted decision log, not a manual search through hundreds of conversations. If you built a Custom GPT specifically for architecture calls, vendor evaluations, or hiring decisions, the extracted log becomes a per-GPT decision journal that can be shared with the team via a private link.

Get early access