A channel-by-channel availability ledger for Grok 4.7

Grok 4.7 has more than one relevant availability date.

SpaceXAI launched the model on September 21 and stated that it was available through its API, Cursor, Grok Build, third-party coding harnesses, model routers, and cloud platforms. The company also listed standard API pricing starting at $2 per million input tokens and $6 per million output tokens, with a faster variant at twice those prices (SpaceXAI announcement).

Two distributors provide narrower, independently dated records. GitHub announced Grok 4.7 in GitHub Copilot on September 21 (GitHub Changelog). AWS announced availability through Amazon Bedrock on September 28 (AWS announcement).

Those records establish a sequence: an umbrella launch and a Copilot announcement on September 21, followed by a Bedrock announcement seven days later. They do not establish that every route named by SpaceXAI became usable at the same moment, exposed equivalent interfaces, or produced equivalent behavior.

One model, several dated events

A model name is too coarse for an availability record. For procurement and release planning, the useful object is a route-specific event: who announced it, on what date, through which interface, and with which stated capabilities or commercial terms.

The following ledger is an SGL-derived way to organize the supplied announcements. It is an operating aid, not a claim that the publishers use this schema.

Route	Confirmed event date	Confirming publisher	What the record states	What remains outside the record
SpaceXAI API	September 21, 2026	SpaceXAI	API availability; standard pricing starts at $2 per million input tokens and $6 per million output tokens; a faster variant costs twice as much	Account eligibility, regional access, quotas, latency, and observed behavior
GitHub Copilot	September 21, 2026	GitHub	Grok 4.7 availability in Copilot	Interface-specific controls, feature parity with the direct API, and observed performance
Amazon Bedrock	September 28, 2026	AWS	Bedrock availability; AWS describes mixed-document handling, repository-scale coding with planning and error recovery, and browser-use agents for forms and portal navigation	Equivalence to other routes, observed task results, and route-specific commercial details
Other routes named by SpaceXAI	September 21, 2026 umbrella claim	SpaceXAI	Cursor, Grok Build, third-party coding harnesses, model routers, and cloud platforms were included in the launch statement	A distributor-specific dated record for each named route in the supplied evidence

The first three rows attach a specific publisher to a specific route. The last row deliberately preserves a weaker evidence state. SpaceXAI’s announcement documents its distribution claim, but the supplied sources do not independently confirm every named destination.

Keep capabilities attached to their source

AWS describes mixed-document handling, repository-scale coding with planning and error recovery, and browser-use agents for forms and portal navigation in its Bedrock announcement (AWS announcement). That wording belongs to the Bedrock record. It does not demonstrate those behaviors in a buyer’s workload, and it does not establish that another route exposes the same configuration or surrounding tools.

The direct API price belongs to the SpaceXAI record for the standard and faster API variants (SpaceXAI announcement). The supplied evidence does not provide Copilot or Bedrock pricing, so the API figure cannot fill those cells by analogy.

GitHub’s record is narrower: it confirms launch-day availability in Copilot (GitHub Changelog). That is valuable precisely because it answers one bounded question without implying interface or behavior parity with the direct API.

Add operational evidence after the announcement

An announcement ledger can establish what each publisher documented and when. Adoption decisions often involve additional questions that these three records do not answer: whether a particular account can select the model, which regions or plans expose it, what limits apply, how the route identifies versions, and how the model behaves inside the intended harness.

A team could extend each ledger row with four internally observed fields:

• first successful access time, tied to the organization’s account and region;
• exact model or deployment identifier returned by the interface;
• relevant route configuration, including harness, tools, and fallback policy;
• a link to workload-specific evaluation results.

These fields are a proposed operating practice, not facts supplied by the announcements. They turn the external availability record into a local adoption record while preserving the boundary between publisher statements and observed access.

The distinction matters when dates diverge. September 21 is supported as the SpaceXAI launch date and the GitHub Copilot announcement date. September 28 is the supported Bedrock announcement date. Collapsing both into “Grok 4.7 launched September 21” would hide information relevant to a team waiting on Bedrock, while calling September 28 the model’s universal release date would discard the earlier records.

Availability is therefore best stored as a set of route-level events rather than one property on the model. The model announcement begins the ledger; each distributor record adds a dated row; internal access checks add local evidence. Teams designing the surrounding system can carry those distinctions into their build decisions, where endpoint, interface, configuration, cost, and observed behavior become part of the evaluated deployment rather than assumptions inherited from the model name.