What one agent spent
The credits one agent spent over a window, summed from the credit ledger rows this agent caused. The sum is read from the ledger rather than from the metering journal, because the ledger is the money and the journal is only a replay cache. An agent with no spend in the window answers zeroes rather than 404, so a dashboard renders a zero row instead of an error.
The credits one agent spent over a window, summed from the credit ledger rows this agent caused.
The sum is read from the ledger rather than from the metering journal, because the ledger is the money and the journal is only a replay cache. An agent with no spend in the window answers zeroes rather than 404, so a dashboard renders a zero row instead of an error.
Path Parameters
The agent's id, as returned by POST /agents.
Query Parameters
How many days back to report, ending now. The ledger page the report reads is sized past the largest accepted window so a report cannot under-count by paging.
1 <= value <= 907Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/agents/string/usage"{ "agentId": "string", "name": "string", "calls": 0, "credits": 0, "firstAt": "string", "lastAt": "string"}Make one metered putty call on an agent's behalf POST
Runs one MCP tool on behalf of a registered agent, and charges the caller for it. This is the route the agent harness on a user's host calls. **The charge comes first.** Credits are taken before the tool runs, and a caller whose balance is short gets the 402 with nothing metered and no tool run. There is no state in which the work happened and the money did not. **`requestId` is the idempotency key, and it is the caller's job to make it stable.** A network retry of the same work must carry the same id. The first call with an id is charged; a replay of that id returns the same charge and takes no new credits, and says so with `replayed: true`. Two calls that are genuinely different work must carry different ids — reusing one id for different work is how a caller would avoid paying for it, and the server cannot tell the two apart by design. A call refused for want of credits is NOT remembered, so retrying that same id after topping up charges it then. A `402` is a statement about a balance, and a balance changes. `status` is `completed` when the tool ran, and `tool_error` when it ran and refused its own input — a tool that rejects a malformed palette is still work the caller asked for and is still billed. The caller learns the price of every tool from `GET /agents/pricing` before it calls.
List the contract presets GET
Every preset the studio can generate, in catalogue order: the standards first, then the studio's own contracts. A preset carries everything a caller needs to build its form: each parameter's name, its Solidity type, whether it is required, its default, and — for the `ours` presets — the OpenZeppelin files the contract is built on. The parameter order is the constructor's argument order. **The audit label travels with its meaning.** Each preset's `audit` is the trust ceiling for its *unmodified* output, and `reviewed` is not a statement that the contract has been audited: it means the parts are OpenZeppelin's and audited, and the choice of which parts, and how they are wired, is not. The `ours` presets — the Merkle claim, the shares split, the escrow, the staking pool — are `experimental`, because nothing of ours is audited. The Wizard has no kind for them, and OZ v5 removed the library utilities that used to cover them. **A `wizard` preset's constructor takes the initial Ownable owner, which the catalogue does not declare as a parameter**, because it is the deploying account and putty cannot know which account that will be. `POST /contracts/generate` says so in its `constructorNote` whenever the returned argument list is empty for that reason. **Free, and no bearer token.** This is a catalogue read: the same data a UI block renders before anyone has signed in.