How to export every one of your Gnosem memories

The best argument that a memory service isn't a lock-in trap is a working export button. Gnosem's is at GET /export, available to every account regardless of tier. This post shows what it returns and why the shape is what it is.

The simplest way

From the dashboard, click "Download JSON export." A file named gnosem-export-YYYY-MM-DD.json downloads.

Via curl

curl -sH "Authorization: Bearer gn_your_key" \
  https://gnosem.dev/export > gnosem-export.json

The response is served with Content-Disposition: attachment, so a browser saves it directly rather than rendering.

What you get

The file is a single JSON object:

{
  "format": "gnosem/export/v1",
  "exported_at": 1785436412386,
  "user_id": "8b5c3c98-b906-4266-82aa-c37aadf88b3b",
  "plan": "pro",
  "counts": { "memories": 15, "includes_forgotten": false, "includes_superseded": false },
  "memories": [
    {
      "id": "0b3f1ee1-b673-418a-8c5f-1a4460f4429c",
      "content": "I prefer Postgres over MongoDB for greenfield work…",
      "content_optimized": "TOPIC=database | PREFERENCE=Postgres | REASON=greenfield_fit",
      "tags": ["preference","stack"],
      "written_by": "claude-code",
      "session_id": "01HXY...",
      "created_at": 1785372156851
    }
  ]
}

A few deliberate shape choices:

• Both content and content_optimized are present. The raw prose is what you wrote. The optimized form is the structured-facts compression Gnosem generates on write for token-efficient LLM ingestion. If you're migrating to another host, take the raw; the compressed form is a Gnosem-specific artifact.
• Tags are decoded to real JSON arrays. No "["preference","stack"]" string escaping to unwind on the other side.
• Provenance travels. written_by and session_id stay in the export, so you can rebuild the same audit trail elsewhere. If Claude wrote a fact and ChatGPT wrote a fact, the destination knows which is which.
• Timestamps are ms epoch. Sortable, comparable, unambiguous. No timezone parsing.

Getting your deleted rows too

By default the export excludes memories you've forgotten and memories that have been superseded (they still exist in D1 but are hidden from reads). If you're auditing your account or migrating a full history, opt in:

curl -sH "Authorization: Bearer gn_your_key" \
  "https://gnosem.dev/export?include_forgotten=1&include_superseded=1" \
  > gnosem-full-export.json

Rows in the extended export carry the extra fields forgotten_at and superseded_by so you can distinguish current from historical.

What to do with it

• Back it up. Cron this against your account nightly and drop the file in your cloud storage. Zero-effort disaster recovery.
• Migrate elsewhere. The format is self-describing — any receiving system can walk memories[] and map fields.
• Audit. Feed it into a script that filters by written_by to see which of your AI clients has been writing the most, or by tags to see what topics dominate.
• Build over it. The export is the same data memory_list would return over MCP, just in bulk. Anything you'd build against the live tools works against a dump.

Portability isn't a feature we advertise; it's a promise we've paid the engineering cost to keep. If you ever leave Gnosem, you leave with your data in a shape any receiving system can import. That's the whole reason gnosem exists — memory belongs to the user, not the vendor.