The guard — @dynamoprotocol/guard

A hard spending cap for any OpenAI-compatible tool, in one command. This is the spend-control front door: no payment setup, no money — Control Mode end to end. The guard runs on your machine; the engine side is your hosted Dynamo instance, and only metering facts (stream ids, unit counts) ever reach it — prompts and completions never leave your machine.

export DYNAMO_CORE_URL=https://your-instance-url
export OWNER_API_TOKEN=your-owner-api-token
export PLUGIN_WIRE_TOKEN=your-plugin-wire-token   # the metering wire's bearer
npm install @dynamoprotocol/guard @dynamoprotocol/sdk
npx @dynamoprotocol/guard up

(A .env file in the working directory works too — chmod 600 it; the guard reads it and token values never enter your shell history.)

It prints a base URL and a key:

  dynamo-guard is UP — hard cap enforced by your dynamo-core (Control Mode).

    Base URL   http://127.0.0.1:4000/v1
    Model      dynamo-guard
    API key    eyJhbGciOiJFUzI1NksiLCJ0eXAiOiJkeW5hbW8t…   (allowance credential)

    Cap        1000000 units (1 unit = 1 token) on stream stm_…
    Core       https://your-instance-url
    Upstream   openai/gpt-4o-mini (live provider — OPENAI_API_KEY found in env)

Point Cursor, Cline, Aider, a LangGraph or CrewAI graph — anything that speaks the OpenAI API — at that base URL with that key. Your provider key stays local (the guard reads it from your environment and never writes it to a file). When the cap is spent, the tool gets HTTP 402. npx @dynamoprotocol/guard status shows the live stream with remaining units; npx @dynamoprotocol/guard down stops the proxy.

What it is

Packaging, not a new component: a local LiteLLM proxy + the litellm-dynamo plugin, provisioned with a capped stream on YOUR instance. The "API key" it prints is a real allowance credential — the same offline-verifiable JWS the money rails use — which is exactly why the upgrade path costs nothing: the same credential mechanics back a capped session on escrow or the card sandbox when a money mode is enabled on your instance.

Why start here

• The cap is enforcement, not observation. The 402 arrives before the

spend, not in a report after it. The credential check is in-process and offline; metering is async — a remote instance adds no latency to your requests (request-path purity).

• Revocation is instant. Kill the session and every in-flight caller

loses the allowance mid-stream.

• Nothing to trust. No money exists anywhere in the stack; the worst

possible outcome of a misconfiguration is a denied request.

The operator path shows the same pattern scaled to a multi-user storefront.