runcycles/cycles-client-typescript

cycles-client-typescript looks like the most adoption-ready of the Cycles SDKs so far. It has a clear audience: Node.js and TypeScript teams building AI agents that need budget checks, tool permission control, audit events, and multi-tenant runtime policy before expensive work actually runs. The README does a strong job of turning that into usable patterns instead of only describing the protocol. withCycles is the right default abstraction for normal async work, reserveForStream fits LLM streaming well, and the lower-level CyclesClient path is still available for teams building their own integration layer.

The API design feels practical for the JavaScript ecosystem. Using AsyncLocalStorage for getCyclesContext() is a good fit for concurrent async workloads, and the README is honest about lifecycle behavior: denial prevents execution, errors release reservations, commits retry in the background, heartbeat extends TTL, and nested withCycles calls can double-count budget. The streaming handle documentation is especially useful because it explains race behavior around commit(), release(), dispose(), and failed commits.

The repo also has unusually strong supporting material. There are examples for OpenAI, Anthropic, AWS Bedrock, Google Gemini, LangChain.js, Vercel AI SDK streaming, and Express middleware, which makes the SDK feel immediately testable in real app shapes. The project has CI, npm provenance publishing, Scorecard, Dependabot, Apache-2.0 licensing, security/community files, Vitest, ESLint, tsup, dual ESM/CJS output, and zero runtime dependencies via built-in fetch and AsyncLocalStorage. The audit notes are a real trust signal too: they claim all 9 endpoints are protocol-conformant, include OpenAPI contract tests, and report 317 tests with roughly 98% statement and 99% line coverage.

The biggest improvement I’d make is release hygiene. package.json, CHANGELOG.md, and AUDIT.md reference 0.3.3, but GitHub releases currently show v0.3.1 as latest. If 0.3.2 and 0.3.3 were published to npm without GitHub releases, adding matching tags/releases would avoid confusion for users checking provenance. I’d also consider a short compatibility matrix for Node versions, runtimes, and framework examples. Overall, this is a polished SDK with strong docs, tests, and real-world examples; the main remaining work is keeping release metadata as clean as the implementation.