Research preview

Over 40× fewer tokens: Markdown in SQLite

Richard Ng

Tokens per fully correct answer

Cached input
Uncached input
Reasoning
Output

TL;DR:

Agents do better with SQLite: 97% fewer failed trials for a fixed 1M input-token budget
Token spend gets slashed: 40× fewer tokens, ~20× lower modelled token bills per fully correct answer
It's faster, not slower: median answers in 1/6 of the time versus Markdown-based grep

Jump to the graphs to see the results, or read on for background and motivation.

Introduction

Open-sourcing our context efficiency research

We're preparing to open-source our data, research and setup wizard for a context engineering architecture that can make your Markdown vault 40× more token-efficient on workloads like the one tested here.

With our one-line setup wizard, you'll be able to:

Get more from your AI agents. Make your AI budget go further with token-efficient context.
Verify our research for yourself. Run benchmarks on your own data and on your own machine.
Discover new Markdown superpowers. Build realtime collaboration and apps on fast, efficient Markdown.

In this post, we share evaluation results and explain the architecture.

Background

Context sovereignty and human agency

Native is a research lab building for a civilisation of many authors. Our focus is infrastructure and products for distributed ambition, agency and abundance.

Our first mission is context sovereignty: making context ownership easy, powerful and delightful for people, companies and communities, so it can be a non-principled default.

Our research preview brings together more token-efficient retrieval, realtime collaboration and a path to keeping your working context outside SaaS walled gardens.

But first: why context sovereignty, and why Markdown vaults?

Context is an ownable asset in the age of AI

Your company's value compounds in your context

We believe context sovereignty is a critical investment for humans and companies.

Context is the key complement to the technology of AI. Intelligence is general, and context is specific. We believe that humanity's good lies in the blend of the two.
Context can be sold as training data. The growth of Mercor, Scale and Surge AI shows the commercial demand for specialised human context.
Context is an enduring, defensible asset if it is owned. AI is commoditising vast professional expertise. But, if you own your context, its value compounds.
Context creation is rapidly accelerated by AI. AI agents explore, learn and output a huge amount. That is all new context, and reading it is becoming a full-time job.
Context ownership helps you respond to geopolitical risk. AI is a rapidly moving technology, with unpredictable changes in access.
Context becomes a bottleneck as intelligence gets cheaper. Epoch AI’s research tracks the falling price of intelligence; context remains specific to the people and organisations that create it.

AI labs are especially dangerous context owners

There are some places where it's especially dangerous for your context to accrue -- and we think that AI labs are top of the list.

If an AI lab owns your context, they have the power to dictate how it's used.
This means that they can make themselves a monopoly provider of your intelligence.
So, now the AI lab owns your context and is your monopoly provider of intelligence.
If value is intelligence plus context, and you rent access to both from the labs...
... yikes?

Not all 'ownership' delivers sovereignty

We think it's clear that your context needs to be independent of the AI labs. But we think there's also a very strong case for it being independent of most digital providers.

A company which hosts your context will probably claim that you own the data. But digital 'ownership' often turns out to be a surprisingly revocable and weak access license.

Here's some questions to explore around context sovereignty.

Can I access it whilst I'm offline?
Can I easily use it with any AI agent that I want?
What happens if an AI lab buys this company?

This deep level of context ownership is what we mean by context sovereignty.

Resisting the context gravity of AI labs

Context -- especially team context -- has something akin to gravitational pull: the larger a store of context, the more likely it is to attract further context.

Context gravity

Let's illustrate this with an example. When you're discussing a proposal with your team, there's lots of plausible places to put it: a Google Doc comment, a Slack channel or even old-fashioned email.

So, where do you pick? In most cases, it's "wherever the team normally does this".

This is context gravity: new context is more likely to be 'attracted' to places where relevant context already exists, for at least a few reasons:

You're more likely to already be there when you create new context, since relevant context is collected there
It's more useful to your audience to store context there, since they 'know where to find it' and can view it next to other relevant background
It's simply 'conforming to social norms' to store the context where everybody else is storing it

Centralising forces

Today, the AI labs are making a big play for your context.

Products like ChatGPT Space and Claude Artifacts are surfaces that also conveniently centralise your working context inside the model lab's ecosystem.

Normally, the logic of context gravity would dampen these surfaces. However, there's some key things which are different now.

AI agents can generate work and output at truly inhuman rates. The written context you generate from a month of AI agents can be larger than years of your Slack conversations.
Frontier labs can influence AI agents towards these new surface areas. OpenAI and Anthropic have the power to prime ChatGPT and Claude towards their centralising surfaces.
New surfaces can be more effective for AI agent productivity. Prominent AI commentators have swung behind the idea of new agent-native workspaces.

This gives the AI labs a powerful context gravity flywheel.

Your agents use their surfaces, whether through merit or biased priming;
It becomes more convenient for you to use those surfaces to work with your agents;
The surfaces accumulate context gravity that pulls in more and more context;
All your context ends up centralised and in control of the AI labs.

Making context sovereignty a non-principled default

For context sovereignty to win, we believe it needs to be the non-principled default.

In other words, we believe that the most easy, powerful and delightful products should be ones that just so happen to deliver context sovereignty -- at least from a mainstream user perspective.

Why? It's because of what we call the 'Should-Do Gap'.

A 'Should' is something that a well-informed expert would strongly urge you to do.

For example, these could all be Shoulds:

"I should floss" (as most dentists would say)
"I should set aside more savings" (as most financial experts would say)
"I should use better passwords" (as most cybersecurity experts would say)

Here's the key thing: we might know that we should, and we might still not do.

Our goal isn't "people and communities know that they should have context sovereignty".

Our goal is "people and communities have context sovereignty".

We need to design for adoption.

We see this as a two stage mission:

Make context sovereignty better -- more easy, powerful and delightful than it currently is
Make context sovereignty the best -- more easy, powerful and delightful than any alternative

That's what takes us to Markdown.

Building up from Markdown

What makes Markdown great

Folders of Markdown -- often called 'vaults' or 'brains' -- have seen a renaissance in the age of AI, as a way to plug and connect AI to rich context.

We think that Markdown is a great starting point for context sovereignty, for many reasons.

It's agent-native. Markdown is the lingua franca of every major AI agent.
It's ownership-friendly. It's transparent, portable and human-readable.
It's an open technology. The file format spec is released under Creative Commons.
It's free from rate limits. You, or your AI agents, can make high velocity changes to it.
There's an ecosystem: GitHub, Obsidian and many apps support Markdown.

A well-organised local Markdown vault achieves two complementary goals: connected context for AI agents, and context sovereignty for humans and teams.

So, our starter question was this: what if all context could sit in that vault?

To do that, we need to reflect a bit on "What is context?".

Different types of context and how teams work

In a knowledge work setting, we see at least three tiers:

Work. The raw 'output' that you create: a document, some slides or a spreadsheet. (As context: "What's the provisional conclusion of our BlueCorp analysis?")
Work about work. Where you track your work: e.g. project and task management. (As context: "What's currently blocked by our BlueCorp analysis work?")
Work about 'work about work'. Where you decide what to work on: e.g. team messaging and meetings. (As context: "Why did we change our mind about Green Inc being a design partner?")

It's very rare for teams to capture all of these in their Markdown vault. Often, these sit in SaaS apps, like Linear, Slack and Attio, for a few reasons:

There's a nicer human UX than Markdown editors. These products are often well-designed, and feel better for humans than editing raw Markdown.
They unlock collaborative work better than Markdown. Your changes are shared without remembering any active sync or data push/pull steps.
They need structured data, not just text. These products often use Markdown content, but need typed, filterable fields to work effectively.

Walled gardens and rate limits

The UX, team collaboration and structured data benefits to SaaS apps correspond, somewhat crudely, to three layers: a frontend UI, a backend server, and a database.

SaaS apps provide a convenient wrapper and packaging for that bundle. But your context is no longer connected or sovereign -- it's fragmented into databases that you don't own or control.

As a tangible example: your context can be put behind a rate limit restriction which these companies can change at any time.

Lots of these SaaS companies have built great products and much better UI/UX experiences than what they replaced.

But what if we could have their ease, power and UX whilst also having the connectedness and sovereignty of a local Markdown vault?

Native: superpowers for connected, sovereign context

We're opening a research preview for Native across web, MCP and CLI.

We've built Native to give superpowers to connected, sovereign context.

100%ownership of your context
The best bits of Markdown.
You own your context. It's transparent, portable and readable. You can keep it on your file system, view it in Obsidian and back it up in GitHub.
40×fewer tokens than a Markdown wiki
Retrieval superpowers for AI.
Get answers 6× faster, with 30× fewer failed trials at a 1M input-token budget and 40× fewer tokens per fully correct answer, when agents use Native instead of an ordinary Markdown wiki.
SQLone shared context database
More freedom for you and your team.
Share context in realtime, remix any app you want and unify your workspace around a connected, sovereign database.

Under the hood, the key technical architecture is this:

An append-only event log is the source of truth. It means that everything is auditable, traceable and restorable. This is one of our key architectural bets for the age of agents.
The event log projects into SQLite and/or a Markdown vault. They are two representations of the same stateful context. SQLite is richer, and Markdown is lossier, but you can still have all the Markdown files on your local machine.
Agents are expected to query via MCP, but they can always read the local Markdown or go direct to the SQLite database.
You can run this locally or in a cloud. A shared cloud database supports team context and sharing. You can self-host it in a cloud of your choice, or use ours.

We are preparing to open-source everything that you need to run Native locally, reproduce our benchmark results and run your own private evaluations.

Below, we include some highlights from our research and benchmark results.

Dataset

Our findings are grounded in real-world context

We take our own event log as the base dataset for our research.

It covers two months, from mid-August to mid-October. (Mid-August is when we switched over to a ground-up rewrite of Native.)
It's mostly two humans and a few thousand agents over this time period. One of the humans is part-time over this time period.
It contains ~77,000 events, such as record.create, record.update, link.create and more.
It projects into ~11,000 individual records, i.e. SQLite rows or Markdown files. It's ~120MB of Markdown content in total.
It's cross-functional context. Records represent everything from CRM-like tracking, product backlog tickets and internal messaging.

The underlying event log can be projected into different forms.

We wanted to test the efficacy of different representations. So, we projected the event log into four setups.

Native's SQLite MCPLocal MCP
A local SQLite database exposed through MCP. Agents write SQL over a discoverable schema, with some convenience tools.
Native-to-MarkdownFilesystem
Nested folders of Markdown files, with strongly typed frontmatter and a JSON index file.
Markdown + wikilinksFilesystem
Nested folders of Markdown files, with wikilink pointers. Similar to a common Obsidian vault.
Plain MarkdownFilesystem
Nested folders of Markdown files, with mentions of other files by title rather than wikilink pointer.

Why we put MCP in front of SQLite

MCP is a priority surface area for us because it means we can support a wide variety of agent harnesses and machine setups.

In retrospect, it would have been interesting to test a direct SQLite setup as well. This honestly did not occur to us until we were writing this blog post.

Further setup details

These setups are identical on body content and structure wherever it fits the paradigm.
We make a best-effort to represent lossy setups in a fair, reasonable way. For example, plain Markdown substitutes titles for wikilink mentions.
- Unfortunately, this setup flatters plain Markdown relative to wikilinks, since we guarantee that the title is the correct, up-to-date title at the point of substitution.
You can see full details of Native's SQLite MCP and the Native-to-Markdown projection in our GitHub repo.

Trial design

We assess on realistic, everyday work queries

We wanted to test how effective and efficient each representation was for agentic context retrieval and question answering.

To do this, we generated 40 questions, that were all answerable with perfect knowledge and/or recall of the represented company context.

We then tested each setup on the 40 questions, with three independent runs for a total of 120 trials per setup.

Each setup used OpenCode as the harness and DeepSeek v4.1 Flash on High effort for the model.

Native's SQLite MCP
Native-to-Markdown
Markdown + wikilinks
Plain Markdown

20× cheaper for agents to get context

Cached input
Uncached input
Reasoning
Output

As teams lean more into AI agents, token spend can get out of hand.

Per fully correct answer, including tokens spent on failed and partially correct attempts, our data suggests 40× fewer tokens and a modelled 10–30× cost reduction when agents use Native instead of normal Markdown + wikilink vaults.

That's a big saving, but it might be confusing: why are those two numbers not identical?

It's because 40× is the total token reduction and not all tokens are priced equally.

Native's token efficiencies are ~50× for cached input, ~7× for uncached input and ~12× for reasoning + output.

As an overall blend, depending on the cache discount and output premium, that is around 10-30× cheaper.

Further explanation on token and pricing types

This is a simplified recap for readers less familiar with AI agent mechanics and token pricing.

Input vs output tokens

Broadly, we can distinguish between two types of tokens:

Input: tokens read by the model as context for it to generate output
Output: tokens used by the model to reason or take action

These are priced differently. Output tokens are more expensive, commonly by a factor of 3-8×. However, even input tokens aren't identically priced -- and to understand this, we need to understand how agents work.

Why input gets repeatedly reused

LLMs are 'stateless': they have no memory. For the models to generate coherent responses in a conversation or long-running session, we need to give them context: "Here's everything from the conversation and session, so you can see what's happened so far".

An AI agent is a 'harness' that includes some mechanism for storing "everything so far", before sending it to an underlying LLM. The LLM generates the next response or action. The harness adds that to "everything so far", and runs a loop.

So, every time the LLM generates a response, three things are used as input tokens:

Everything that was given as input tokens in the last loop cycle (assuming no compaction)
The output (agent reasoning, response and action) generated by the last loop cycle
Any new user response or environment feedback received after the last loop cycle

This has several implications.

As the session goes on, input tokens vastly outnumber output tokens. "Everything that has happened so far" is much bigger than "Here's what I'm doing next."
Input tokens are reused as input repeatedly. For example, your user input from turn 4 is sent as input ("Everything so far") in turn 5, 6, 7 and more...

Cached input reads

If I paid full input token price through every loop cycle, this could get pretty expensive and painful. I'd pay for the same context repeatedly: if we loop through 90 cycles, I would pay 90× costs for cycle 1's user input, 89× costs for cycle 2's user input, and so on.

Luckily, many intelligence providers provide a 'cache' mechanism and discount to make this cheaper.

In effect, they store (or cache) the LLM results from processing your input
This is cheaper for them to build upon instead of getting the LLM to process the input from-scratch again.
This shows up in our pricing: 'cached input' is cheaper than 'uncached input'. (This varies from a ~75% discount to as high as 98%.)

So, your cache input token use (or 'cache reads' for short) depends on two things:

What's the volume of your input tokens? More input tokens means that you have more that you read from the cache on each loop cycle.
How many loop cycles does your session run for? More cycles means the cache is read for the same input a larger number of times.

Fewer tokens and fewer loop cycles

Native is more token-efficient than Markdown + wikilinks. But the magnitude of change is different:

It's 'merely' 7× more efficient for uncached input
It's a much larger ~50× for cached input.

Why is this?

It's because Native's gains are on two axes.

Native reduces unnecessary input context. Agents use SQL for structured filters and multi-hop retrieval in a single query, without intermediate results entering agent context.
Native reduces the number of agent loop cycles needed. Agents get to the answers they need in a shorter number of queries, meaning they need fewer loop cycles to complete their work.

So, here's an approximate intuition how we get to ~50× cached input savings. Firstly, we save ~7× on the size of cached input, because we give agents more efficient context; then, because agents need fewer loops, we save a further ~7× on how frequently our cached input needs to be referenced.

What this means for your token bills

Then, here's how that affects your overall token savings and bill:

Since not all tokens are cached input tokens, the overall token reduction is ~40× across cached input, uncached input and output (including reasoning) tokens.
Since not all tokens are priced equally, the overall cost saving is ~10-30× depending on your provider's cache discount and output token premium.

Our bar chart above gives you a way to explore this in a few different ways.

Toggle between a cost-weighted view and a raw token view to see the difference between token reduction and cost savings
Select which token types you want to include or exclude to see how different token types are affected
Move the sliders on cache discount and output token premium to see how this affects the cost saving

Speculative thoughts on future savings

As agents move into greater use, there's a trend towards provider cache discount increasing.

At the same time, deeper use of agents generally means longer-running sessions, in which the same cache is re-read repeatedly.

We predict that, by the Jevons paradox, the second of these will end up dominating the first: cache reads might get cheaper, and then we'll just end up using them far more.

Therefore, our provisional prediction is that savings with Native will increase over time as the length of agent sessions drives token cost more than cache discounts.

Cut noise by 3×, get better agent signal

We believe that signal-to-noise should be a key target of context infrastructure. How can you give your agents the key context they need with as few tokens as possible?

Our results are consistent with signal-to-noise being important, and suggest that a strong data schema can help.

We notice a strong association between two factors:

Trials where the Markdown + wikilinks agent uses over 128k of its context window; and
Trials where the Markdown + wikilinks agent fails to answer correctly.

This could be explained by context rot, but we think signal-to-noise ratio is a better explanation.

How we give agents better signal-to-noise

Native's event log is strongly typed, which means agents have guarantees on how they can search and filter.

With Native's SQLite MCP, agents straightforwardly use SQL queries to filter out irrelevant context.
With Native-to-Markdown, we find that agents proactively use Python scripts to achieve the same effect, without central guidance or steer.
With Markdown + wikilinks, the agent lacks the same typed fields and relationships to filter on, and spends more time searching through irrelevant files.

As such, the Markdown + wikilinks agent ends up using 2-3x the context window of both the Native MCP and Native-to-Markdown agents.

(Native's SQLite MCP is shown to be the most efficient way to do this, but many of Native's gains are preserved in the Native-to-Markdown projection.)

Frontier efficiency for both time and tokens

In complex context retrieval, teams make accuracy and latency trade-offs. Ideally, we want fast and accurate answers, with as few tokens as possible.

On this question set, Native's SQLite MCP offers a better accuracy–budget trade-off across much of the measured time and token range. This compares the tested setups; it does not establish a universal advantage for every vault or budget.

The intuition is pretty simple:

For small scale, e.g. the 100's of files, Markdown is great for simplicity, portability and readability. If you don't use AI agents much, you probably never need anything else.
At the scale of 11,000 files -- which is only two months of context for a two-person team deeply leveraging AI agents -- Markdown is highly inefficient for retrieval.
SQL is a battle-tested technology for rapidly searching this volume of data, e.g. through indexed queries.

So what?

Context and a workspace that's yours

The graphs in this post are about Native as a performant context vault. It saves you money, tokens and time.

But that's not what we're really excited about.

In our view, the magic of Native is that it makes your context yours -- not just yours to own, but yours to mould.

Let's return to the idea of context gravity. If my team uses Google Docs, then even if I love Notion, I have to use Google Docs.

What if we could collaborate together across those interfaces? What if I was editing in Notion, and your Google Doc showed my changes in realtime?

With Native, you can have any UI that you want -- your agents can author it for you! Your docs, projects and messaging can all write to the same underlying source of truth -- a connected, sovereign database -- with your own bespoke theming or remixing.

Collaboration doesn't need to mean conformity. Individuality doesn't need to mean isolation.

This is our bigger picture at Native. We describe our north star as "a civilisation of many authors". It's a future of sovereign individuals, shared freedoms, voluntary association and creative collaboration.

Our research preview is just a small step towards that future. There is much more to come, and we're excited to mould it together with the community.

To get research preview access, join our waitlist.
To support our work, star our GitHub repo.