GitHub Spark is shutting down August 31 — export code now and replace broken `llm()` calls

GitHub announced on August 4 that the current GitHub Spark experience on github.com is being retired. It stopped accepting new users and new app creation immediately, while existing users can access Spark only until August 31 to export apps they already created. GitHub says apps that were already deployed will continue working after the builder is retired. A separate dependency has already failed: GitHub Models, the inference service behind Spark’s `llm()` function, retired on July 30, so `llm()` calls no longer work and affected apps need another inference provider.

The practical risk is easy to misread because the editor and the deployed runtime have different fates. A deployed Spark app may stay online after August 31, but builders can lose the managed development surface unless they export the source first, and AI features that rely on `llm()` may already be broken today. For builders who used Spark as a fast route from prompt to production, this is a concrete reminder to keep source, deployment and critical service dependencies recoverable outside a managed app builder.

GitHub says the retirement applies specifically to the current Spark experience on github.com. New users and new app creation stopped on August 4, and existing users can keep accessing Spark only until August 31. Apps that were already deployed are expected to continue working after Spark is retired. That distinction matters: runtime continuity does not remove the need to preserve an editable source copy before the workbench disappears.

Spark was natively integrated with GitHub Models for AI features, including through its `llm()` helper. GitHub Models retired on July 30, and GitHub says calls to `llm()` no longer work. Apps without `llm()` calls are not affected by that specific retirement; apps that use it must switch to their own inference provider and take responsibility for API credentials and billing.

GitHub’s migration instruction is direct: open the Spark workbench for an app, choose the overflow menu, and select `Create repository`. GitHub’s current Spark documentation says repository creation captures the app’s code and prior Spark changes and commits, giving the owner a normal GitHub repository that can be maintained through standard development workflows after Spark access ends.

GitHub says models and agentic development tools have advanced and that builders are increasingly choosing Copilot workflows in VS Code, Copilot CLI and the GitHub Copilot app. That is GitHub’s stated rationale for aligning its product experiences; it is not a promise that those tools reproduce every Spark-managed capability such as its hosted data store, authentication or one-click runtime.

Spark bundled code generation, a managed data store, GitHub authentication and deployment into one product surface. Once an app matters, builders should separate the conveniences they can replace from the state and dependencies they must preserve. Exporting source is the first step, but owners should also inventory AI calls, hosted data, authentication assumptions, secrets and deployment requirements before relying on post-retirement runtime continuity.