Local open weight models will definitely be a future trend. Imagine if an Opus-level model could run locally: many more latent use cases would likely emerge, since Opus is priced so high. Perhaps the future will be a multi-model architecture, where frontier models handle planning and local models carry out the concrete execution.
I’ve been building pie, an open-source coding agent written in Rust. The initial reason was that I had some proactive, long-term automated tasks to run on a local DS v4 model. Therefore, I needed a customizable agent runtime to support these custom tasks, such as triggers, to perform some simple automation, Over time, the project gradually became more and more usable, so I thought I might as well turn it into a proper project.
Of course, most of the code in this project was written by AI. If you’re sensitive to AI-generated code or AI coding, feel free to simply ignore it.
Pie runs inside your local project directory, can inspect/edit files, run shell commands, keep resumable sessions, and use different model providers, including local OpenAI-compatible servers.
The goal is not just to build another chat UI for coding, but a local agent runtime for developer workflows: slash commands, session history, skills, MCP tools, cron/triggers, and a small hub so agents running on different machines can send messages to each other.
A few things I’ve been focusing on recently:
- local/session-first workflows: resume sessions, search history, save transcripts
- model flexibility: Anthropic/OpenAI/etc., plus local OpenAI-compatible endpoints
- MCP and skills for attaching project-specific tools/instructions
- cron/triggers for lightweight automation inside a coding session
- SSH/headless support for running agents on remote dev boxes
- a web UI that mirrors the terminal runtime rather than replacing it
- an optional hub for agent-to-agent messaging and notifications
it has nothing to do with TiDB, db9 is built from scratch.A good way to think about it is that db9 is similar to tidb-server, it provides a PostgreSQL wire protocol and SQL layer, while the actual data lives in the underlying KV layer.
Hello, the developer of db9 here. You’re right, that section is indeed a bit too brief. We will add more architecture documentation later.
What I wanted to convey is that, unlike a standard PostgreSQL, db9 is more like a pg SQL-compatible layer built on top of a large distributed KV store.
I also shared a brief introduction in this tweet, which might help clarify things. https://x.com/dxhuang/status/2032016443114733744
In large-scale metadata scenarios, JFS recommends using a distributed key-value store to host metadata, such as TiKV or FoundationDB. Based on my experience with large JFS users, most of them choose TiKV.
A good example is TiDB's implementation of vector indexes. TIDB is also a MySQL-compatible distributed transactional database, which separates the storage engine for vector indexes from the transactional store through an extra replica in its OLAP engine (via TiFlash), avoiding resource contention.