KODE SDK

The deciding trait is that a session is a thing you can come back to. Restart the process, or branch a conversation that went wrong at a chosen point, and the work is still there rather than gone. If you have shipped anything where a user closed a tab halfway through and lost an hour of an agent's output, you know why that matters.

What you take on is a runtime with real opinions and a database behind it. Pick it if long runs are your product. Pick something thinner if your agent answers in thirty seconds.

Resumption is where this gets subtle. Internal state can be rewound cleanly because it lives in a database the runtime owns. Everything the agent did outside that database cannot be, and the documentation describes the stages without describing compensation for external effects. Fork a session past a step that created a branch, sent a request or wrote a file, and the second run does it again.

What it does right is separate the streams. Progress, control and monitoring arrive on different channels, so a user interface does not have to guess which is which.

1. Naming the stages is what makes this analysable. A snapshot taken at an arbitrary moment is a guess about consistency; a snapshot taken at an enumerated boundary has a stated invariant, and a reader can reason about what is true at each one. 2. Designating a single fork point rather than allowing forks anywhere is the conservative and correct choice.

2. Persistence is offered through two storage engines with different durability characteristics, and the documentation does not state which guarantees hold under each. No evaluation is published.

Giving away the runtime that other people's products are built on is a recognised strategy, and it pays in exactly one currency: influence over how a category is shaped. There is no hosted tier here, no commercial edition and no support contract, so the return has to arrive somewhere other than this repository.

Moat: whatever mindshare the design earns before the model vendors ship their own. Likely acquirer: none for the code; the authors are the asset. Position: build on it, pin the version, and keep your persistence layer swappable.

The commercial question is not this package, it is the service underneath it. Commands run in a hosted sandbox operated by somebody I have not contracted with, which means a security review, a data processing agreement and an answer to where source code is executed and for how long it is retained. That review costs more than the library saves.

There is no per-seat cost and nothing to install on desks, so the real expense is the team that builds and operates whatever gets shipped. Approved with conditions: one approved sandbox vendor, contracted, and no others.

A base URL parameter is worth more than a list of blessed vendors, because it means the set of things I can call is decided by me rather than by a release cycle. The documentation names five services that already work that way, which tells me somebody actually tested the path instead of leaving it as a theoretical escape hatch.

Tools arrive over the protocol or through a skills directory, so extending it does not mean patching the library. Permissive licence, readable TypeScript, and a fork that would compile.