# Packages and SDKs

Every WAMP package, what it is for, who consumes it, and its current availability — with source-checkout and host-provided availability.

Source: https://docs.vampikez.fun/reference/packages/

Choose packages by execution environment. Extension UI receives its runtime
modules from the host; backend integrations can use documented HTTP directly.
Extension authors need only the public extension SDK. Packages used internally
by the host are listed separately because they are not extension dependencies.

## Packages you would consume

| Package | What it does | Availability |
|---|---|---|
| `@wamp/extension-sdk` | Author extensions: public API declarations, manifest types, compiler, WAMP style preset, templates, and the `wamp` CLI. See [The wamp CLI](/reference/cli/) | Not on npm. Ships inside WAMP Desktop, which puts `wamp` on the `PATH` of every shell it opens; otherwise build it from the source checkout |
| `@wamp/app-sdk` | Server-side app identity — generate a keypair, issue end-user tokens, mint installation tokens, and use a typed Cloud client | Not on npm |
| `wamp-engine` | The standalone secured headless core: `serve`, `call`, `local`. This is what the desktop app spawns | Build from the source checkout |
| `@wamp/ui` | Host-provided renderer module. Its complete public declarations and build preset ship inside the extension SDK. See [Interface kit](/build/ui/) | Runtime import; do not install separately |

## Packages internal to the platform

These exist because the platform is split across processes and hosts. You do not
consume them directly, but knowing they exist explains the shape of everything
else.

| Package | What it is |
|---|---|
| `@wamp/engine` | The host-agnostic AI runtime: agents, runs, tasks, the tool registry, MCP, compaction, plan mode |
| `@wamp/shared` | The cross-process contract surface — one typed IPC contract per domain, plus the extension manifest schema |
| `@wamp/api-fetch` | Auth-aware HTTP client: token storage, the refresh state machine, SSE streaming, the AI proxy |
| `@wamp/remote-engine-client` | Client for an engine core running on another machine |
| `@wamp/runner` | The sandbox runner |

`packages/engine-node` is worth one line of its own: despite living beside the
others, it has no `package.json` and is not a package. It is the headless Node
composition layer — plus the prompt, agent-definition, and skill assets the
engine ships — compiled into whichever host consumes it.

## What each one wraps

If you are deciding whether to wait for a package or write the request yourself:

- **`@wamp/app-sdk`** wraps two cryptographic contracts — signing an app
  assertion and signing an end-user token — plus a typed client over the Cloud
  HTTP API. The signing steps are about ten lines
  of `jose` each; [Apps and credentials](/identity/apps-and-credentials/) shows
  them. The Cloud client is a convenience over documented HTTP.
- **`@wamp/extension-sdk`** is the supported build boundary. It packages every
  author-facing declaration, validates private imports, bundles ordinary npm
  dependencies, generates the WAMP UI CSS and creates the installable ZIP. The
  [manifest reference](/reference/manifest/) is derived from the same schema.

## Versions

For source-based consumption, pin one repository commit across WAMP packages
and use its lockfile. Internal package versions do not establish a public
compatibility history. `compat.pluginApi` in an extension manifest is the
separate runtime compatibility check; see [The manifest](/build/manifest/).