Unless you're creating a disposable throwaway filesystem that's isolated between API calls, you're setting yourself up for a whole lotta stateful shenanigans...

> With a typical LLM SDK

What is a typical LLM SDK?

I get the "Why Claude Code", just not the "Why a REST API". It doesn't seem to solve a problem at all.

Check the "Who It's For"

> Solo founders who use Claude Code daily and want to use it in toolchains

I can do that just fine without a REST API

> Backend developers adding AI capabilities to services and APIs

You can interact with Claude Code just fine. In fact I wouldn't use CC here since I want control over how it's ran, and CLAUDE.md just doesn't have that power.

> AI tinkerers building agentic workflows, automation, and experiments

Ditto.

> Data engineers who need structured, typed LLM output in pipelines

This has nothing to do with the REST part. I don't see how this is better than just an SDK with structured output.

> Platform teams exposing Claude Code to internal services

I guess I see the appeal a bit here, but anthropic has a platform that can handle agents for you, and this seems like a better fit than a clunky REST API between a CLI tool.

Have we stopped with helpful titles nowadays?

I'm the maintainer of this project. I made this so I could plug and play agentic workflows into existing systems. The prototype I built was for a self-hosted inbox assistant (shoutout Inbox Zero). I wanted to extend the assistant's capabilities without writing my own orchestrations. For instance, I already have a claude code config to get data from my CRM. Rather than program that into the existing service, I just sent the calls to claude code instead.

This isn't going to solve every use case. In most places a proper SDK like BAML will be better suited.

Cheers.

PS - The Anthropic Agent SDK doesn't have native support for streaming JSON. Other SDKs like Vercel and BAML (and Koine) solve this with prompt hacking and schema validation in the client.