Google Is Killing Jules: Export Before November 11, 2026

The short answer: you have 12 days of real work left, not two months

Google announced on October 29, 2026 that Jules, its asynchronous AI coding agent, will wind down on December 31, 2026, with its learnings folded into Antigravity, Google’s agent-first development platform. That December date is the one most headlines carry. It’s also the least useful date in the announcement.

The date that actually controls your plans is November 11, 2026. That’s when Jules goes read-only. After that, you can look at your sessions but you can’t keep working in them. So if you have background tasks still running in Jules, you don’t have two months — you have until November 11 to finish them, and you should export everything well before that, not on the last evening. Google gives no time of day for either cutoff, so treat November 10 as your personal deadline and keep November 11 as buffer.

This article is the migration guide I wish had shipped with the announcement: what to export, in what order, what Antigravity’s new plugin marketplace does and doesn’t replace, what’s still missing with no date attached, and the decision framework for staying with Google versus moving to another coding agent entirely. If Jules is part of your daily workflow, start this week. If it’s a side tool you tried once, the export still takes less than an hour and saves you from reconstructing setup scripts from memory later.

What Jules was, and why its shutdown stings more than a normal product closure

Google launched Jules in December 2024 as an experimental coding agent for what it called the tasks developers “don’t want to do”: bug fixes, dependency updates, feature requests, and test-writing, run asynchronously against your GitHub repositories. The key word is asynchronous. Unlike a chatbot that answers while you watch, or an in-editor assistant that suggests code as you type, Jules worked in the background: you assigned a task, walked away, and came back to a pull request.

That background model is exactly what made Jules different from Antigravity, and it’s why the shutdown lands harder than a simple rebrand. Antigravity, launched in November 2025 and now at version 2.0 after Google I/O 2026, is an agent-first development environment: agents plan tasks, make changes, run commands, and check their own work inside a workspace you’re actively using. It’s powerful, but it’s a different shape of tool. A developer who relied on Jules to chew through a backlog overnight — twenty dependency bumps, a sweep of failing tests — doesn’t automatically get that workflow back by opening Antigravity. Google says it is “working on bringing our learnings from Jules into Antigravity so you get the best of both worlds: autonomous remote background task execution and an agent-first development environment.” That sentence promises the combination. It gives no date for when background execution arrives in Antigravity, and no commitment that every Jules feature carries over one-for-one.

The community reaction, as collected the day of the announcement, was more resigned than angry — the familiar “Killed by Google” jokes, some nostalgia for Jules’s branding, and a set of very specific asks. As one user quoted in the reaction roundup put it, “jules goes read-only on nov 11 even though the shutdown date is dec 31,” so “anyone with background tasks still running there has 12 days, not two months.” Another summed up the notice period bluntly: “Like damn not even 2 weeks’ notice.” And one developer nailed the deeper workflow problem with async agents generally: “async background agents were the right bet. the part nobody solved was the review queue, an agent that opens 20 prs overnight just moves the bottleneck to you in the morning.” That last point is worth sitting with, because it shapes the migration advice below: the goal isn’t to replace Jules with another firehose of pull requests. It’s to rebuild a reviewable workflow. Google Jules shutdown reactions

The timeline, stated plainly

Three practical consequences follow. First, anything you haven’t finished by November 11 stays unfinished in Jules; you’ll complete it elsewhere. Second, anything you haven’t exported by December 31 is gone with the service, so export early even if you plan to keep reading sessions in the read-only window. Third, because Google states no time of day for the cutoffs, don’t schedule your export for the evening of November 10 and assume you’re safe — do it days early.

One reassuring fact: your code itself is safe. Jules worked against your GitHub repositories, so your code, branches, and pull requests already live on GitHub and stay there regardless of what happens to Jules. What you’re protecting with an export is everything around the code: the configuration and memory that made Jules useful for your specific projects.

Your export checklist: do this before November 11

Google’s export saves your Jules data to a local folder. Work through it in this order — the order matters because the early items are the ones you’ll need first when rebuilding elsewhere, and the last item is a security step people skip.

1. Finish or close active sessions first

Go through every active session and decide: finish it, merge its pull request, or close it deliberately. A session left half-finished in Jules becomes a half-finished task you have to reconstruct from a pull request diff somewhere else. If a session’s pull request is good, merge it now while you still can. If it’s not, close it and note what was wrong — that note is more useful than the abandoned branch.

2. Export settings and environment variables

This is the highest-value item in the export. Your Jules settings and environment variables encode how your projects were configured: which repos were connected, what setup was assumed, what credentials and endpoints your tasks relied on. Save the export folder somewhere durable — not just your laptop’s Downloads folder — and treat it as sensitive from the first second (see step 6).

3. Export scheduled tasks

If Jules was running recurring work — weekly dependency sweeps, scheduled test runs, regular backlog passes — your scheduled tasks list is your migration spec. Each scheduled task becomes a line item in the “rebuild this elsewhere” list below. Don’t just save the list; annotate each one with what it was for and how often it actually produced something worth merging. The tasks with a low merge rate are candidates to drop, not to migrate.

4. Export memories, setup scripts, and session history

Memories and setup scripts are the quiet knowledge Jules accumulated about your projects: conventions, preferences, environment setup steps. Session history is your audit trail — what was attempted, what succeeded, what failed and why. Even if you never read the full history again, it answers the question “did we already try this?” six months from now. Keep it with the export folder, not scattered across screenshots.

5. Verify the export before you trust it

Open the exported folder and check that each category actually has content: settings present, environment variables present, scheduled tasks listed, session history readable. An export you never opened is a backup you never tested. If anything is missing or empty, re-run the export while Jules is still fully working — after November 11, your options narrow to read-only access.

6. Lock the export folder down, then rotate secrets

Here’s the security step that matters most, and the one most likely to be skipped. The export includes environment variable values — which means it can contain API keys, tokens, and other secrets your Jules tasks used. Treat the folder like a password vault: store it encrypted or in a private location, never commit it to a repository, never drop it in a shared drive, and never paste it into a chat or support ticket. Then rotate any secrets it contains that were ever used in Jules, because a secret that lived in a third-party agent’s environment should be treated as exposed once that environment is being decommissioned. Rotating now is cheap; discovering a leaked key later is not.

What Antigravity’s plugin marketplace actually gives you

On the same day as the Jules shutdown notice, Google launched a Plugin Marketplace for Antigravity — a central directory for finding and installing Google-built and third-party plugins in the Antigravity App and CLI, rolling out to both. Google’s own announcement is here: Plugin Marketplace in Antigravity. Plugins cover skills, MCP servers, rules, hooks, and custom agents, and the launch lineup includes Stripe, Vercel, Notion, Linear, Supabase, and Zapier alongside Google’s own Docs, Sheets, Drive, and Firebase plugins.

For a Jules migrant, the marketplace matters in a specific way: it answers the question “can Antigravity talk to my stack?” If your Jules workflows touched Vercel deploys, Linear issues, Notion docs, or Supabase databases, there’s now a one-click plugin path in Antigravity for that connection. That’s genuinely useful, and it’s the strongest concrete reason to try Antigravity first before shopping elsewhere.

But the marketplace does not answer the question that matters most to Jules users, which is “can Antigravity run my tasks in the background while I’m away?” Plugins extend what an agent can do; they don’t by themselves create Jules-style autonomous remote execution. Google says that capability is coming to Antigravity as part of the unification, but it has given no date. Until it arrives, an Antigravity workflow still assumes you’re present in the environment, directing agents — a different working pattern from assigning a task and returning to a finished pull request.

Jules feature → Antigravity status: the honest table

Read that table as a migration plan, not a verdict. Antigravity is the natural first stop, especially if your team already lives in Google’s ecosystem. But “natural first stop” is not “complete replacement,” and the gaps — background execution, scheduling, and the free tier — are exactly the features that made Jules worth using for many people.

Your migration plan, week by week

This week (by November 2): Run the full export and verify it. Merge or close every active Jules session you care about. List your scheduled tasks and mark each one keep, drop, or rebuild. Install Antigravity and connect the plugins for the tools your workflows actually touch.

November 3–10: Rebuild your top three recurring workflows somewhere durable. For each one, decide: does it live in Antigravity as supervised agent work, does it move to a CI pipeline or scheduled script, or does it move to another coding agent that already offers background execution? Test each rebuilt workflow end-to-end before November 11 — a workflow you haven’t run is a workflow you haven’t migrated.

November 11–December 31: Jules is read-only. Use this window only for reference: checking old session history, confirming an export detail, retrieving something you missed. Don’t plan new work in Jules during this window, and don’t leave your only copy of anything in a read-only service heading for shutdown.

After December 31: Jules is gone. Your export folder, your GitHub repos, and your rebuilt workflows are what remain. If you rotated secrets during the export step, confirm the new credentials work in the rebuilt workflows — a rotated key that breaks a scheduled job on January 2 is a migration bug, not a security win.

And one workflow-design lesson worth carrying out of this shutdown, drawn from that developer quote about the review queue: when you rebuild, build the review step first. An agent that opens twenty pull requests overnight doesn’t save you twenty reviews — it moves the bottleneck to your morning. Cap concurrent agent tasks, require small pull requests, and set a rule that nothing merges without a human look, even if the agent’s track record is good. The teams that get the most from coding agents aren’t the ones that generate the most code; they’re the ones whose review queue stays empty.

Should you stay with Google, or move to another agent?

This is the decision the shutdown forces, and the honest answer depends on what you actually used Jules for:

Stay with Antigravity if: your work is mostly supervised, in-editor agent coding; your stack is covered by the new plugin marketplace; and you can wait — with no promised date — for background execution to arrive. You’re betting that Google’s unified platform is worth a transitional gap.

Move to another coding agent if: background, unattended execution is the core of your workflow (overnight backlog sweeps, scheduled dependency work); you relied on Jules’s free tier of 15 tasks a day and can’t justify a paid replacement on Google’s terms; or you need scheduling guarantees today, not a roadmap promise. In that case, evaluate alternatives on three criteria only: does it run tasks without you present, does it open pull requests against your repos, and does it let you export your configuration the way Jules’s export does? For a sense of what a cloud-subagent coding setup looks like in practice, see Cursor projects and cloud subagents. A tool that fails the third test is a tool you’ll migrate away from painfully next time.

Do both, temporarily, if: you’re a team with mixed needs. Run supervised work in Antigravity now, keep background work on an alternative until Antigravity’s background story has a date, and revisit the split quarterly. Temporary dual-tooling is annoying, but it’s cheaper than rebuilding twice because you guessed wrong about a roadmap.

There’s a broader lesson here that applies beyond Jules, and it’s one this site has covered before in the context of other Google and platform shutdowns: build workflows on top of platforms and open standards, not on a single product’s quirks. Keep your task definitions in version control, your secrets in a vault you control, and your review process independent of any one agent. Products get wound down — Jules launched in December 2024 and is gone before the end of 2026 — but a workflow written down survives the product. If you take one habit out of this shutdown, make it that one. For the parallel lesson from another vendor’s deprecation, see our guide to migrating off a retiring API before its deadline. OpenAI GPT-4o and GPT-4.1 API shutdown migration

Frequently Asked Questions

When exactly does Google Jules shut down?

Google announced on October 29, 2026 that Jules winds down on December 31, 2026. But the practical deadline is earlier: Jules becomes read-only on November 11, 2026, after which you can view sessions but can’t keep working in them. Finish active sessions and export your data before November 11.

What can I export from Jules before it shuts down?

Google’s export saves your settings, environment variables, scheduled tasks, repository connections, memories, setup scripts, and session history to a local folder. Your code, branches, and pull requests are already safe on GitHub and don’t need exporting. Verify the export folder has real content in each category — don’t assume it worked.

Is my code safe when Jules shuts down?

Yes. Jules worked against your GitHub repositories, so your code, branches, and pull requests remain on GitHub after Jules winds down. What you lose without an export is the configuration around that code: settings, environment variables, scheduled tasks, memories, and session history.

Does Antigravity fully replace Jules?

Not yet, on the evidence available. Antigravity is an agent-first development environment with a new Plugin Marketplace (Stripe, Vercel, Notion, Linear, Supabase, Zapier, plus Google’s Docs, Sheets, Drive, and Firebase plugins), but Google has given no date for Jules-style autonomous background task execution inside Antigravity, and Jules’s free tier (15 tasks a day, 3 concurrent) has no announced equivalent. Try Antigravity first, but plan around those gaps.

What should I do with the secrets in my Jules export?

Treat the export folder as sensitive immediately: it contains environment variable values, which may include API keys and tokens. Store it privately and encrypted, never commit it to a repository or shared drive, and rotate any secrets it contains that were used in Jules. A secret that lived in a decommissioned agent environment should be treated as exposed.

What if I only tried Jules once and barely used it?

Export anyway — it takes less than an hour and saves you from reconstructing setup scripts later. Then close or ignore the account. The cost of exporting a tool you barely used is tiny; the cost of discovering later that it held your only copy of a working configuration is not.