# Room pricing and revenue preview

Local preview introduced 21 October; direction clarified 22 October 2026.
Initial preview rate approved by the owner: **US$20 per room-hour**.
This covers the room's robots and cameras; the customer's model remains on their
own infrastructure. The current implementation is a local monetary preview.
Payments are not connected, collected revenue is zero, and development credits
retain their existing separate authority and meaning.

Room time meters access to a complete testing or learning environment. The
[commercial assessment](COMMERCIAL_VISION.md#pricing-channels-and-financing)
distinguishes this meter from proposed testing campaigns, repeated evaluation
and managed data offers. Their physical-service pricing and delivery are
unvalidated and do not change this approved rate, existing quotes or settlement
policy. A campaign recommendation does not add a new charge or billing path.

## Planned physical experiment pricing

The product is an experiment requested through MCP/HTTP/Python, with room and
compute resources behind it. Quote the full cost, finite execution limits,
starting-state guarantees, preparation/reset charges and export deadline before
trusted owner approval. A US$20 total cap is an illustrative authorization,
not this preview's hourly rate. Agents cannot self-approve or increase a cap.
Repeated/parallel requests must share existing atomic reservations and settlement.

Best-effort/as-observed runs omit a requested reset but require a usable scene,
current observations, robot health and independent protection. Initialized runs
include a declared measured reset; further resets and campaigns are explicit.
A US$5 minimum and two-hour initialized minimum are hypotheses to cost, not
implemented fees. Before paid activation define failed-preflight, unavailable
capability, cancellation and refund treatment; unusable scenes must not silently
become execution charges. See [state classes](ROOM_TYPES.md#planned-physical-experiment-classes).

Price physical delivery from forward equipment/delivery costs and realistic
lifetime paid utilization, then validate willingness to pay. Track recurring
contribution, incremental station returns including shared staff/space/GPU
thresholds, and whole-company burn separately. The initial funded facility may
have capped early losses while validating demand. Recovering every startup cost
on a few stations in 24/36 months is a sensitivity, not the pricing objective.
The supplied Pro rates and capital envelopes are unverified planning examples;
they do not change existing quotes, records or the calculation below.

## Price policy

Price the reserved UTC calendar window, including startup and the stop reserve.
Round duration up to a whole second, then round the resulting amount up to a USD
cent. All stored amounts are integer cents. At the initial rate:

| Reserved window | Room-price preview |
| --- | ---: |
| 30 seconds | US$0.17 |
| 45 seconds | US$0.25 |
| 90 seconds | US$0.50 |
| 15 minutes | US$5.00 |
| 1 hour | US$20.00 |

Taxes are not calculated. This is a room-time preview, not a checkout total or
an authorization to collect money. Flexible jobs without a calendar booking
retain development-credit quotes and contribute no dollar booking value.
The quoted numerical execution limits remain independent of the booked window;
this does not create continuous rentals or guarantee a start time.

Availability search returns a current price. A hold pins its immutable rate,
window, amount and digest, and confirmation copies that exact price. Rate edits
do not reprice existing holds or bookings. Early completion releases capacity;
its preview still uses the originally reserved window. A valid published
experiment can count as completed even when its task goal fails.

## Configure rates and inspect revenue

Rate edits retain the same local operator authority as room registration.
Ordinary tenant and viewer credentials have no rate mutation endpoint. Inspect
the current rate through room discovery or the pricing read endpoint, then:

```sh
python -m physical_ai_lab farm --db .pal/control.sqlite3 set-price \
  --room-id ROOM_ID --hourly-rate-cents 2000 --expected-version 1 \
  --idempotency-key my-rate-change-01
python -m physical_ai_lab farm --db .pal/control.sqlite3 revenue
```

The operator report aggregates local projects. Optional `--since-unix` and
`--until-unix` filter booking confirmation time, with an exclusive end. The
browser and HTTP reports show only the authorized workshop project's bookings,
alongside shared room rates. They distinguish:

- Completed booking value: successful, released, uniquely executed bookings.
- Pending booking value: confirmed bookings still within their admission window.
- Collected revenue: zero while payments are unconnected.

Cancelled, failed, expired and reused/cached bookings contribute no projected
revenue. Holds never count. Repeated reads and confirmation retries do not add
sales. Earlier bookings with no saved price remain explicitly unpriced; they
are not backfilled at today's rate. These metrics are operating projections,
not an accounting revenue-recognition policy or evidence of paying customers.

## Customer interfaces

All routes use existing project authentication and `Cache-Control: no-store`:

| Operation | Route beneath `/v1/workshop/projects/{project_id}/farm` |
| --- | --- |
| Current rate | `GET /rooms/{room_id}/pricing` |
| Read-only window price | `POST /rooms/{room_id}/pricing/estimate` |
| Scoped revenue report | `POST /revenue/report` |

Estimate bodies contain `starts_at_unix` and `ends_at_unix`; report bodies contain
optional `since_unix` and `until_unix`. The room board includes `revenue`, and
calendar availability, holds and bookings include `pricing`. SDK 0.1.3 provides:

```python
preview = await rooms.estimate_price(room_id=room_id,
    starts_at_unix=start, ends_at_unix=end)
assert preview["real_payment"] is False
print(preview["currency"], preview["amount_cents"])
# The later booking response contains booking["booking"]["pricing"].
```

The installed CLI also supports `actuator-rooms price` with `--room`, `--start`,
`--end`, `--url` and `--project`. It uses the existing token environment variable.
No payment credentials or billing provider are introduced.

## Verification and limits

Farm migration v5 adds immutable rate revisions and nullable calendar price
snapshots. Existing jobs, artifacts, balances, reservations, room templates and
old bookings remain intact. Rates use version checks and exact idempotency;
booking prices are stored inside existing calendar transactions. There is no
second wallet, monetary settlement state machine or scheduler.

An isolated installed SDK 0.1.3 estimated US$0.25, confirmed that exact 45-second
price, controlled both simulated NexArms, exported native results, and observed
the projection move from pending to completed while collected cash stayed zero.
Actual API/worker execution, byte audits and the real browser display were
checked. Nine continuous and eight legacy pair native qualification cases passed
on the current sources. The broader regression passed 553 cases; two additional
pricing cases passed separately. The original failed development checks are
retained alongside final receipts in ignored local state.

[Concise verification record](evidence/room-pricing-2026-10-21.json) records exact
identities, tests and local evidence. Physical/WAN and commercial payments remain
unqualified. Monetary collection later requires its own complete quote, enforced
spending authority, tax/refund terms and idempotent payment integration.