`ai-data-extractor` is a free, open-source tool that reads local storage from Cursor and Claude Code and exports your full conversation history as structured JSON. Most developers have hundreds of high-signal prompts sitting on their hard drives, unindexed and unreachable. This tool surfaces them. Whether it changes your workflow depends entirely on what you build with the data after extraction.
Most people waste 80% of their AI potential. Not because the models are bad — because the prompts disappear.
You spend 20 minutes crafting a prompt that finally gets Cursor to refactor a messy service layer correctly. It works. You close the tab. Six weeks later you need the same pattern. You start from scratch. That cycle is the actual productivity leak, and it has nothing to do with model capability.
`kruzovic7/ai-data-extractor` exists to stop that loop.
The tool reads the files that Cursor and Claude Code write locally during every session. It touches no API. It sends nothing anywhere. It reads what is already on your machine, parses the structure, and outputs usable JSON.
For Cursor, the target is the SQLite database the editor maintains in your system's user data directory. For Claude Code, it is the JSONL session files stored under `~/.claude/projects/`. Both formats are undocumented in the apps themselves — this project does the reverse-engineering work so you do not have to.
A raw conversation log from either tool is richer than it looks. Each entry includes:
That is not just a chat log. That is a labeled dataset of prompt-to-response pairs, grounded in specific code context. If you have been using Cursor or Claude Code for six months, you have a non-trivial corpus on your machine right now.
Cursor crossed one million users faster than most developer tools in recent memory. Claude Code, Anthropic's terminal-native assistant, has become a standard tool for the developer segment that needs deep multi-file reasoning rather than IDE autocomplete. Both tools generate dense local conversation data every single session.
What has been missing is any infrastructure to work with that data after the session ends.
`ai-data-extractor` is the first widely distributed open-source project that addresses this gap across both tools under a single interface. That matters because a significant slice of power users run both: Cursor for IDE-integrated work, Claude Code for complex tasks that require sustained context across a codebase.
There is a broader signal here. As competitive pressure between AI coding models intensifies — with new entrants narrowing the gap on raw capability — differentiation increasingly falls on workflow architecture, not model quality. The developers who win are the ones building feedback loops. Extraction is step one of any serious feedback loop.
This is the 80% use case. Extract your history, filter for sessions where the response resolved the task in one or two turns, and pull the user messages. Those are your templates.
Structure each one like this:
``` TASK: [what you were trying to accomplish] TOOL: [Cursor / Claude Code / model version if known] CONTEXT: [language, framework, file type, constraint] PROMPT: [exact prompt text] RESULT: [one sentence on what it produced] REUSE TRIGGER: [the situation where you'd reach for this again] ```
Store them in Obsidian, a plain text file, or a private Notion page. The format matters less than the habit. After 30 extracted sessions, you have a prompt library that represents months of real-world validation — you just were not keeping score.
Tested 200 prompts. Only 12 consistently beat GPT-4 defaults. The difference is almost always specificity, not length.
If you are building a specialized coding assistant — for internal frameworks, codebase conventions, or a niche domain — your Cursor and Claude Code history is the cleanest training signal available. It is already in a prompt-completion format.
The standard structure for fine-tuning, which most providers accept:
```json { "messages": [ {"role": "user", "content": "[extracted user prompt]"}, {"role": "assistant", "content": "[extracted assistant response]"} ] } ```
Run a quality pass before using any of this. Filter out sessions where you re-prompted more than twice on the same task. High re-prompt count means the initial prompt failed — that is low-signal by definition. Keep sessions that resolved cleanly.
This use case is underutilized and not obvious until you think about it.
Embed extracted conversations using any standard embedding model — OpenAI's `text-embedding-3-small`, Voyage, or Cohere are all reasonable starting points — and drop them into a local vector store like Chroma, Qdrant, or LanceDB. Then query it:
*"Show me every session where I asked about database migration patterns and the response was accepted."*
You are not asking an LLM to generate an answer. You are retrieving a proven answer you already validated, from a real task you completed. That is a fundamentally different quality floor. The model cannot hallucinate something you already verified in production.
Useful if you manage a development team using coding assistants and want to understand where the leverage actually is. Which task types generate the longest back-and-forth — indicating high complexity worth documenting? Which prompts resolve in one shot — indicating strong candidates for standardized templates?
This requires additional scripting on top of the extracted JSON, but the structure supports it. The timestamps and session identifiers are there. You can build basic utilization metrics without much effort.
Before you run the extractor against your local data:
Don't run this on a shared machine. Extracted files contain every prompt you sent, including auto-injected file context. On a shared developer machine, that data is accessible to anyone with filesystem access. Local extraction does not mean access-controlled extraction.
Don't pipe the raw output directly to a cloud LLM. Extracted conversations can contain sensitive file paths, internal hostnames, database schemas, and credentials that ended up in code context during sessions. Sending that payload to a cloud API is a security event, not a productivity move. Review first.
Don't treat it as a substitute for intentional logging. Extraction is archaeological — you are recovering what already happened. If you want to build a real prompt engineering practice, the right move is logging at the moment of use: what worked, why, what context was required. Extraction gives you a starting corpus. It does not replace forward-looking documentation.
Don't include low-quality sessions in your prompt library without filtering. Conversations with heavy re-prompting, backtracking, and corrections are in the dataset. They are not useless — failure cases have signal — but they dilute a template library if included without a quality pass.
Local AI data infrastructure is becoming a real category. Right now, `ai-data-extractor` is a single-developer open-source project. Within 12 months, expect either a maintained fork with broader tool support or a commercial product doing the same thing with a graphical interface and built-in quality scoring. The underlying need is genuine and growing.
Multi-tool extraction is the obvious next step. The project currently supports Cursor and Claude Code. GitHub Copilot, Windsurf, Zed, and Cody all generate local conversation data in different formats. A unified extractor across all major coding assistants would be genuinely useful for the growing population of developers running two or three tools simultaneously for different task types.
Personal AI memory layers will consume this data. Several active projects — Mem0, MemGPT, and Anthropic's own memory research — are building persistent memory layers for AI assistants. Your extracted conversation history is exactly the kind of signal these systems need to personalize responses. The extraction step you take today may feed a memory layer that is in production use in 18 months.
Prompt quality scoring is the missing piece. Raw extraction gives you conversations. It does not tell you which ones were good. The logical next layer is an automated quality pass — using a smaller, fast LLM to score each extracted session on dimensions like: did the response resolve the task, how many follow-up turns were required, was the output used or discarded. That turns a raw dump into a ranked dataset worth building on.
Does the tool work on Windows, macOS, and Linux? The project documents support for all three platforms, with different default paths for where Cursor and Claude Code store local data. Verify the paths in the README against your actual installation. Non-standard Cursor installs in particular may store SQLite files in a different location than the documented default.
Is my data sent anywhere when I run the extractor? No. The tool reads local files and writes local output. Nothing is transmitted. If that changes in a future version or fork, the open-source license means you can audit the code before running it.
Can I use this to extract conversations from GitHub Copilot or other tools? Not currently. The tool is scoped to Cursor and Claude Code. Other tools use different local storage formats. The most direct path to expanding coverage is contributing support for additional tools to the repository.
What format is the output? JSON. Each extracted conversation is a structured object with message arrays, timestamps, and session metadata. You can process it with Python's `json` module, `jq`, Node.js, or any tooling your existing workflow already uses.
Will this break if Cursor or Claude Code updates their storage format? Possibly. Both tools can change their local storage schema in any app update. If extraction fails after an update, check the repository for open issues or a maintenance release. This is the primary ongoing maintenance burden for any tool that reverse-engineers local app storage formats — it is not a question of if a schema changes, but when.
What about privacy? Should I be concerned about what the extracted files contain? Yes, actively. The extracted data includes not just your prompts but full file contents that the AI tool injected as context during sessions. That can include source code, configuration files, and anything else that was open in your editor or referenced during the conversation. Treat the output files with the same access controls you would apply to your source code.
Is this useful if I just started using Cursor? Not yet. The value of extraction scales directly with history depth. Less than four weeks of usage will produce a corpus too thin to build a useful prompt library. Use the tools consistently for a month or two, then run the extraction. The archaeology is only worth the dig when there is enough buried to find.
Spending nearly $1,000/month on AI tools is no longer unusual for serious builders — the layering of Cursor, Claude Code, OpenAI API credits, and a handful of specialized tools gets there fast. The math increasingly...
Omnigent is an open-source meta-harness that sits above your existing AI coding agents — Claude Code, OpenAI Codex, Cursor — and routes your prompts to the right one based on task type and context. The efficiency...
BestAIFor