DreamerOS

Build on DreamerOS

Build on answers that show what was checked.

DreamerOS is a checking layer for AI answers that builders can call through the live REST and MCP paths. A receipt is attempted after each eligible answer.

When receipt minting succeeds, public proof shows signed fields you can verify. Signed-in accounts can see their own private receipt context.

Try it free. No card, ever.
A request passing through the checked pipeline before it returns
What runs behind one API call

Use the MCP door

One URL. Your key. The tools your plan includes.

Point an MCP-capable client at one URL and pass your own key. The client can call the DreamerOS tools its plan includes: remember a fact, recall it later, route a question, or use a checked chat path. Each result shows what ran. Every tier from Light up carries a key.

Direction, protocol, auth, scope
direction: your client reads and writes through your account only protocol: MCP session over HTTPS auth: your own dros_ API key, revocable any time scope: the tools your plan includes; route-specific checks report what ran tiers with a key: Light, DreamWeaver Solo, DreamWeaver Duo, DreamerOS Pro, DreamerOS Elite
A question passed through the checked pipeline
How an answer is checked

Bring your own engine

Your key is your engine. We check what runs on it.

Bring an OpenAI, Anthropic, Perplexity, Google or xAI key through a supported connection and that provider bills the model work. DreamerOS-owned routes can select from five customer engine families. The checks differ by route, plan, and mode; the response shows what actually ran.

Direction, protocol, auth, scope
direction: DreamerOS calls the selected engine and reports which checks ran protocol: provider API over HTTPS auth: your own connected key or DreamerOS session vault boundary: production connection writes refuse to proceed when required vault encryption is unavailable scope: the engine answers; route-specific DreamerOS checks and billing rules apply customer engine families: ChatGPT, Claude, Gemini, Grok, Perplexity
What DreamerOS adds on top of the engine you bring
The engine is yours. The check is ours.

Read a receipt

Every eligible call attempts one receipt you can open when minted.

DreamerOS attempts a receipt after each eligible response. If minting fails, the answer still returns without receipt fields. When a receipt is minted, public proof exposes signed verification fields, while a signed-in account can see its own private receipt context. Ask for the record in plain words, an operator view, or raw public fields, and stop at the one you understand. Check public proof.

Direction, protocol, auth, scope
direction: receipt minting is attempted after each eligible checked call protocol: JSON when minting succeeds, or GET the receipt by id auth: your own dros_ API key public fields: signed verification proof only signed-in fields: your private receipt context failure: the answer returns without receipt fields
One receipt opens in three layers: plain, operator, engineer
One record, three layers

Rate and rules

What each plan allows, in one line.

Each key has an hourly request ceiling. Light allows 10 requests an hour and caps receipt minting at 25 a day. Paid plans have higher hourly request ceilings and no daily receipt cap, up to 500 requests an hour on DreamerOS Elite. When a confirmed limit blocks a call, the response names the limit instead of claiming success.

Direction, protocol, auth, scope
direction: limits apply per key, checked on every request protocol: HTTP 429 with a reason when a ceiling is hit auth: your own dros_ API key scope (requests/hr, receipts/day): Light: 10, 25 a day DreamWeaver Solo: 50, no daily cap DreamWeaver Duo: 50, no daily cap DreamerOS Pro: 100, no daily cap DreamerOS Elite: 500, no daily cap
Each plan has a daily ceiling, shown as a wall on each track
Where the spending stops

Docs

Read the tools you already use next: the Connect page for mail, files, code and money, client setup, and the plain-words answers.

More detail

What the checked routes can run

The path depends on the endpoint, plan, and mode. A normal chat can shape the question, select an engine, run available checks, and attempt a receipt. Raw mode and specialist endpoints take different paths. The response and receipt show the fields that were actually recorded.

Endpoints, at a glance

POST /api/v1/verify checks a text claim and returns the verdict fields available at the requested depth. POST /api/v1/underwrite creates a signed recommendation record for eligible callers. GET /api/v1/fingerprint/export exports the caller's fingerprint when that route and tier allow it. POST /api/v1/provenance/claim timestamps a submitted claim. GET /api/v1/audit/export returns the caller's available audit rows. POST /api/v1/intent/clarify returns a structured interpretation of an ambiguous prompt. Authentication and tier checks apply to each route.

Start with the live REST door

curl -X POST https://api.dreameros.app/api/v1/verify \
  -H "Authorization: Bearer dros_your_key" \
  -H "Content-Type: application/json" \
  -d '{"text": "Churn dropped 40% after the pricing change", "depth": "light"}'

Raw REST works from any stack: JSON in, JSON out, Bearer auth. For MCP-capable clients, use https://mcp.dreameros.app/mcp with your own key and the tools your plan includes. Authentication, tier, limit, and service failures return explicit HTTP states instead of a success label.

SDK is In Beta 2.0

The proposed new DreamerOSClient(...) package is not a customer-ready SDK quickstart. Use the REST or MCP paths above today.

Who this is for

Solo builders ship a feature with checks already attached instead of building that layer themselves. Product teams embed a checked pipeline into an existing app so the UX can show its work, not just claim it. Researchers and students get the internals exposed: engine selection, scores, and the reasoning behind them, to study or benchmark against. Larger teams get role-based keys, org-wide memory, and one audit export instead of assembling that infrastructure themselves.