GitHub Spark retires on 31 August 2026: your 26-day export window

Summary. GitHub stopped accepting new GitHub Spark users and new Spark apps on 4 August 2026, and existing users have until 31 August 2026 to export their app code. That is a 26-day window as of 5 August 2026. Apps already deployed keep running after the shutdown. The AI part of them may not: GitHub Models, the inference service behind Spark's llm() function, retired on 30 July 2026, so any llm() call has already been failing for six days. Export is one menu click. The work that follows it is not, because the exported React and TypeScript source still calls four managed services you will no longer have: a key-value store running on Azure Cosmos DB with a 512 KB per-entry limit, GitHub-account authentication, Azure Container Apps hosting, and GitHub Models inference. Replacing the last of those on gpt-5.6-luna costs $0.20 per million input tokens and $1.20 per million output tokens as of 5 August 2026 — roughly ₹18 and ₹105 at 87 to the dollar — which is the cheapest line item in the whole exercise.

Two retirements landed five days apart and they interact. Read them together or you will export code that compiles and then discover the AI features were already dead before you started.

The timeline

Date	What happened	Who it hits
16 June 2026	GitHub Models closed to new customers	New projects only
1 July 2026	Full retirement of GitHub Models announced for 30 July	Everyone using the inference API
30 July 2026	GitHub Models retired: playground, model catalog, inference API and bring-your-own-key all withdrawn from every customer, including those with active usage	Any Spark app calling llm()
4 August 2026	GitHub Spark stopped accepting new users and new app creation	Anyone who had not started
31 August 2026	Last day to export Spark app code	Everyone with a spark they want to keep editing

GitHub's stated reason for the Spark retirement is that AI models and agentic tooling moved on: builders can now do the same work through GitHub Copilot inside VS Code, Copilot CLI and the GitHub Copilot app, and GitHub says it has seen builders increasingly choose those integrated workflows. The change applies specifically to the current Spark experience on github.com.

What the export actually gives you

The mechanism is simple and it is worth doing today rather than on 30 August. Open the Spark workbench for the app, select the ... menu, then select Create repository. A new private repository is created under your personal account, named after the spark. Every change made to the spark before repository creation is included, so you get the full commit record, not a snapshot. From there you can clone it or download a zip.

There is a two-way sync between the spark and the main branch of the repository while both exist, which means a repository created now stays current until the shutdown. That is the argument for exporting on day one instead of day twenty-six.

What you receive is a full-stack web app in an opinionated stack: React and TypeScript, built to work inside Spark's own SDK and core framework. GitHub is explicit that compatibility with that SDK is not guaranteed once you add external libraries. Which is the polite version of the problem in the next section.

The four dependencies that do not come with the code

Spark's pitch was that data storage, AI features, authentication and deployment were built in. The export gives you the application code. It does not give you the four services that code talks to.

Spark capability	What ran it	What you now own
Managed data store	Azure Cosmos DB key-value store, 512 KB per entry, provisioned automatically	Choose and provision a database; migrate existing records
Authentication	Sign-in with a GitHub account, built in	Wire your own identity provider or GitHub OAuth app
Hosting and runtime	Azure Container Apps, one-click deploy	Pick a host; build a deployment pipeline
AI inference	GitHub Models via llm()	Bring your own provider and API key; you now pay for tokens
Development environment	GitHub Codespaces, synced to the spark	Local toolchain or your own Codespaces config

The data store deserves the most attention because it is the one people forget until launch day. By default a published spark's key-value store is shared across all users of that app, which is a design that makes sense for a prototype and none at all for anything holding customer records. If you are rebuilding, that is the moment to introduce per-user isolation rather than porting the shared-store behaviour into your new database.

The 512 KB per-entry ceiling is also a useful design constraint to carry forward. Anything already close to it in Spark was being stored in the wrong shape, and a rebuild is the cheapest time to fix it.

llm() is already broken, and replacing it is a billing decision

GitHub's own guidance is blunt: if your app uses llm(), replace it with your own inference provider to keep AI features working, and you will need to supply your own API key and manage billing, because GitHub will not provide the underlying model or tokens any longer.

Check first. Not every spark uses inference. Open the app in Spark and search the code for llm(). No matches means the GitHub Models retirement did not affect you at all, and your only decision is whether to export the source before 31 August. Matches mean the feature has been failing since 30 July 2026.

The replacement is a normal API call, and the price depends entirely on which tier of model the feature actually needed. Standard OpenAI rates, per million tokens, read on 5 August 2026:

Model	Input	Cached input	Output	Sensible use
gpt-5.6-luna	$0.20	$0.02	$1.20	Tagging, classification, short summaries
gpt-5.6-terra	$2.00	$0.20	$12.00	Longer generation, light reasoning
gpt-5.6-sol	$5.00	$0.50	$30.00	Complex reasoning only
gpt-4o-mini	$0.15	$0.075	$0.60	Legacy cost floor
text-embedding-3-small	$0.02	Not applicable	Not applicable	Search and similarity features

Most Spark llm() calls were doing what the docs describe: summarising text or suggesting image tags. That is a gpt-5.6-luna workload, not a flagship one. An app making 50,000 such calls a month at roughly 800 input and 200 output tokens each lands around $20 a month at Luna rates, about ₹1,740. Batch pricing halves the token rates again if the feature can tolerate delay. The cost is not the problem. The API-key handling, rate-limit behaviour and error paths that Spark used to hide from you are.

GitHub's own suggested destinations are Microsoft Foundry for a broad model catalog, or GitHub Copilot for AI workflows that live on GitHub rather than inside your app. Neither is a drop-in for llm(); both are a new integration.

The shape of the replacement

Spark's llm() ran server-side inside GitHub's runtime, so the app code never held a credential. The moment you replace it, the key becomes yours to protect, and that changes the architecture more than the call signature does. A browser-side call with the key embedded in the bundle is the failure mode to avoid, and it is the easy mistake when the original function needed no key at all.

Put the call behind a small server route instead:

// server-side only. The key never reaches the browser bundle.
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export async function summarise(text: string): Promise<string> {
  const r = await client.responses.create({
    model: "gpt-5.6-luna",
    input: [
      { role: "system", content: "Summarise in at most three sentences." },
      { role: "user", content: text },
    ],
    max_output_tokens: 300,
  });
  return r.output_text;
}

Three things Spark used to handle that this snippet does not. Rate limiting: the original had GitHub's quota in front of it, and your replacement needs its own per-user throttle or one enthusiastic user will spend your monthly budget in an afternoon. Failure handling: llm() returning an error was rare enough to ignore, while a provider API will time out, and the UI needs a path for that. And the system prompts themselves: Spark let you edit the prompts controlling each AI capability, so read them out of the exported code before you rewrite anything, because they encode behaviour your users are already used to.

Set max_output_tokens deliberately rather than leaving it open. On gpt-5.6-luna output tokens cost six times input tokens, so an unbounded response is where a $20 monthly bill becomes a $200 one.

Do you actually have to do anything?

Three situations, three answers.

Your situation	Deadline	What to do
Deployed app, no llm() calls, no plans to change it	None	Nothing. The app keeps running after the shutdown
Deployed app, no llm() calls, may want to edit later	31 August 2026	Export the code. It costs one click and preserves the option
App uses llm()	Already past	The feature broke on 30 July 2026. Export, then wire a provider
Spark was your prototype for something real	31 August 2026	Export now, then plan a rebuild against services you control

The second row is the one most teams should act on and most will not, because nothing is visibly broken. An app that runs today but whose source you cannot retrieve after 31 August is a liability with no alarm attached to it. The click is free. Take it.

A 26-day plan

Days 1 to 2. Inventory. List every spark in the organisation, not just the ones you remember. Sparks were shareable by link and undiscoverable otherwise, so the ones that matter are often owned by whoever prototyped them and never handed them over. For each, record: is it deployed, does it call llm(), does it hold real data, and does anyone still use it.

Days 1 to 2, in parallel. Export everything. Create the repository for every spark on the list, including the ones you expect to kill. A private repository costs nothing and the two-way sync keeps it current until the shutdown. Decide later.

Days 3 to 7. Triage. Most sparks are dead prototypes. Archive their repositories and move on. The survivors split into two groups: apps that are fine as they are and simply keep running, and apps that need to become real software.

Days 7 to 21. Rebuild the survivors. Four workstreams, roughly in this order: replace the data store and migrate records out of the Spark key-value store; replace GitHub-account sign-in with your identity provider; stand up hosting and a deployment pipeline; wire an inference provider and put the API key in a secret manager rather than an environment variable in a dashboard. Teams that have done a prototype-to-production conversion before will recognise the shape from our no-code to production app rebuild practice, and the sequencing is the same here.

Days 21 to 26. Verify and cut over. Test with real data volumes, not the demo record set. Confirm the new auth path handles the users who had access to the shared spark. Then point people at the new deployment.

After 31 August. Delete nothing you have not verified. The source is gone from Spark; your repository is the only copy.

The pattern worth noticing

Two retirements inside a week, one of them of a service the other one depended on, is not an accident of scheduling. It is what building on a preview platform looks like when the vendor's strategy moves.

The sequence is legible in the changelog. GitHub Models closed to new customers on 16 June 2026, announced full retirement on 1 July, and went dark on 30 July, taking the playground, model catalog, inference API and bring-your-own-key with it for every customer including those with active usage. Five days later Spark, which was "natively integrated with GitHub Models" per GitHub's own documentation, stopped accepting new users. The dependency retired first. The product built on it followed.

The engineering judgement here is not "avoid vendor platforms". It is narrower: keep the parts of your app that are expensive to rebuild out of any layer you cannot export. Business logic, data schemas and prompts should live somewhere you can git clone. Auth, hosting and inference are commodities you can swap in a week. Spark inverted that, and the export button is the receipt.

The same reasoning applies to any platform migration that starts with a changelog entry rather than a plan. If GitHub's own tooling is where your estate lives, the GitLab to GitHub Enterprise Importer guide covers the other half of that story, and teams already re-planning inference spend after the July repricing will find the GPT-5.6 price cut and Fast mode migration notes useful when choosing a replacement for llm().

India-specific considerations

Where the data sits. Sparks were deployed to Azure Container Apps and their key-value store ran on Azure Cosmos DB. If your app holds personal data and you are subject to the Digital Personal Data Protection Act 2023, the rebuild is the moment to place the replacement database in an India region deliberately, rather than inheriting whatever region the managed store happened to use. Record the change in your processing records.

The shared-store problem is a DPDP problem. A published spark's data store is shared by default across all users of the app. Any spark that collected customer names, phone numbers or email addresses under that default needs a data audit before, not after, migration. Export the records, check what is in them, and decide what should be carried forward and what should be deleted.

Billing in rupees. Once llm() is replaced, someone owns an API key with a card attached. At 87 to the dollar, gpt-5.6-luna's $0.20 per million input tokens is about ₹18, which is cheap enough that nobody notices the spend and nobody sets a limit. Set a hard monthly cap on the provider account on day one, and route it through a company payment method rather than a developer's personal card.

Team handover. Sparks were created under personal GitHub accounts and shared by link. Before anyone leaves the project, move the exported repository into an organisation. Repositories created by the export land under a personal account by default.

FAQ

Will my deployed Spark app stop working on 31 August 2026?

No. GitHub states that apps already deployed continue to work after Spark is retired. What stops on 31 August is your ability to export app code from the Spark workbench. If the app calls llm(), that specific feature already stopped on 30 July 2026 when GitHub Models retired.

How do I export my Spark app before the deadline?

Open the Spark workbench for your app, select the ... menu, then select Create repository and confirm. GitHub creates a private repository under your personal account, named after the spark, containing the full commit history from the spark's creation. A two-way sync then keeps the repository and the spark in step until the shutdown.

How do I tell whether the GitHub Models retirement affected my app?

Open the app in Spark and search the code for llm(). If there are no matches, no action is needed for the inference retirement. If there are matches, those calls stopped working on 30 July 2026 and you need to replace them with an inference provider of your own, supplying your own API key and managing the billing.

What does replacing llm() cost?

It depends on the model tier the feature needs. On standard OpenAI rates read on 5 August 2026, gpt-5.6-luna is $0.20 per million input tokens and $1.20 per million output, gpt-5.6-terra is $2.00 and $12.00, and gpt-5.6-sol is $5.00 and $30.00. Summarising and tagging workloads sit comfortably at Luna rates.

Can I keep running the app exactly as it is after exporting?

Not off GitHub's infrastructure. The exported React and TypeScript source still depends on Spark's managed key-value store on Azure Cosmos DB, GitHub-account authentication and Azure Container Apps hosting. Running it elsewhere means replacing all three. The deployed spark itself, however, keeps working on GitHub's runtime.

Why did GitHub retire Spark?

GitHub's stated reason is that AI models and agentic development tools have advanced since Spark launched, and builders can now build and refine the same experiences through GitHub Copilot in the environments they already use, including VS Code, Copilot CLI and the GitHub Copilot app. GitHub says it has seen builders increasingly choose those integrated workflows.

What replaces GitHub Models for inference?

GitHub points to Microsoft Foundry for a broad model catalog, and to GitHub Copilot for AI workflows built directly on GitHub. Neither is a drop-in replacement for the llm() function: both require a new integration, your own credentials, and your own billing arrangement going forward.

How much data can the Spark key-value store hold per record?

Spark's managed data store runs on Azure Cosmos DB and is intended for small records, up to 512 KB per entry. Anything approaching that ceiling was probably stored in the wrong shape, and a migration is the right moment to move large objects to blob storage and keep references in the database instead.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy, CMMI Level 5 and ISO 27001:2022 certified, with senior engineering teams that turn prototypes into production software: replacing managed stores with databases you own, wiring real authentication, standing up deployment pipelines, and integrating inference with proper key management and spend caps. We design applications aligned with DPDP requirements, including deliberate data residency choices rather than inherited ones. If you have sparks worth keeping and 26 days to act, talk to us about a rebuild plan.

References

1. GitHub Changelog, Upcoming deprecation of GitHub Spark on github.com, 4 August 2026.
2. GitHub Changelog, GitHub Models is now retired, 30 July 2026.
3. GitHub Changelog, GitHub Models is being fully retired on July 30, 2026, 1 July 2026.
4. GitHub Changelog, GitHub Models is no longer available to new customers, 16 June 2026.
5. GitHub Docs, About GitHub Spark.
6. GitHub Docs, Building and deploying AI-powered apps with GitHub Spark.
7. GitHub, GitHub Spark product page.
8. OpenAI, API pricing, read 5 August 2026.
9. Microsoft, Microsoft Foundry.
10. GitHub Community, Spark deprecation discussion.
11. GitHub Docs, What are GitHub Codespaces?
12. GitHub Changelog, Migrate from GitLab to GitHub with GitHub Enterprise Importer, 3 August 2026.

Last updated: 5 August 2026.