Jan-Stefan in an interview about CTX and AI coding

Two things right now. First, onboarding: documentation, an explainer video, and a setup that also works without agents. Until now ctx was mainly my own tool; now pull requests and feedback are coming from outside, and you quickly notice where the docs exist only in my head. Second, the background process I call Dream. It links knowledge blocks and marks outdated content. Currently it is learning to reassess older judgments as soon as a new block contradicts them, instead of waiting for the next regular Dream run.

AI coding is not a helper here — it is the way of working. ctx is built with ctx: the agents that write the code read the architecture decisions, mistakes, and corrections from previous sessions out of the store before every session and write their own back. Without this memory, every session starts from zero. That is exactly the cross-machine problem I wanted to solve, and the project is its own hardest test case.

The harness is Claude Code in tmux and Hermes-Desktop. The strongest model orchestrates, plans, and reviews; one level below, agents build clearly scoped work packages, each in its own Git worktree. Sub-agents are the normal case for me: in a measured three-day stretch, 200 of them ran, and around 90 percent of all tool calls happened inside them. Recurring workflows live in skills — for example planning with built-in counterchecks, decision templates as a clickable page with technical details and diagrams, code review with an evidence level per finding, and a closing ritual at the end of a session.

ctx itself is a single Go program with PostgreSQL 18, pgvector for vector search, and TimescaleDB for time series. It is accessed via MCP, a command line, or HTTP; the MCP server is part of ctx, and through it multiple Claude instances and other harnesses share the same knowledge state. In operation, my setup uses no cloud model: scoring, linking, and answer synthesis run on a local Qwen with 27 billion parameters on a DGX Spark, with embeddings also local. The store itself therefore needs no cloud service and has enough headroom on the hardware for parallel use.

Other users instead use Claude Sonnet with a low thinking level or DeepSeek. Backend management is deliberately kept adaptable.

There is no single figure for ctx alone, because Claude Code only keeps its logs for 30 days. Since June 2026, though, I have been collecting usage with tokscale across all tools and projects. As of today that stands at a good 117 billion tokens from just under 11,000 sessions on 220 active days. Of those, 112 billion were read from cache and only 590 million were generated. That ratio shows what agentic work actually looks like: little is written, reading is constant. Roughly half of that fell to ctx in the last 30 days; the months before May 2026 are only patchily recorded.

At the APIs’ list prices, that would correspond to around 100,000 US dollars. The Claude Ultra subscriptions I used explicitly for this cost about 3,000 euros over that period.

What can be documented across the whole stretch is in the repository: since late March 2026, a good 2,100 commits on 117 active days, 234 releases, just under 600,000 lines of Go, almost two thirds of them tests. It started in late 2025 as a key-value store via n8n’s MCP node. That echoed every input in full and talked too much, so it became webhooks first and then a program of its own. The rewrite in Go took about an hour.

I count hours differently than I used to. In that three-day stretch, 44 finished work packages were produced, and I typed 52 messages for that. Just under half of them were automatic routine to hand a full session over to a fresh one; only eight were decisions. My time goes into planning and decisions, not into writing. According to my partner, though, I am very busy compared with before. It simply is fun to push creative freedom and explore.

I have been programming for more than 20 years, self-taught, and for more than twelve years professionally in enterprise and consulting environments, most of the time between software development and infrastructure. I have been running my own servers since 2006.

In 2017 I actively worked with PyTorch for image generation and style transfer.

In 2021 I took part as a developer in an ML project for detecting problematic crypto tokens, to protect investors from fraud.

With the release of the small DeepSeek-R1 models in January 2025, my focus shifted completely to local inference and its possibilities. I built my first own harness only a few months later and quickly found that it takes a fair amount of brute force to define clean prompts for individual work steps in a harness.

I have been working fully agentically since late 2025, and ctx grew out of exactly that shift, because at the time we did not yet have a million tokens of context per session: after a few weeks it was clear that writing code was not the bottleneck, but that every new session had forgotten the decisions of the last one. Since then ctx has been the memory behind every session, across multiple machines and Claude accounts. Today my personal tenant holds a good 10,000 blocks there.

Agents already design schematics, layouts, and firmware today. Developing independently, for me, means someone checks whether it works — and that is where the limit is. Software gives an agent feedback in seconds: the test passes or it does not. Hardware answers in weeks and costs money with every attempt. As long as simulation does not replace that feedback, a human with a measuring instrument stays in the loop. Because various competent manufacturers run board reviews and ask follow-up questions before it gets expensive, the barrier is falling and the whole thing is becoming more realistic.

I see the biggest limits not in the intelligence of the models anyway, but around them. First, memory: agents are stateless, and what travels when summarizing from one session to the next not only gets less but also shifts. An observation becomes a recommendation; the recommendation becomes a rule. Second, self-reporting: a model sounds just as confident with a wrong answer as with a right one. Scolding it changes nothing. What helps are external checks — tests, measurements, and a second agent that reads against the source. Third, completion reports: “done” is said faster than it is verified. A large part of my successful work on and with ctx consists of building structures for these three points that do not rely on good intentions.