Show HN: Ash – OSS Infra for Running Claude Agent SDK • Hacker News Board

Show HN: Ash – OSS Infra for Running Claude Agent SDK

#1

Post by nicklo » Sat, Mar 07, 2026, 9:51 PM UTC

Hey HN,

I kept rebuilding the same infrastructure every time I wanted to put a Claude Agent SDK into production. Sessions, streaming, sandboxing, persistence, a REST API, file hooks. So I built Ash.

An agent is a folder with a CLAUDE.md file, skills folder, etc, and one-line deploy from cli, or tsx/python sdks.

Some things I cared about when building this:

Sandboxing. Each agent runs in its own isolated process with an environment allowlist, cgroups resource limits, and bubblewrap filesystem isolation on Linux.

Session persistence. All state lives in CRDB. If the server crashes mid-conversation, resume picks up where it left off. You can also snapshot workspaces to S3/GCS and resume on a different machine.

Keeping it thin. The SDK's `Message` types flow through the whole pipeline untranslated, from the Unix socket to SSE to the client. Ash adds session routing, sandbox pooling, and lifecycle management. It doesn't re-wrap or translate the SDK's types.

I've been measuring overhead pretty carefully. Ash adds OSS, Self-hostable, MIT licensed: https://github.com/ash-ai-org/ash-ai

Show HN: Ash – OSS Infra for Running Claude Agent SDK
github.com

Re: Show HN: Ash – OSS Infra for Running Claude Agent SDK

#2

Post by redhanuman » Sat, Mar 07, 2026, 10:02 PM UTC

the cold resume at 32ms is the number that matters most here and workspace restore + process spawn + reconnect in 32ms means you can treat agents as stateless from the infrastructure side without paying the UX cost of a cold start. that's the hard part of session persistence done right.

curious how CRDB handles the write amplification on high-frequency streaming sessions every SSE chunk going to the DB or are you batching at the session boundary?

Re: Show HN: Ash – OSS Infra for Running Claude Agent SDK

#3

Post by nicklo » Sat, Mar 07, 2026, 10:45 PM UTC

redhanuman wrote: post #2

the cold resume at 32ms is the number that matters most here and workspace restore + process spawn + reconnect in 32ms means you can treat agents as stateless from the infrastructure side without paying the UX cost of a cold start. that's the hard part of session persistence done right. curious how CRDB handles the write amplification on high-frequency streaming sessions every SSE chunk going to the DB or are you bat…

Yeah with sandbox pre-warming and disk co-location its fast enough to avoid UX cold start penalty.

On write amplification — we persist at the message level, not per SSE chunk. The sandbox's workspace filesystem (claude code's native jsonl files) is the source of truth for resume, and the DB is for queryability, tracing, etc - so fire and forget works fine here.