Memory, harnesses and fewer tokens: what grew in open-source agent and data infrastructure, autumn 2026

Every few months we read the open-source charts to see where developer attention is going. This is the autumn 2026 reading, for the window 19 August to 18 October 2026. The short version: almost all the growth in developer infrastructure is in agent infrastructure. Databases grow when they present themselves as memory or context for agents, and stay flat when they present themselves as databases.

We look at ten categories below. For each one: who is growing and by how much, why we think it is growing, and what it means if you are building on it. At the end we say where Loams fits, with the status of each part, and what we plan to build next.

How we measured, and what stars do not tell youCopy Anchor Link

Totals and licences come from GitHub's REST API (repos/{owner}/{repo}), read on 18 October 2026. Growth is the number of stars a repository gained from 19 August to 18 October (60 days), and where we say so, from 18 September (30 days). It comes from GitHub's stargazer history endpoint, which star-history.com described when it appeared in September (star-history.com, 2026-09-05). The older per-user stargazer listing stopped working for repositories you do not own in July (star-history.com, 2026-07-06). Every number in this post has one of those two sources and that date. We dropped numbers we could not trace to either.

Three caveats before the numbers:

• Stars measure attention, not use. A star is a bookmark. Some of the largest new counts on GitHub this year look inorganic, and we left those repositories out. Treat every number here as "people looked", not "people deployed".
• New-repo charts are mostly not infrastructure. Of the 773 repositories created since 18 August with more than 500 stars, most are consumer apps, skill collections and guides. We read the infrastructure ones and ignored the rest.
• One public trend source is down. OSS Insight's trending API has returned empty results since March 2026, by its own note, so we did not use it.

Two outside lists agree with what we found. Runa Capital's ROSS Index for Q3 2026, which ranks the fastest-growing open-source startups, is dominated by orchestration, agent runtimes, memory and knowledge, token-cost tools and browser agents (Runa Capital, Q3 2026). Star History's monthly themes for 2026 were Skills in March, Computer Use in April, Harness in August and structured agent Output in September (Aug, Sep). None of them was about databases.

The mapCopy Anchor Link

One more signal is worth stating before the categories, because it shows up in GitHub descriptions rather than star counts. Established data projects are rewriting their one-line descriptions around agents. On 18 October, TiDB's says it is "built for agentic workloads", RisingWave's calls it an "event streaming platform for agentic AI", Databend's a "Data Agent Ready Warehouse", Electric's "the agent platform built on sync", and Instant's "the best backend for AI-coded apps". The products did not change overnight. The audience they are written for did.

1. Agent harnesses and workspacesCopy Anchor Link

This is where most of the attention went.

• deepseek-ai/deepseek-harness (MIT) gained 91.7k stars in 60 days, to 253k. Star History called it the fastest repository to reach 200k (star-history.com, 2026-09-02). Its design rule is "everything is a plugin": the model, tools, memory, storage and sandbox.
• stablyai/orca (MIT), a desktop orchestrator that runs agents in parallel git worktrees, gained 48.1k, to 96.3k.
• paperclipai/paperclip (MIT), "manage agents at work", gained 25.6k.
• The agents themselves kept growing: openai/codex +23.8k, earendil-works/pi +23.3k and anomalyco/opencode +18.6k.
• herdrdev/herdr (Apache-2.0), a Rust runtime that keeps agent terminals alive across disconnects and restarts and shows each pane as working, blocked or idle, gained 14.4k.
• apache/maka (Apache-2.0), an agent workspace incubating at the ASF that "keeps a complete record of everything it did", gained 4.5k.

Why it is growing. People have moved from running one coding agent to running several at once, and the problem changed with it. With one agent you watch the terminal. With five you need somewhere to see what each one is doing, resume one that stopped, and review what it changed before it lands. Worktree-per-agent and a diff review screen are now the expected baseline, not a feature.

What it means for builders. The harness is becoming a commodity with plugin points. If you build tools for agents, build them to plug in (an MCP server, a skill, a protocol adapter) rather than as another harness. If you build a harness, the open question is the record: what the agent did, why, with which tool calls, kept somewhere you can query later. herdr and Maka both lead with that, and it is still mostly kept on one laptop.

2. Memory layersCopy Anchor Link

Memory is the fastest-growing data category of the quarter.

The shapes differ. Hindsight describes "agent memory that learns" with retain, recall and reflect operations, and publishes its benchmark results. claude-mem captures coding sessions as a plugin. OpenViking calls itself a "context database" and unifies memory, retrieval and skills behind a filesystem-like address space. TencentDB Agent Memory is a team memory hub that sits in front of the model as a proxy. mem0 and Graphiti, the established projects, are still growing, but at around 6% in 60 days against Hindsight's 156%.

Why it is growing. Coding agents forget everything between sessions, and teams now run several agents that share nothing. Memory is the obvious fix, and benchmarks such as LongMemEval and LoCoMo have given the category a way to compare claims. Projects quote large gains on them; those are their own numbers, and the ones worth trusting publish the method next to the result.

What it means for builders. Memory is turning into a storage problem with a model in the write path: raw episodes in, extracted facts and links out, with time and provenance on every fact, and a hard requirement to forget. Two practical points. First, keep the raw input; extraction prompts will improve, and you will want to re-run them. Second, check licences before you embed one: the field mixes MIT, Apache-2.0, AGPL-3.0 and vendor licences, and they carry different obligations if you ship a service.

3. Code graphs and "fewer tokens"Copy Anchor Link

The second data category that grew is code context for agents, sold on token savings.

• Graphify-Labs/graphify (Apache-2.0) turns a codebase, its docs and PDFs into a queryable knowledge graph. It gained 20.9k, to 128.2k, and is second in the ROSS Q3 list.
• headroomlabs-ai/headroom (Apache-2.0), a context-compression proxy, gained 9.4k. Its README has a "when to skip" section, which we liked.
• rtk-ai/rtk (Apache-2.0), a Rust CLI proxy that trims command output, gained 8.1k.
• colbymchenry/codegraph (MIT) gained 7.8k and DeusData/codebase-memory-mcp (MIT), a single C binary served over MCP, gained 7.7k.

Why it is growing. Token spend is the main cost for heavy users of coding agents, and "N times fewer tokens than grep" is a claim anyone can test on their own repository in an afternoon. Easy to verify and easy to share is a strong combination.

What it means for builders. A code graph is now an expected input to a coding agent, the way a language server is an expected input to an editor. If you publish one, publish the token number with the task it was measured on. If you consume one, measure it on your own code; savings on a benchmark repository say little about a monorepo.

4. MCP: an interface, not a categoryCopy Anchor Link

The Model Context Protocol is everywhere in this quarter's READMEs, but it does not trend on its own. Look at two kinds of project:

• Products that ship an MCP server grew. t8y2/dbx (Apache-2.0), a 25 MB Rust database client for many engines with an AI SQL assistant and an MCP server, gained 11.5k, to 27.1k. codebase-memory-mcp (above) and xerj-org/xerj (Apache-2.0), a Rust hybrid search engine with an Elasticsearch-compatible API and MCP, gained 7.7k and 6.8k.
• Servers that are only MCP grew slowly. Google's googleapis/mcp-toolbox (Apache-2.0) for databases gained 535, and bytebase/dbhub (MIT) gained 311.

Two related conventions are spreading the same way. Agent Skills became a distribution channel this year: GitStarClub's year-to-date list, as of 30 August, has skill collections among the top gainers (GitStarClub, 2026), and Star History's September issue treats skill installs as a usage metric. And the Agent Client Protocol (ACP), which lets a workspace drive any agent that implements it, is named in the READMEs of several of the workspaces above.

What it means for builders. MCP is now table stakes for anything an agent might call, like a REST API was for anything a web app might call. Nobody stars a REST API. Ship the MCP server, ship a skill that explains how to use your tool, and put your effort into what the tool does. Also treat an MCP endpoint as an API with permissions: an agent with a database tool can do what the tool's credentials can do.

5. Graph and search engines on object storageCopy Anchor Link

The databases that grew this quarter are the ones built for agent memory and priced like object storage.

• hydra-db/hydradb (AGPL-3.0) went from creation on 3 July to 13.1k stars, 12.6k of them in our window. It is a Rust graph database on SlateDB over S3, with OpenCypher and Neo4j driver support, and disposable query and indexer nodes. It is eighteenth in the ROSS Q3 list.
• FalkorDB/FalkorDB (Server Side Public License) gained 4.9k, positioned for GraphRAG.
• HelixDB/helix-db (Apache-2.0), graph, vector and BM25 in Rust on object storage, gained 422.
• ModernRelay/omnigraph (MIT), a small but interesting one: graph, vector and BM25 fused with reciprocal rank fusion over Lance on S3, with git-style branching and Cedar policies. It gained 278.

A note on licences, because they matter if you build on these. AGPL-3.0 and SSPL are legitimate choices for a project that wants hosted copies to share their changes. They are also stricter than Apache-2.0 or MIT if you plan to offer a service on top. Read the licence before you embed the engine, not after.

Why it is growing. "Graph for agent memory" and "object storage is cheap and durable" are the two stories of the quarter, and these projects tell both at once. Separating stateless compute from the bucket is not new (we wrote about it in part 1 of this series), but it is now the expected design for a new engine, not an exotic one.

What it means for builders. Ask any engine in this category three questions. Where does a write become durable, and what does it cost in latency? Which formats are on the bucket, and can another tool read them without the engine? And what happens to the indexes, graph and vectors together, when a node dies? The answers vary more than the READMEs suggest.

6. A database per agent, and Postgres for agentsCopy Anchor Link

This idea is louder in blog posts than in star counts. The pitch is that if storage is on a bucket and compute is disposable, a database per agent, per session or per branch becomes cheap enough to be the default, and an agent can try a migration on its own copy before anyone sees it.

The star numbers are modest. supabase/supabase (Apache-2.0) gained 4.0k, to 111.7k. malisper/pgrust (AGPL-3.0), Postgres rewritten in Rust, gained 738. Microsoft's pg_durable, durable execution inside Postgres, gained 77. And upstream neondatabase/neon (Apache-2.0), the project most associated with branchable Postgres on object storage, gained 385; its last push was on 31 August 2026.

What it means for builders. Branching a database for an agent is useful only if the branch is cheap to create, cheap to throw away and isolated from the parent. Copy-on-write storage gives you the first two. The third needs credentials scoped to the branch, which is easy to forget when the branch is created by a tool call.

7. Git for agentsCopy Anchor Link

When agents write most of the commits, the version control system has more to record: which session produced a commit, which prompts and tool calls, and which checkpoint to roll back to.

• pacifio/atlas (Apache-2.0), "source control for coding agents", links checkpoints and commits to agent sessions. It gained 8.6k, to 9.6k.
• enroute-sh/enroute (Apache-2.0), created on 24 August, is a Rust Git server on S3 with programmable hooks. It has 265 stars and calls itself early 0.x.
• modem-dev/hunk (MIT), a review-first terminal diff viewer for agent-written code, gained 1.1k.

What it means for builders. Git's data model is fine. What is missing is the link from a commit to the run that made it, and storage that does not mind a hundred short-lived branches a day. Both are solvable without leaving Git's wire protocol, which is the property worth keeping.

8. Sandboxes and microVMsCopy Anchor Link

Unattended agents need isolation, and the projects here grew steadily rather than explosively.

• arcboxlabs/arcbox (Apache-2.0), local Docker-compatible microVMs, gained 3.9k.
• TencentCloud/CubeSandbox, a KVM sandbox compatible with E2B's API that publishes P95 and P99 cold starts, gained 1.8k. e2b-dev/E2B (Apache-2.0) gained 1.0k.
• strands-agents/box (Apache-2.0), created on 2 October, is small but has an idea worth reading: policy that looks at an agent's history, so a file read can deny a later network request.

What it means for builders. E2B's API is becoming a de facto interface, since others implement it. And isolation alone is not enough: the interesting work is in policy, deciding what a sandboxed agent may do next given what it has already done.

9. Local-first tools, and the object storage under themCopy Anchor Link

"Local-first" in the sync-engine sense was flat this quarter (below). Local-first in the sense of tools that run on your machine as one binary did well. herdr markets itself as one Rust binary; codebase-memory-mcp is one C binary; rtk is a Rust CLI; arcbox runs microVMs on your laptop; most of the fast growers install with one command.

The object storage under self-hosted stacks is shifting too. rustfs/rustfs (Apache-2.0), an S3-compatible store in Rust, gained 4.0k, to 35.1k. minio/minio (AGPL-3.0) has a much larger base, 61.3k stars, but gained 110 in the window, and its last push was on 24 April 2026.

What it means for builders. If your tool needs a bucket for local development, do not hard-code one implementation; test against two. And a single binary with a sensible default is worth more to a first-time user than any feature on the roadmap.

10. What stayed flatCopy Anchor Link

These categories are mature, useful and not where the attention went. Gains over the same 60 days:

• Vector databases: Qdrant +1.2k, Milvus +829, LanceDB +548, Chroma +531.
• Lakehouse and analytics: DuckDB +1.9k, DuckLake +405, iceberg-rust +50.
• Durable execution: Temporal +1.5k, Trigger.dev +548, Restate +280.
• Sync engines: Electric +94, Instant +187, Zero (rocicorp/mono) +62.

Flat is not dead. Vector search is now a feature of everything rather than a product, Iceberg has become the default lake format without needing stars, and durable execution is quietly inside many of the agent runtimes above. Durable execution is the clearest example of framing: few people star "durable workflows", and many star "agent runs that survive a restart", which is the same thing described by its result.

Two adjacent categories we read but do not cover in depth: LLM gateways, where OmniRoute (MIT) gained 28.0k and the field is crowded, and desktop shells, where Tauri gained 2.1k and Electron 1.2k.

What it adds up toCopy Anchor Link

Three patterns run through all ten categories.

1. Agents are the user now. The infrastructure that grew is described in terms of what an agent does with it: remember, find, run, recover, review. Data infrastructure is not less important; it is being chosen by a different reader.
2. The record matters more than the run. Workspaces want the history of every run, memory wants the history of every fact, Git for agents wants the history behind every commit. Those are all data problems, and today most of that data lives on one machine or in one vendor.
3. Cheap storage makes "one per agent" practical. A database per branch, a sandbox per run, a memory space per user: each idea depends on storage that costs object-storage prices and compute you can throw away.

If you build in this space, our suggestions are plain ones. Ship MCP and a skill. Publish numbers with the method and the losses. Keep the raw data in formats other tools can read. And read the licence of anything you embed.

Where Loams fits, and what we are building nextCopy Anchor Link

Loams is an open-source data platform in Rust, under Apache-2.0. Its premise is that your object-storage bucket is the source of truth and compute only holds caches, which puts it in the storage layer of the map above. The status below is from the Loams 0.1.0 feature table (Running Loams). 0.x means APIs and on-disk formats can still change between minor versions.

What ships today.

• Available Collections and hybrid retrieval. Documents stored as Lance and Tantivy on the bucket under one manifest; vector kNN, BM25 and filters fused with RRF in one query, with drop-in Qdrant and Elasticsearch APIs. See the engine and hybrid retrieval.
• Available Loams Graph. GQL graphs on Loams' fork of Grafeo, with writes on the Loams log, snapshots in the bucket and crash recovery. Experimental Graph expansion adds 1 to 2 hops from a search's hits, the GraphRAG pattern, as a search stage and as SQL functions. See Loams Graph.
• Available Loams Durable. Durable promises and tasks for agent runs, from an embedded Resonate server. See Loams Durable.
• Available Loams Postgres. Our hard fork of Neon, with its storage on the bucket, plus Loams SQL, MySQL on a patched TiDB. See Loams Postgres.
• Experimental Loams Studio. Coding agents (Claude Code, Codex, opencode and others) in threads with a git worktree each, diff review, checkpoints, terminals, previews, parallel runs and supervised approvals by default. On by default in Loams Desktop. See Loams Studio.
• Experimental Loams Git. git-remote-loams ships with the CLI, so git clone, fetch and push reach a repository stored on a bucket with no server in between. See Loams Git.

What we are building next. These are plans, not features.

• Planned Loams Memory. Agent memory and code graphs built on the parts above rather than a new engine: raw episodes kept as the ground truth, facts with validity time and provenance, per-user and per-project spaces, a forget that cascades to everything derived, and one code graph per repository. The design is §52; it is proposed, and no code exists yet.
• Planned MCP and agent tools. Listed as planned in the 0.1.0 feature table. The memory design puts its tools on the same MCP surface.
• Planned loams-sandbox. One isolation crate built around a declarative spec, with a Linux adapter by default and stronger adapters for multi-tenant use. The design is §56; implementation is scheduled after the next preview.
• Planned Also on the roadmap: Loams Git repositories on the server, Iceberg analytics, Kafka wire, Functions and Jobs. In progress First-party source and sink connectors are being built and are not in the release images yet.

What we are not: a harness, a session-capture plugin or an LLM gateway. Those are well served by the projects above, and Studio runs the agents you already use rather than replacing them. Where Loams can help is underneath, as the place where the memory, the run history, the graph and the indexes all live on one bucket you own. We wrote about what that means in more detail in part 3, what agents need from infrastructure, and about our current gaps in what Loams is bad at today.

We will run this survey again in the new year. If we missed a project that belongs here, open a discussion on GitHub.

SourcesCopy Anchor Link

All repository totals and licences: GitHub REST API, repos/{owner}/{repo}, read on 18 October 2026. All star gains: GitHub's stargazer history endpoint, 19 August to 18 October 2026 (60 days) and 18 September to 18 October 2026 (30 days), read on 18 October 2026. Descriptions are paraphrased from each project's README, read on the same day; benchmark and token claims are the projects' own.

• star-history.com: New GitHub star history API (2026-09-05); Stargazer API restriction (2026-07-06); Monthly, August 2026: Harness (2026-08-31); Monthly, September 2026: Output (2026-09-30); DeepSeek Harness, fastest to 200k stars (2026-09-02)
• Runa Capital, ROSS Index Q3 2026
• GitStarClub, 2026 rankings, year to date as of 2026-08-30
• Loams: README; Running Loams and the feature table; §52 Loams Memory; §53 Loams Studio; §56 Loams Sandbox; §36 Loams Git; §51 Loams Postgres