One recipe, exact saved code, usable from any harness.

pantry stores a recipe and hands back its exact code. Any harness fetches the same source and runs it in its own isolate. pantry never runs it.

Read the docs

discover pantry list # slugify, deploy_coey_worker, …

fetch pantry get slugify

export default (input) => ({
  slug: String(input.title)
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, "-")
});

run pantry run slugify # in the caller's own isolate
```
{ "slug": "my-first-pantry-recipe" }
```

pantry hands back exact code. It never runs it.

The recipe shape

A recipe is a named JavaScript function body with an input schema, capability tags, status, version, and an owner. pantry keeps it in D1 and returns the code verbatim when asked.

Discovery without custody transfer

GET /recipes lists names, descriptions, schemas, capabilities, status, version, and shared author provenance without transferring code. Fetch the full source only when the artifact fits.

It never runs your code

pantry stores and transports. Running a fetched recipe, and in what isolate, is the caller's trust decision. The example runner is a convenience, not a sandbox.

What pantry adds

Runtime extensions live inside one agent. A pantry recipe is a portable artifact any harness can fetch. Think extensions are runtime-local capabilities for a Think agent; pantry is a runtime-neutral code registry where any harness fetches the exact saved source and chooses its own execution authority.

Reuse here means fetching the exact reviewed artifact with provenance. Capability tags are metadata for the caller, not permissions enforced by pantry.

How a recipe gets used

discover    GET /recipes        your names + schemas, no code
fetch       GET /recipe/:name   the full recipe, including code
decide      caller's choice     run it, or re-reason it
run         caller's isolate    pantry is not involved

A saved recipe helps only for a recurring pattern. Novel work still needs reasoning, because there is no saved artifact to fetch.

[ opt-in shared pantry ]

Shared recipes move artifacts between harnesses

Private is the default. Shared recipes are opt-in artifacts with author owner, version, and status visible before code fetch. A recipe stays private unless you push it with visibility: "shared" or pantry push --shared.

push        visibility: "shared"   publish your own recipe
list        GET /recipes?scope=shared   shared names + schemas, no code
fetch       GET /recipe/:name       your recipe wins, then shared
trust       author owner            provenance on the shared row

Writes stay owner-scoped. Shared reads show the author owner as provenance, because the server still never runs a recipe and capabilities are tags, not grants. The caller still decides whether to fetch code, whether to run it, and what isolate deserves the risk.