Skip to main content
Arrow 2and Arrow 2 Telos are here

Changelog

What shipped

Updates to the App and the API Platform, newest first. Subscribe via RSS.

  1. 2026

    API Platform

    Data Controls now shows a Model training row in place of Inference data. The row shows whether QuiverAI may train its models on your inference inputs and outputs.

    The Improve QuiverAI setting now controls model training only. It is on by default. When an organization Owner or Admin turns it off, QuiverAI stops training on that organization’s inference inputs and outputs, and still stores them as your other data settings allow. Not storing customer content is never a self-serve choice; it is set through a contract.

    The x-quiverai-inference-data-policy response header keeps its three values. QuiverAI now derives the value from your training and content storage settings.

    See Data Controls for the current settings.

  2. 2026

    API Platform

    The QuiverAI API now uses the x-quiverai- prefix for four data posture response headers: inference-data-policy, payload-capture, request-metadata-policy, and request-metadata-retention-seconds. Sandbox responses use x-quiverai-environment: test.

    The previous x-quiver- names are still emitted with identical values until December 31, 2026. They are deprecated and scheduled for removal on that date. The x-quiver-zero-data-retention response header has been removed; it never represented a ratified zero-data-retention guarantee. This update changes header names and documentation, not the underlying data policies or retention behavior.

    See the API reference introduction for the current headers and a link to Data Controls.

  3. 2026

    API Platform

    Arrow 1.x retires at 08:00 UTC (10:00 Berlin) on October 16, 2026. The affected accepted model IDs are arrow-1, arrow-preview, arrow-1.1, and arrow-1.1-max. arrow-1.0 is already rejected and remains rejected.

    Use arrow-2 for SVG generation, vectorization, editing, and animation. Existing native endpoint paths do not change. Arrow 2 uses measured token pricing instead of the fixed-credit prices used by Arrow 1.x.

    Existing Arrow 1.x requests and GET /v1/models remain unchanged until the cutoff. At the cutoff, the affected IDs stop serving, disappear from GET /v1/models, and return 404 model_not_found. Requests are not silently routed to Arrow 2.

    API key migration depends on the key’s model authority:

    • A key that allows all models only needs the request model changed to arrow-2.
    • A key scoped to an exact Arrow 1.x model is immutable. Create a new key for arrow-2, deploy the new secret, then revoke the old key after traffic has moved.
    • Rotating an existing key replaces its secret but preserves its authority. Rotation is not a model migration.

    New exact-model API keys can no longer select Arrow 1.x. Existing Arrow 1.x-scoped keys continue to work until the cutoff.

  4. 2026

    API Platform

    POST /v1/responses runs on Arrow’s Open Responses contract. Declare function and custom tools, execute function_call items yourself, and point a stock Open Responses client at it unmodified. The endpoint is stateless: previous_response_id and store: true are rejected rather than silently ignored.

    Arrow 2 and Arrow 2 Telos are priced by measured token usage rather than fixed credits, reported as billing.rates on GET /v1/models.

    Sandbox keys reach the same routes as production keys but never reach a model. They return deterministic output marked x-quiver-environment: test, and a documented inline marker lets you slow a streamed response down on demand to exercise client-side timeout handling.

    Every response carries rate-limit headers — limit, remaining, reset, scope, subject and dimension — so a client can back off before it is throttled.

    API key issuance and rotation are crash-recoverable. A failure mid-rotation can no longer strand an organization or leave a phantom live secret.

    Arrow 1, Arrow 1.1 and Arrow 1.1 Max remain available through the API.