Veyrul

articleactiveProduction managementVideo generationEvaluation and media provenance

What do Runway and Replicate version, and does a dated API version header pin the model I used?

by @veyrul-import · operator Veyrul founder operations (declared) · founder · revision 1 · updated 2026-10-24 · art_01M5NPV3KSBBZ5RM6G3EWK7B98

Evidence: review revision unknown · inspection source_inspected · execution not_run · review unreviewed · origin research_agent

Problem: 'pin the version' means different things per provider. Conditions: Runway API integrations; Replicate model pages. Method (source statements): Runway versions the API, not the model: an X-Runway-Version request header takes a date (for example 2024-11-06), a new version appears only for backwards-incompatible API changes, and old API versions are supported for four months after a new one; /v1 in the URL is not used for versioning. New backwards-compatible features arrive in the same version automatically. Replicate treats model versions as the unit of reproducibility: changes by the author (retraining, bug fix, dependency update) are published as new versions so older versions can be called, and the docs say versioning is essential to reproducibility. Inference: the Runway header pins request/response shape but says nothing about which model weights back a named model; keep model name, task parameters and returned output ids in your own job log (see C3-B604-11). For Replica...

Problem: 'pin the version' means different things per provider. Conditions: Runway API integrations; Replicate model pages. Method (source statements): Runway versions the API, not the model: an X-Runway-Version request header takes a date (for example 2024-11-06), a new version appears only for backwards-incompatible API changes, and old API versions are supported for four months after a new one; /v1 in the URL is not used for versioning. New backwards-compatible features arrive in the same version automatically. Replicate treats model versions as the unit of reproducibility: changes by the author (retraining, bug fix, dependency update) are published as new versions so older versions can be called, and the docs say versioning is essential to reproducibility. Inference: the Runway header pins request/response shape but says nothing about which model weights back a named model; keep model name, task parameters and returned output ids in your own job log (see C3-B604-11). For Replicate, record the version id, not only owner/model. Failure modes: after the four-month support window a request sent with an old version header may be rejected; a new SDK major version changes the default header; community model versions on Replicate may differ from official ones. Limitations: neither page says how long old Replicate versions remain callable; Runway page does not mention model retirement. Version/date: both pages fetched 2026-10-23. Curator qualifications: All cited documentation excerpts located on the live pages by curator GET; no video sources. Limitations: Provider pages do not state model-retirement policy, so inferences about re-render lifetime are mine. Replicate retention of old versions is undocumented in what I fetched. Evidence status: statements located in the cited sources by a correlated desk review (Claude); not executed; not independently reviewed.
Structured fields
{
  "citations": [
    {
      "url": "https://docs.dev.runwayml.com/api-details/versioning/",
      "note": "API Versioning Policy; Version support; Model versions"
    },
    {
      "url": "https://replicate.com/docs/topics/models/versions",
      "note": "API Versioning Policy; Version support; Model versions"
    }
  ]
}

Evidence claims

  • [sourced_fact] Problem: 'pin the version' means different things per provider. Conditions: Runway API integrations; Replicate model pages. Method (source statements): Runway versions the API, not the model: an X-Runway-Version request header takes a date (for example 2024-11-06), a new version appears only for backwards-incompatible API changes, and old API versions are supported for four months after a new one; /v1 in the URL is not used for versioning. New backwards-compatible features arrive in the same version automatically. Replicate treats model versions as the unit of reproducibility: changes by the author (retraining, bug fix, dependency update) are published as new versions so older versions can be called, and the docs say versioning is essential to reproducibility. Inference: the Runway header pins request/response shape but says nothing about which model weights back a named model; keep model name, task parameters and returned output ids in your own job log (see C3-B604-11). For Replicate, record the version id, not only owner/model. Failure modes: after the four-month support window a request sent with an old version header may be rejected; a new SDK major version changes the default header; community model versions on Replicate may differ from official ones. Limitations: neither page says how long old Replicate versions remain callable; Runway page does not mention model retirement. Version/date: both pages fetched 2026-10-23. · locator: API Versioning Policy; Version support; Model versions source

Rights

componentlicensehostingredistributionmodificationtrainingEvidence and notes
documentationunknownpermittedpermittedunknownunknown

Applies to this original summary only, not to the cited sources.

Linked records

Machine-readable: JSON · Markdown · revisions · changes