We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.

In our experience, most apps don't need cross-tenant queries outside of BI. For example, think about the apps you use on a daily basis: Linear, Slack, ChatGPT all fit well with an actor-per-workspace or actor-per-thread model.

To be clear, we're not trying to replace Postgres. We're focused on modern workloads like AI, realtime, and SaaS apps where per-tenant & per-agent databases are a natural fit.

Using SQLite for your per-tenant or per-agent databases has a lot of benefits:

- Compute + state: running the SQLite database embedded in the actor has performance benefits

- Security: solutions like RLS are a security nightmare, much easier to have peace of mind with full DB isolation per tenant

- Per-tenant isolation: important for SaaS platforms, better for security & performance

- Noisy neighbors: limits the blast radius of a noisy neighbor or bad query to a single tenant's database

- Enables different schemas for every tenant

- AI-generated backends: modern use cases often require AI-generated apps to have their own custom databases; this model makes that easy

A few other points of reference in the space:

- Cloudflare Durable Objects & Agents are built on this model, and much of Cloudflare's internal architecture is built on DO

- https://neon.com/use-cases/database-per-tenant

- https://turso.tech/multi-tenancy

- https://www.thenile.dev/

- Val.town & Replit

> Better usage of resources

I'd be curious to hear more about what you mean by this.

> always allows a parent style agent do complex queries

Do you have a specific use case in mind where agents need to query other agents' data?

However, we are planning on building a query engine that can operate over multiple databases. One option we're considering is exposing Rivet SQLite as a DuckDB datasource: https://duckdb.org/docs/stable/data/data_sources

Today we've released SQLite storage for actors (Apache 2.0).

Every actor gets its own SQLite database. This means you can have millions of independent databases: one for each agent, tenant, user, or document.

Useful for:

- AI agents: per-agent DB for message history, state, embeddings

- Multi-tenant SaaS: real per-tenant isolation, no RLS hacks

- Collaborative documents: each document gets its own database with built-in multiplayer

- Per-user databases: isolated, scales horizontally, runs at the edge

The idea of splitting data per entity isn't new: Cassandra and DynamoDB use partition keys to scale horizontally, but you're stuck with rigid schemas ("single-table design" [3]), limited queries, and painful migrations. SQLite per entity gives you the same scalability without those tradeoffs [2].

How this compares:

- Cloudflare Durable Objects & Agents: most similar to Rivet Actors with colocated SQLite and compute, but closed-source and vendor-locked

- Turso Cloud: Great platform, but closed-source + diff use case. Clients query over the network, so reads are slow or stale. Rivet's single-writer actor model keeps reads local and fresh.

- D1, Turso (the DB), Litestream, rqlite, LiteFS: great tools for running a single SQLite database with replication. Rivet is for running lots of isolated databases.

Under the hood, SQLite runs in-process with each actor. A custom VFS persists writes to HA storage (FoundationDB or Postgres).

Rivet Actors also provide realtime (WebSockets), React integration (useActor), horizontal scalability, and actors that sleep when idle.

GitHub: https://github.com/rivet-dev/rivet

Docs: https://www.rivet.dev/docs/actors/sqlite/

[1] https://news.ycombinator.com/item?id=42472519

[2] https://rivet.dev/blog/2025-02-16-sqlite-on-the-server-is-mi...

[3] https://www.alexdebrie.com/posts/dynamodb-single-table/

Comments URL: https://news.ycombinator.com/item?id=47197003

Points: 45

# Comments: 16

- TUI (I prefer this for most programming)

- Web UI (negligible difference than VS Code)

- Mobile support (via web UI)

- TypeScript SDK to automate

It's not a fork of OpenCode. Instead, it implements the OpenCode protocol and just runs `opencode attach` to the server that converts API calls to the underlying agents.

We build this to scratch our itch of being able to rapidly switch between coding agents based on the task at hand. For example, we find that:

- Claude Code is the best executor & fast iterator - Codex (high) is the best for complex or long-running tasks - OpenCode for fine-tuned, do-exactly-as-I-say edits

I personally believe that harnesses matter almost as much as the models in 2026. OpenCode lets you swap out models already, but the CC & Codex harnesses + system prompts make a big difference in practice.

Under the hood, this is all powered by our Sandbox Agent SDK:

- Sandbox Agent SDK provides a universal HTTP API for controlling Claude Code, Codex, and Amp - Sandbox Agent SDK exposes an OpenCode-compatible endpoint so OpenCode can talk to any agent - OpenCode connects to Sandbox Agent SDK via attach

I want to emphasize: the Anomaly folks are doing awesome work with OpenCode agent + Zen + Black. I use OC regularly alongside CC & Codex depending on the task. Gigacode is only possible because OpenCode is insanely flexible, hackable, and well documented.

Give it a try:

$ curl -fsSL https://releases.rivet.dev/sandbox-agent/latest/gigacode-ins... | sh

Check out the project, architecture, and other install options:

https://github.com/rivet-dev/sandbox-agent/tree/main/gigacod...

Comments URL: https://news.ycombinator.com/item?id=46912682

Points: 27

# Comments: 11

(Sprites.dev in the works already.)

Posted this morning an overview of the project: https://x.com/NathanFlurry/status/2018366627021291699

As you said – in terms of project goals, the biggest difference is:

- ACP seems to be focused on providing a universal API for the subset of features required for editors

- Sandbox Agent SDK is focused on automating agents, so aims to provide a much more comprehensive API coverage for niche agent-specific features

We maintain a feature coverage matrix (https://sandboxagent.dev/docs/session-transcript-schema#cove...) – it's early, much more coming soon.

We open-sourced the Sandbox Agent SDK based on tools we built internally to solve 3 problems:

1. Universal agent API: interact with any coding agent using the same API

2. Running agents inside the sandbox: Agent Sandbox provides a Rust binary that serves the universal agent API over HTTP, instead of having to futz with undocumented interfaces

3. Universal session schema: persisting sessions is always problematic, since we don’t want the source of truth for the conversation to live inside the container in a schema we don’t control

Agent Sandbox SDK has:

- Any coding agent: Universal API to interact with all agents with full feature coverage

- Server or SDK mode: Run as an HTTP server or with the TypeScript SDK

- Universal session schema: Universal schema to store agent transcripts

- Supports your sandbox provider: Daytona, E2B, Vercel Sandboxes, and more

- Lightweight, portable Rust binary: Install anywhere with 1 curl command

- OpenAPI spec: Well documented and easy to integrate

We will be adding much more in the coming weeks – would love to hear any feedback or questions.

Comments URL: https://news.ycombinator.com/item?id=46795584

Points: 41

# Comments: 7

Hacked together an SF parks ranking system based on current weather

https://sfparks.nathanflurry.com/

Comments URL: https://news.ycombinator.com/item?id=46049417

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45644047

Points: 6

# Comments: 2