Antimatter

Docs

Hosted agents

Run agents here, give them paid tools and let them pay for services.

Hosted agent runsPOST/v1/agents/{id}/runs

An agent wallet can run on the server. Give it a definition with PUT /v1/agents/{id}/definition (a key with the agents scope): a model (a model id or an Autopilot id, on the agent's own list), its instructions, its tools, and limits for each run. Then POST /v1/agents/{id}/runs with an input starts a run, from your key or the agent's own. The model is called, the tools it asks for are run, and the model is called again with their output, until it answers without asking for a tool. Each step is its own job, one model call or one batch of tool calls, so a run outlives any one request. Every model call is a request from the agent's own key, held and settled against its wallet under its daily cap, per request ceiling and model list.

The tools are function (yours, as in chat completions: the run pauses as requires_action and waits up to 600 seconds for POST /v1/agents/{id}/runs/{run}/tool_outputs to answer every call it lists), code_interpreter (JavaScript in a sandbox with no network, no filesystem, 2000 ms and 64 MB a call; with "language": "python", Python 3 with its standard library under the same limits, nothing installable and only a scratch filesystem in memory, starting in about a second), mcp (a remote MCP server you name, https only, Streamable HTTP; its headers are stored encrypted and read back only by name, and a save that leaves them out keeps them), image_generation (pictures from an image model you name, through the images endpoint, billed to the agent) and file_search (your vector stores, or the ones its vector_store_ids names, searched as the agent's key and billed to it; the model reads numbered passages with their file names). A tool's output is cut at 16 KB before the model reads it. The server's calls in one batch run side by side, up to 4 at once. Each paid call's worst case is set aside from what the run can still spend before it starts, so a batch never goes over the run's ceiling. Outputs go back in the order the model asked, and a cancel stops every call in flight.

A run is held to max_steps (default 20, at most 50), max_wall_seconds (default 600, at most 3600) and max_cost_micros (default 1000000, at most 20000000). The definition can lower them, and a run can lower them further. Before each model call its worst case is priced as a request is held, and a run that could not cover it stops as incomplete with the reason. Its status is queued, in_progress, requires_action, then completed, incomplete, failed, cancelled or expired. Pausing or deleting the agent, or a freeze, stops its runs. Follow one at GET /v1/agents/{id}/runs/{run}/events: JSON after ?after=, or with Accept: text/event-stream events numbered from 1 that a client resumes with Last-Event-ID. POST /v1/agents/{id}/runs/{run}/cancel stops it. A finished run is kept 30 days. On the hosted MCP server, antimatter_agent_run starts a run and waits for it, and antimatter_agent_run_get reads one.

The builder at /agents/build does all of this on one page, from four templates (research, a support inbox, data extraction, a studio producer), with a test run beside the editor. Every run lists the cost of each step; a finished run can be run again from the builder or the dashboard, with the same input and definition, once its first step is priced.

curl -X PUT https://useantimatter.com/v1/agents/42/definition \
  -H "Authorization: Bearer $ANTIMATTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "inclusionai/ling-3.0-tiny",
    "instructions": "Answer briefly. Use code to do arithmetic.",
    "tools": [{"type": "code_interpreter"}],
    "limits": {"max_steps": 8, "max_cost_micros": 200000}
  }'

curl https://useantimatter.com/v1/agents/42/runs \
  -H "Authorization: Bearer $ANTIMATTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input": "What is 17 to the power of 9?"}'

curl -N https://useantimatter.com/v1/agents/42/runs/run_.../events \
  -H "Authorization: Bearer $ANTIMATTER_API_KEY" \
  -H "Accept: text/event-stream"

Tools marketPOST/mcp/tools

Remote MCP tools that providers list with a price per call, all behind your key. Add https://useantimatter.com/mcp/tools to any MCP client with your key as a bearer token. Every listed tool appears as server__tool. The endpoint is stateless Streamable HTTP and speaks both the 2026-07-28 protocol (no handshake, the version in _meta and the MCP-Protocol-Version, Mcp-Method and Mcp-Name headers) and the earlier one that opens with initialize. Or skip MCP: GET /v1/tools lists every tool with its input schema, billed price and measured success and latency, and POST /v1/tools/{server}/{tool}/call with arguments calls one and answers its content, structured_content and is_error.

A call uses the chat scope, and a key policy can block it with the tools wire. Its model lists and budgets treat the tool by its id tool/<server>/<tool>. It is paid from a balance only, never the free allowance. The provider's price plus the margin is held before the call and charged only when the tool answers without an error. A tool's own error, a server that fails, an answer over 256 KiB and a call past 30 s cost nothing. The billed figure is in x-antimatter-cost-micros. A call's arguments go to the provider's server and are not kept here. In a hosted agent run, a tool entry {"type": "antimatter_tools"} offers the market's tools (or the servers and tools you name) without an MCP configuration of your own, paid by the agent's wallet. Providers list a server at /tools/provide.

claude mcp add --transport http antimatter-tools https://useantimatter.com/mcp/tools \
  --header "Authorization: Bearer $ANTIMATTER_API_KEY"

curl https://useantimatter.com/v1/tools/$SERVER/$TOOL/call \
  -H "Authorization: Bearer $ANTIMATTER_API_KEY" \
  -H "content-type: application/json" \
  -d '{"arguments": {"query": "antimatter"}}'

Paying servicesPOST/v1/pay/fetch

Paying services is not on here. When it is, the gateway pays x402 services on the web for your agents. POST /v1/pay/fetch takes url, method, headers, body and max_micros, and fetches the URL. When the service answers 402 with x402 version 2 terms in PAYMENT-REQUIRED, the gateway holds them to your spending rules, signs an EIP-3009 transfer of the asked USDC from its own wallet, sends the request again with PAYMENT-SIGNATURE and hands you the answer in {status, headers, body, payment}. Your balance is charged what was paid plus 10%, once the chain shows the payment moved, and never from the free allowance. A personal key needs the pay scope. An agent's key pays from the agent's own balance once its owner switches it on at /agents/spend.

curl https://useantimatter.com/v1/pay/fetch \
  -H "Authorization: Bearer $ANTIMATTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://api.example.com/premium-data", "max_micros": 50000}'

Only the exact scheme by EIP-3009, in USDC on Base, is paid. One payment is at most $1.00 at the service's price. A payer pays at most $5.00 a UTC day unless its rule says otherwise, and the gateway caps every payment together each day. Rules name allowed and denied hosts (*.example.com for subdomains), a per payment cap, a daily cap and an expiry. The owner's denied hosts apply to every agent. A host the rules refuse is never contacted. An AP2 open payment mandate's constraints (amount_range, budget with a DAILY agent_recurrence, allowed_payees, execution_date) may be given as ap2_constraints and are read into the same rules. A refusal is payment_refused or payment_cap_reached, with a code, and nothing was signed. The URL goes through the network guard (https, public addresses, no redirects), with a 20 second timeout and an answer read up to 1 MB. A payment record keeps the host, never the path, headers or bodies. GET /v1/pay/payments lists them. On /mcp the tool is antimatter_pay_fetch, and a hosted run's definition may name the x402_fetch tool.

Agent passportsGET/v1/agents/{id}/identity

An agent can carry a portable identity on the ERC-8004 Identity Registry on Robinhood Chain, and a record any service can check without knowing its owner. The owner opens a passport on the dashboard. Antimatter serves its registration file, ERC-8004's agent card, at /agents/id/{slug}/agent.json, and the token's URI points there. The owner's own wallet sends register(agentURI) and pays the gas. Nothing counts as registered until the chain is read back: the transaction, the registry's Registered event naming the owner's wallet and this URI, then ownerOf and tokenURI.

curl https://useantimatter.com/v1/agents/self/identity \
  -H "Authorization: Bearer $AGENT_KEY"

The record is only what Antimatter measured: requests and how many were answered 2xx, what the balance was charged, x402 payments made and settled on chain, completed hosted runs, disputes raised on its requests and the days active. Each figure is the sum of day evidence leaves, and each sealed day names its receipt root and the root of the agent's own leaves in it (/api/agents/id/{slug}/days/{day} gives the paths). The attestation is EIP-712 typed data signed by the attester (/api/agents/id/attester). Antimatter gives no feedback on the Reputation Registry, because it is not the agent's client; the passport shows what other clients gave. A token on chain cannot be erased, because the registry has no burn. Its owner can transfer it.