A Field Guide to Understanding Your Kilo Data Export

Kilo built a tool where you can download a subset of the data associated with your account. This field guide can help walk you through this data set.

This export can turn the last few months of scattered data into a clearer picture of what the last quarter has looked like. You can be your own forensic detective identifying what you need to improve as you head into the last quarter of the year strong.

You can also run a cybersecurity checkup on your own data using the open source tools covered in our guide. For example, if you or your organization ever needed to understand your data profile following a security incident, these open source tools can help identify where to focus first when remediating potential risk.

The export itself is straightforward to request. Making sense of what’s inside may require some help if you don’t have a data background, which is the purpose of this guide.

The export is a single compressed file containing your account details.

Since it’s a large data export, none of it is readable by just opening the file. It’s structured, but not human-structured, and this guide walks through how to unpack it, how it’s organized, and how to search through it for anything specific you want to find.

Requesting and unpacking the file

To request an export, open the Kilo Dashboard at app.kilo.ai, click the account settings menu in the bottom left corner, and select Request data exports. From there, click the Request export. Kilo will email you at the email address on file once it’s ready, which is usually a matter of minutes, and the email links to a single file named kilo-data-export.jsonl.gz.

The .gz extension means the file is compressed with gzip. On macOS or Linux, you can decompress it in place with:

gunzip -k kilo-data-export.jsonl.gz

The -k flag keeps the original compressed file around in case you want to reprocess it later. On Windows, 7-Zip will open it directly, or you can run tar -xf from a recent version of PowerShell. If you’d rather skip the decompression step entirely, most of the commands in this guide work just as well by streaming the compressed file through zcat (or gzcat on macOS), which is the approach used throughout.

Once decompressed, what you have is a .jsonl file, short for JSON Lines: a plain text file where every line is its own complete, independent JSON object. It’s a common format for large exports, since it lets you process a file line by line with ordinary Unix tools instead of loading the entire thing into memory at once. The tradeoff is that it isn’t very readable on its own, so you’ll want jq installed to make sense of it. If you don’t already have it, brew install jq on macOS, or your package manager’s equivalent elsewhere.

Reading the header

The first line of the file is a header describing the export itself, separate from any of your actual data. You can view it with:

gzip -dc kilo-data-export.jsonl.gz | head -1 | jq

Which returns something like this:

{

“type”: “header”,

“schemaVersion”: 1,

“exportId”: “010a8d7f-...”,

“requestedAt”: “2026-08-11T15:15:16.939Z”,

“generatedAt”: “2026-08-11T15:15:19.334Z”,

“includedSources”: [

“kilocode_users”,

“app_builder_projects”,

“microdollar_usage_metadata”,

“system_prompt_prefix”

],

“snapshotAt”: “2026-08-03T00:00:00.000Z”

}

Two fields are worth paying attention to here. includedSources lists which categories of data made it into this particular export, and snapshotAt marks the point in time the export was generated from.

How the data is structured

Every line after the header is a flat object with a source field telling you which category it belongs to, a field name, and a value. Some rows also carry an id, which groups multiple field/value pairs into a single record, like one CLI session having a title, a session ID, and a git branch as three separate lines that share the same id.

An account-level row looks like this:

{”source”: “kilocode_users”, “field”: “default_model”, “value”: “x-ai/grok-code-fast-1”}

A record-level row looks like this:

{”source”:”microdollar_usage_metadata”,”id”:”9e6f3aa6-120a-4047-8169-dafcfe566e2e”,”createdAt”:”2025-10-28T16:40:40.581Z”,”field”:”user_prompt_prefix”,”value”:”\ngive me a 2 sentence summary of this whole project\n\n\n# VSCode Vis”}

{”source”:”system_prompt_prefix”,”field”:”system_prompt_prefix”,”value”:”You are Kilo Code, a knowledgeable technical assistant focused on answering questions and providing “}

There’s no nested JSON to unwrap and nothing nested inside value. Every field you’ll query is right there at the top level, which keeps the jq recipes below fairly simple.

Before doing anything else, it’s worth getting a sense of what your export actually contains and how much of each type of data is in there:

gzcat kilo-data-export.jsonl.gz | jq -r ‘.source // “header”’ | sort | uniq -c | sort -rn

What each source contains

kilocode_users is your account record. It covers the basics you’d expect, like your signup date, default model, and credit totals, but it also carries more than that: your Google account email, name, and profile image if you signed up that way, any linked GitHub or LinkedIn URLs, your email domain, and a signup IP address. It’s worth a look on its own, since it’s the one source that’s entirely about you rather than about what you’ve done.

gzcat kilo-data-export.jsonl.gz | \

jq -r ‘select(.source == “kilocode_users”) | “\(.field): \(.value)”’

Spend is tracked here too, in microdollars_used and total_microdollars_acquired, both in microdollars, so divide by a million to get an actual dollar figure:

gzcat kilo-data-export.jsonl.gz | \

jq -r ‘select(.source == “kilocode_users” and .field == “microdollars_used”) | .value / 1000000’

microdollar_usage_metadata is one row per billed request, keyed by an id unique to that request. Because it’s tied to request-level billing rather than a single conversation, it captures prompts from every context Kilo bills for, including scheduled or automated tasks, not just what you typed in a session yourself. At roughly one row per request, this ends up being the largest and most varied source in the export.

gzcat kilo-data-export.jsonl.gz | \

jq -r ‘select(.source == “microdollar_usage_metadata”) | .value’ | head -20

system_prompt_prefix holds prefix text associated with system-level prompts on your account, truncated the same way. It’s a smaller source and mostly useful if you’re trying to confirm what a given model call was actually instructed to do.

Reviewing your data export

Once you have a full export in front of you, it’s worth taking a pass through it for anything sensitive that may have ended up in there without you noticing. The most likely place for that is microdollar_usage_metadata, since it’s built directly from prompt text and there’s a lot of it: a stray .env value typed into a task description, an API key pasted into a debugging prompt, a database connection string, an email address embedded in some automation context. None of this is unusual, and it’s not a sign that anything went wrong. It’s simply what tends to accumulate when a hundred-character window into your prompts gets recorded thousands of times over. Since your export is a faithful record of exactly that, it’s a reasonable place to check.

Start by pulling the fields you want to scan into one plain text file:

zcat kilo-data-export.jsonl.gz | \

jq -r ‘select(.source == “microdollar_usage_metadata” or .source == “system_prompt_prefix”) | .value’ \

> kilo-export-flat.txt

Open Source Tooling

Scanning a large body of text for sensitive strings is a well-established problem, and there are several solid open source tools built specifically for it. None of them catches everything on its own, since each one relies on a different detection approach, so the most thorough method is to run a few of them and then de-duplicate whatever they turn up. Here’s a rundown of the ones worth knowing.

Gitleaks (source, MIT license) is the quickest to get running. It’s designed primarily for git repositories, but it also supports scanning plain directories:

gitleaks detect --no-git --source . --report-path findings.json

Point it at the directory containing your flattened export, and it returns a JSON report of everything matching its built-in ruleset.

Trufflehog (source, website, AGPL-3.0 license) goes a step beyond pattern matching. For many types of findings, it will actually attempt to verify whether a discovered key is still active by making a live test call against the relevant service. That distinction matters a great deal for triage, since a finding that’s already inactive requires no further action, while a verified one does.

trufflehog filesystem ./kilo-export-flat.txt --results=verified,unknown

CredSweeper (source, docs, MIT license) was originally developed at Samsung. It layers a machine learning model on top of its regex-based rules specifically to cut down on false positives, which is useful given how repetitive and fragmentary short prompt snippets tend to be.

pip install credsweeper

credsweeper --path kilo-export-flat.txt --save-json report.json

Presidio (source, website, MIT license) was incubated at Microsoft and takes a different focus than the tools above: rather than keys and tokens, it’s built to find personal information, including names, email addresses, phone numbers, and physical addresses. Given that kilocode_users and microdollar_usage_metadata both routinely carry this kind of data, it’s a good fit for this export specifically. It’s a Python library rather than a standalone command line tool, but a basic scan takes only a handful of lines of code, and it’s also capable of anonymizing whatever it finds.

Bulk Extractor (source, GPL-3.0 license) comes out of the digital forensics field. Rather than parsing file structure, it scans raw bytes directly for emails, URLs, and other patterns, which lets it catch things sitting in places that structure-aware tools sometimes miss. It’s more than most people will need for a routine check, but it’s the right choice if you want the most exhaustive sweep available.

If you run more than one of these tools, you’ll likely see the same finding reported in slightly different formats. The simplest way to consolidate results is to normalize on the matched string itself across all the reports, then de-duplicate from there, which a short jq and sort -u pass handles well.

Letting Kilo do the reading for you

Given that Kilo is an agentic engineering platform, working through a large JSONL file by hand is exactly the kind of task it’s built to take off your plate. The one thing to avoid is asking it to analyze the export natively.Telling an agent to simply read the file directly will, for any export of meaningful size, blow through both the context window and a fair amount of credit in the process.

A better approach is a small custom skill that teaches Kilo to work through the export in fixed-size chunks, handing each chunk off to a subagent rather than holding the whole thing in the main session’s context. One approach that works well in practice is spawning a subagent for every thousand lines: each subagent reads only its own slice, returns a short summary of what it found, and the parent session aggregates those summaries without ever loading the raw data itself.

A skill along these lines might look like this:

---

name: export-analyzer

description: Analyze a Kilo data export (kilo-data-export.jsonl) without loading it all into context. Use when the user asks to explore, summarize, or audit their Kilo data export.

---

# Kilo Export Analyzer

## Rules

- NEVER read the export file directly into the main context. It can be

tens of thousands of lines.

- First, run `wc -l` on the file and read only line 1 (the header) to

learn which sources are present.

- Split the work: process the file in chunks of 1,000 lines. For each

chunk, spawn a subagent whose only job is to analyze that slice and

return a compact summary (counts, notable findings, flagged strings

with line numbers). Chunk with:

`sed -n ‘START,ENDp’ kilo-data-export.jsonl`

- Subagents report findings only, never raw chunk contents.

- Prefer shell one-liners (jq, grep, awk) over reading data as text.

Compute aggregates like spend and session counts entirely in shell.

## Standard tasks

- “Summarize my export”: per-source line counts, session titles, total

spend in dollars (microdollars / 1,000,000), date range covered.

- “Audit my export”: pull `value` from `microdollar_usage_metadata` and

`system_prompt_prefix` into a flat file, then scan it chunk by chunk

for high-entropy strings and known key patterns. Aggregate and

de-duplicate findings, then report each with enough context to

locate it.

- “Find X”: grep first to locate candidate line numbers, then send only

those regions to a subagent for interpretation.

With that in place, a prompt as simple as “audit my data export in ~/Downloads” runs the entire flatten, scan, and aggregate sequence on its own, and your context window comes out the other side intact.

What you end up with

Taken as a whole, an export like this is more useful than it looks at first glance. It’s a spend ledger or a record of how you actually think through problems, not just what code you shipped. History like this allows you to spot real patterns like which reps eat the most iteration or which prompts you keep rephrasing.

It’s also the fastest way to answer a question that’s otherwise unanswerable: what has actually ended up in your prompt history. Running the scan while nothing is wrong gives you a baseline, and the findings turn into a short list of concrete actions rather than a vague sense that something might be in there somewhere. If you’re the person responsible for bringing AI tooling into a team, that same flatten-and-scan pass is the evidence a security reviewer will ask for, and having it ready before anyone asks is a much better position than assembling it afterward.