Stability

The rule

Agents on the other side of an MCP connection cannot be redeployed by Miles. So:

• A shipped tool's declared parameters are never renamed or removed. A test in Miles' build fails on any field or tool disappearing.
• A breaking change ships as a new tool name plus a deprecation window on the old one, never an in-place edit of an existing field.
• A pure addition, a new optional parameter or a new tool, can appear at any time without notice.
• The resource URI miles://guidance/working-with-miles and the points_question prompt's question argument are never renamed either.

The Chat API

/v1/chat/completions follows the OpenAI request and response shapes. Two things are outside that contract and may change with a changelog entry rather than a deprecation window: the x-miles-quota-* headers, and the miles object on non-streaming responses.

The one exception on record

On 2026-08-20 the refusal channel changed shape. Every declared parameter schema was untouched, but a refusal (a spent ceiling, a missing scope, a Membership gate) stopped arriving as the tool's ordinary JSON text and started arriving as an isError result with a structured code. A caller that detected a refusal by parsing the tool's text got a plain sentence and a parse error instead. It shipped without a deprecation window because the connected population at the time was two users, and it is recorded here rather than hidden so the promise above stays honest.

Credentials

Every credential Miles mints carries a prefix: miles_sk_ for a personal key, miles_at_ and miles_rt_ for OAuth access and refresh tokens, miles_ac_ for an authorization code. The prefixes are stable and safe to match on.