NEWTON’SExact ID
The client chooses an ID returned by the live catalog. Unpublished names are rejected.
Routing & receipts
Trust the route.
Read the receipt.
A model name should not be a vague preference. Newton’s reports what you requested, what resolved, whether an explicit fallback ran, and whether the call was included with membership or settled against prepaid credit.
Pinned by default
No silent substitution.
Automatic model routing is not part of the current public API. You select a published model ID, and Newton’s requires the upstream-reported identity to match.
Identity check
The returned identity must match the pinned route. Unconfirmed identity fails closed.
Visible result
The response records requested and resolved IDs plus explicit fallback status.
Fallback is opt-in. A client may provide up to three documented, published fallback IDs. Newton’s tries them in order and reports when one is used.
Request evidence
Every accepted call accounts for itself.
Receipts are operational and accounting metadata. They improve observability, but they are not cryptographic attestations.
| Receipt field | Question it answers | Where it appears |
|---|---|---|
| Request ID | Which call should support investigate? | Response header and receipt |
| Requested / resolved model | Did the route match the client’s intent? | Response headers and receipt |
| Fallback used | Did an explicitly configured fallback run? | Response header and receipt |
| Billing mode / included | Was the request included with Solo or Team, or prepaid? | Response headers and receipt |
| Membership plan / policy status | Which interactive plan and policy state applied? | Response headers and receipt |
| Request cost / remaining balance | What did a trial or Agents request consume? | Prepaid response header and account view |
| Usage and duration | How large and how slow was the call? | Response body and request log |
Infrastructure should explain itself.
Use the documented headers and settled receipt to reconcile every request.