Here at DoltHub we tend to view everything through the lens of version control. We built Dolt, the world’s first version-controlled SQL database after all. Would this new tool be better with branches? Diffs? Merges? Clones? Inevitably, we see some opportunities.

Databases? Check.
Spreadsheets? Eventually.
Coding agents? Hmmm. I wonder…

With the rise of vibe coding and agents in general, we’re looking at context with a lustful, content-addressed eye. What if there was “Git for Context”? What would it look like? What features would developers love? This article won’t just answer those questions — it will answer them with a demo.

Context#

I’m sure most people already know this but let’s start with a quick definition of context. Context is the prompt and additional metadata that is sent to a large language model to produce a response. One of the key innovations with agents was the ability to iterate on a context/response action loop, combined with tool use to allow agents to do useful work like writing code. Agents generally have an append-only context with a compaction step when it gets too big.

For most agents, full context is hidden from the user, but you can dig into files in your .claude or .codex. It started as raw text files, but recently, most agents are discovering the need for structured data in context for more targeted retrieval, quality control, and concurrency management. So now you’ll see a lot of JSON format files and even, for the more cutting edge agents, SQLite files.

Open Code#

Enter Open Code, the most popular open source coding agent. An open source coding harness? Yes please.

Obviously, as an open source company ourselves, we love and support open source. One of the benefits of open source is that you can show, not tell. We saw Open Code migrated their persistence to SQLite and thought “How hard would it be to add version control for context using Dolt or DoltLite? It’s already SQL.”

Even the maintainers were goading us into it. This quote is ripped from one of their issues.

This is not very big or complex data.

Sounds like a perfect place to add version control.

Why Version Control Context?#

I wrote a whole article about agentic memory that makes a deeper case for version-controlled context: Git for Context.

But for Open Code in particular, we think Git for Context starts first and foremost as a development tool for Open Code contributors. What specifically happens to context after compaction? What if I compact 10 times on 10 different branches? How consistent is compaction? What if I manually strip out code comments from context on one branch and leave them on another? I’ll compare the context and code after 5 turns. Branches and diffs are powerful development tools for testing and comparing different strategies in the probabilistic environment agents live in. Could Git for Context make Open Code better, faster?

If Open Code contributors find Git for Context useful, maybe the most useful features could become user facing features? Having ten sub-agents work from the same context base on branches, comparing outputs, and merging good outcomes seems like a workflow that could work for some tasks. My only hesitation is the user experience. Adding version control to anything is a UX challenge.

But I think the most important user-facing feature would probably be context preservation. It seems weird to me already that we don’t push the context of our coding agents up to an immutable repository and link to it in our pull requests. Stored context is the agent stack trace. When something goes wrong, surely we will want humans or even other agents to dig through the context to figure out what happened. This can be closely linked to multiplayer mode. Pull an agent’s context locally and have an agentic engineering expert resume the session where it went off the rails as a teaching moment for other engineers. This is more GitHub for Context than Git for Context, but you can’t have one without the other.

Why Talk When You Can Show?#

We built it! You can check out version-controlled Open Code on GitHub, also free and open source.

Clone and Build our Open Code Fork#

First, you need to clone and build our Open Code fork. Before you get started, make sure you have bun installed. The example assumes you are running OSX with an ARM64 chip. If your architecture is different, the commands below will be similar but for your architecture.

cd ~/opencode-demo
git clone git@github.com:dolthub/opencode.git
cd opencode
bun install
cd opencode/packages/opencode
bun run build --single --skip-install --skip-embed-web-ui
mv dist/opencode-darwin-arm64/bin/opencode ~/bin/

Now, you have an opencode binary in ~/bin. If ~/bin is at the front f your PATH your PATH, you can just run opencode or you can run it directly with a full path.

But first, let’s create and start a Dolt server to house your version-controlled context. I would do this in a new shell so you can watch the query logs.

cd ~/opencode-demo
mkdir db
cd db
dolt init
dolt sql -q "CREATE USER 'dolt'@'%' IDENTIFIED BY 'pass1234';"
dolt sql -q "GRANT ALL PRIVILEGES ON *.* TO 'dolt'@'%';'"
dolt sql -q "CREATE DATABASE opencode;"
dolt sql-server -H127.0.0.1 --loglevel DEBUG

Try It#

Now, you’re ready to try version-controlled OpenCode.

OPENCODE_MYSQL_URL=mysql://dolt:pass1234@127.0.0.1:3306/opencode ~/bin/opencode ~/myproject/

Version-controlled Open Code exposes the following new version control commands. If you’re familiar with Git, these will look familiar.

/commit <message>

/log

/branch [-v]
/branch <name> <ref>
/branch <name> <[prompt_index]> -m <message>

/checkout <branch_name>
/checkout -b <branch_name>

/reset
/reset <ref>
/reset <[prompt_index]>

/context [--show]
/context <ref> [--show]

/diff-stat
/diff-stat <ref>
/diff-stat <ref1> <ref2>

/diff-context
/diff-context <ref>
/diff-context <ref1> <ref2>`

/history [-v]
/history <ref> [-v]

/sql <SQL STATEMENT>

Demo#

As many of you know, my pet project is DoltLite, a fork of SQLite with Dolt-inspired version control. I asked Open Code to clone a copy and give it a code review, making commits along the way. I’m just going to show the diff functionality today and come up with a more complex demo for another blog article.

ok. we're going to be working on doltlite. can you give it a code review for duplicate code?

There was a lot of output. But how did the context change? I can use /diff-stat for a raw view of what’s changed in my context.

[/diff-stat]
Diff stat HEAD → WORKING
message:
  rows:   3 → 35 (+32)
  added:    +32 rows, +160 cells
  deleted:  -0 rows, -0 cells
  modified: ~0 rows, ~0 cells
  data:   0 B → 13.5 KB (+13.5 KB)
    added rows:    +13.5 KB
    deleted rows:  -0 B
    modified rows: 0 B
part:
  rows:   9 → 142 (+133)
  added:    +133 rows, +798 cells
  deleted:  -0 rows, -0 cells
  modified: ~0 rows, ~0 cells
  data:   0 B → 248.5 KB (+248.5 KB)
    added rows:    +248.5 KB
    deleted rows:  -0 B
    modified rows: 0 B
todo:
  rows:   0 → 5 (+5)
  added:    +5 rows, +35 cells
  deleted:  -0 rows, -0 cells
  modified: ~0 rows, ~0 cells

Now, I’ll make another /commit and ask Open Code to fix the first item in the review.

After a few minutes, I’ll use /diff-context this time to see a more human readable diff.

[/diff-context]
Context diff HEAD → WORKING
Model:           opencode/big-pickle (unchanged)
Messages:        64 → 124 (+60)
  assistant    32 → 62 (+30)
  tool         29 → 58 (+29)
  user         3 → 4 (+1)
Tool calls:      41 → 75 (+34)
Total chars:     168023 → 275974 (+107951)
Approx tokens:   42006 → 68994 (+26988)
Changes by position:
  [0..63]  identical (64 msgs)
  [64]      added    user (+57 chars)
  [65]      added    assistant (+20832 chars)
  [66]      added    tool (+803 chars)
  [67]      added    assistant (+919 chars)
  [68]      added    tool (+3971 chars)
  [69]      added    assistant (+710 chars)
  [70]      added    tool (+1663 chars)
  [71]      added    assistant (+8361 chars)
  [72]      added    tool (+790 chars)
  [73]      added    assistant (+625 chars)
  [74]      added    tool (+4655 chars)
  [75]      added    assistant (+391 chars)
  [76]      added    tool (+1364 chars)
  [77]      added    assistant (+4381 chars)
  [78]      added    tool (+149 chars)
  [79]      added    assistant (+953 chars)
  [80]      added    tool (+805 chars)
  [81]      added    assistant (+306 chars)
  [82]      added    tool (+9912 chars)
  [83]      added    assistant (+8428 chars)
  [84]      added    tool (+149 chars)
  [85]      added    assistant (+3446 chars)
  [86]      added    tool (+150 chars)
  [87]      added    assistant (+715 chars)
  [88]      added    tool (+150 chars)
  [89]      added    assistant (+681 chars)
  [90]      added    tool (+807 chars)
  [91]      added    assistant (+662 chars)
  [92]      added    tool (+17608 chars)
  [93]      added    assistant (+18140 chars)
  [94]      added    tool (+149 chars)
  [95]      added    assistant (+720 chars)
  [96]      added    tool (+809 chars)
  [97]      added    assistant (+298 chars)
  [98]      added    tool (+141 chars)
  [99]      added    assistant (+294 chars)
  [100]      added    tool (+1141 chars)
  [101]      added    assistant (+1398 chars)
  [102]      added    tool (+135 chars)
  [103]      added    assistant (+1117 chars)
  [104]      added    tool (+135 chars)
  [105]      added    assistant (+506 chars)
  [106]      added    tool (+8433 chars)
  [107]      added    assistant (+421 chars)
  [108]      added    tool (+4157 chars)
  [109]      added    assistant (+1946 chars)
  [110]      added    tool (+542 chars)
  [111]      added    assistant (+525 chars)
  [112]      added    tool (+624 chars)
  [113]      added    assistant (+1340 chars)
  [114]      added    tool (+274 chars)
  [115]      added    assistant (+811 chars)
  [116]      added    tool (+263 chars)
  [117]      added    assistant (+507 chars)
  [118]      added    tool (+417 chars)
  [119]      added    assistant (+2730 chars)
  [120]      added    tool (+291 chars)
  [121]      added    assistant (+847 chars)
  [122]      added    tool (+809 chars)
  [123]      added    assistant (+1562 chars)

Compare this to my next make a pr prompt. Much lighter weight.

  [/diff-context]
Context diff HEAD → WORKING
Model:           opencode/big-pickle (unchanged)
Messages:        124 → 136 (+12)
  assistant    62 → 68 (+6)
  tool         58 → 63 (+5)
  user         4 → 5 (+1)
Tool calls:      75 → 82 (+7)
Total chars:     275974 → 298799 (+22825)
Approx tokens:   68994 → 74700 (+5706)
Changes by position:
  [0..123]  identical (124 msgs)
  [124]      added    user (+34 chars)
  [125]      added    assistant (+971 chars)
  [126]      added    tool (+20477 chars)
  [127]      added    assistant (+449 chars)
  [128]      added    tool (+418 chars)
  [129]      added    assistant (+1098 chars)
  [130]      added    tool (+382 chars)
  [131]      added    assistant (+342 chars)
  [132]      added    tool (+327 chars)
  [133]      added    assistant (+1061 chars)
  [134]      added    tool (+174 chars)
  [135]      added    assistant (+215 chars)

The agent created this PR which failed CI with a build error on the sqllogictest job. I made another commit and then asked the agent to fix its build. At this point, the agent was ready for compaction and I hit a bug in our prototype. I have it trying to fix itself now.

As you can see, this diff functionality would be very useful for Open Code developers to track the evolution of context, especially under code changes to Open Code.

Conclusion#

We’re definitely looking for feedback here. Please try out this harness and tell us what you think. Were the Git features useful? Do you want to see others? As always, you can come chat with us on our Discord or create a GitHub issue.