11 November is the real deadline: Google Jules shuts down on 31 December, code stays on GitHub, memories and scheduled tasks must be exported by you

Some products die because nobody uses them. Others die because a company consolidates its roadmap. Google's asynchronous coding agent Jules belongs to the second group, and it has given its users very little time. On 29 October 2026, the official Jules changelog published a notice titled Jules Turndown: as part of Google's work to unify its agentic coding efforts, Jules will wind down on 31 December 2026. Users may keep finishing sessions until 11 November 2026; after that, Jules becomes read-only until the end of the year.

If you remember only 31 December, this article is here to correct you. The date that actually controls your plan is 11 November. After that you can look, but you cannot work. More importantly, Google has not promised to move everything from Jules into a new product. It has promised an export, not a migration. Code already lives on GitHub, so it is safe; but the configuration, scheduled tasks, memories, and session history that live inside Jules will stay inside a closing product unless you take them out before read-only mode begins.

Two dates, and only one of them lets you work

The shutdown timetable has only three lines, and each must be read correctly. The first is 29 October 2026, the announcement date, from which the countdown runs. The second is 11 November 2026, the last day on which sessions can still be finished; the notice says users may continue finishing sessions until that date. The third is 31 December 2026, the final shutdown, with the period after 11 November spent in read-only mode.

Read-only means what it sounds like: you can view, but you cannot push a session forward. For a long task still running, that is decisive. If your Jules session is unfinished on 12 November, you cannot expect it to keep editing code and opening pull requests during the read-only period. All you can do is read it and redo the work elsewhere. Anyone treating 31 December as the deadline will discover on 12 November that the chance to act has already gone.

The notice gives no time of day for either cut-off. Is 11 November measured from midnight, or through the end of the day, and in which time zone? None of that is stated. The safe approach is to treat 10 November as your own last working day and keep 11 November as buffer, not as a sprint. The same applies to exports: do not leave them until December. The read-only period may still let you look, but what you really need is to take your data out while the product still works, and to verify that the exported files are usable.

One more gap is worth noting: the notice says nothing about refunds, and nothing about what happens to Jules task limits inside Google AI Pro and Ultra plans. If you used Jules partly because of those plan limits, those questions currently have no answer. Do not invent one. Note them, ask through official channels, or budget on the assumption that there will be no compensation.

What Jules was, and why its ending deserves an obituary

In Google's own words, Jules began as an experiment to learn how asynchronous coding agents could help developers clear backlogs and ship faster. It worked differently from an agent that sits beside you in an editor and writes code in real time. You gave it a prompt, or assigned it a GitHub issue, and it worked on its own in a cloud virtual machine, eventually handing back its result as a branch and a pull request. You did not need to watch it in between, which made it suitable for work you did not want to do but still had to do: fixing bugs, upgrading dependencies, adding tests, and handling small feature requests.

The value of that asynchronous mode lay precisely in not demanding your attention. A real-time agent asks you to sit at the screen and watch each change; Jules asked you to hand over a task and return later to review it. For teams and solo developers with long backlogs, that difference is large. That is also why this shutdown is more than a minor product adjustment: it closes a way of working, not just an entry point.

The notice says what Jules taught Google is now shaping products across the company, including the agent-first platform Antigravity. That sentence needs to be split in two. The first half is a statement of fact: an experiment completed its learning mission. The second half is a direction, not a promise. It does not say Antigravity already has all of Jules' capabilities, nor when remote background execution will be available there. Equating lessons learned with a ready replacement is the easiest misreading of this announcement.

What survives, and what you must move yourself

Start with the part that needs no panic. The notice is explicit: your code, branches, and pull requests already live on GitHub, so they stay where they are. Shutting down Jules will not take your repositories away or revoke merged pull requests. That part of your work is safe, needs no export, and needs no rescue.

Now the part that needs action. The notice lists what you can export into a local folder: account settings, environment variables, scheduled tasks, connected repositories, memories, setup scripts, and every session, including its prompt, plan, full activity log, and code patches. All of these live only inside Jules; GitHub does not hold them. Scheduled tasks deserve special attention: they are not code, they are arrangements for Jules to do things on a schedule. Memories are not code either; they are the context Jules accumulated about your projects and preferences. Losing them means losing the context you spent time teaching the agent.

The export method is also in the notice: install Jules Tools with npm install -g @google/jules, sign in with jules login, then open a command-line coding agent from your home directory, such as Claude Code, and paste in the export prompt provided in the notice. That agent checks your setup, runs the export, and reports what it saved and where. Results land in ~/jules-export: one folder per repository with its setup script, test command, and memories; one folder per session with a readable summary.md, the full activity log, and its diffs.

One detail is worth pausing on: Google's own export guide names Claude Code, a rival product from Anthropic, as its example command-line agent. The wording is such as Claude Code, not only Claude Code, but it is the only example named. A Google product asking users in its farewell note to bring in a competitor's agent to help move house says something about the reality of the moment: export was not built as a one-click button; it needs an agent beside you that can read a prompt and run a script. For users, that is not gossip but a warning: test the export process, and do not assume one paste will finish the job.

Three traps in the export

The first trap is secrets. The export folder contains env-variables.json, which holds the values of your environment variables. The notice warns at the end to keep the export folder private and out of your repositories. Many people's first instinct after exporting is to commit the whole folder to Git as a backup; that is exactly the most dangerous move. Keep it in a local encrypted location or in private storage you trust, and after exporting, check that no secret has been pasted into chat logs, tickets, or public repositories.

The second trap is the GitHub connection. The notice says that if you use Jules with GitHub, you should make sure your GitHub account is connected first, or the export will not include repository data. The export script checks this itself, but it can only tell you something is missing; it cannot fill the gap for you. The correct order is: confirm the connection, run the export, then count the exported repositories and sessions against what you see in Jules, and only then call it done.

The third trap is login expiry. The export script's own notes say the Jules CLI login stores a token that expires about an hour after login, and that repeated 401 errors mean you should run jules login again or run any jules command to refresh it. Anyone exporting many sessions is likely to hit expiry halfway through. That is not user error; it is documented behaviour. On a 401, re-login and continue, rather than pasting the same prompt repeatedly, and never paste a token from an error message into a public channel.

There is a subtler trap too: some of the endpoints the export script uses are not publicly documented. The script's comments admit that if a call starts returning 404 or 400, the user should be told which call failed rather than guessing at fixes. That means the export process is somewhat fragile, and the later you run it, the higher the risk. Running it while the product still works normally and its interfaces have not changed is the safest choice.

Can Antigravity actually take over?

Google points Jules users toward Antigravity, an agent-first development environment. The notice describes the goal as combining autonomous remote background task execution with an agent-first development environment, so users get the best of both worlds. That vision sounds like Jules plus an editor combined, but a vision is not the current state. The notice gives no date for remote background execution inside Antigravity and no method for importing Jules data into it. Exporting to a local folder and importing into Antigravity are two entirely different things; the first exists, the second does not yet.

On the same day, Antigravity also launched a plugin marketplace, a directory for one-click installation of Google-built and third-party plugins covering skills, MCP servers, rules, hooks, and custom agents, with launch partners including Stripe, Vercel, Notion, Linear, Supabase, and Zapier alongside Google's own Docs, Sheets, Drive, and Firebase plugins. That news should be kept separate from the Jules shutdown: a plugin marketplace makes Antigravity a more extensible workbench, but it does not answer the question Jules users care about most, namely where their cloud-running asynchronous tasks will run next and how. Treating the marketplace as a Jules replacement confuses two different things.

For anyone choosing a migration destination, the honest conclusion is that there is currently no officially designated drop-in replacement. Antigravity is the direction Google names, but its remote background capability has no timetable; other vendors' asynchronous agents each have their own onboarding and pricing, and none can directly consume a Jules export folder. Migration should therefore run in order: first, secure the assets, with code already safe on GitHub and configuration, memories, and session history exported locally and verified; second, reassess what your tasks actually need, asynchronous background execution or work that an in-editor agent can do; third, decide whether to wait for Antigravity or bridge with another tool. That order must not be reversed.

Boundary: this is not the Code Assist sunset story

This site previously covered a related Google consolidation story: the end of Gemini Code Assist subscription sales and the move to Antigravity. That story and this one are easy to confuse, but they are different events. Code Assist was a subscription coding assistant service, and its sunset concerned ending new subscription sales. Jules is a standalone asynchronous agent product, and its shutdown means the service itself ends on 31 December 2026. What they share is a direction, the concentration of scattered agentic coding capabilities into Antigravity; what differs is the impact and the timetable, and neither can substitute for the other.

Read together, the two stories make Google's direction clearer: instead of maintaining a separate product for every scenario, it is concentrating capabilities into one agent-first platform. Concentration has benefits, lower maintenance cost and a more unified experience, and it has a cost, forcing users to migrate, with experiment-product users especially likely to bear that cost. Jules users are bearing it in this round. Understanding that matters more than memorising two dates, because it suggests similar consolidations may follow.

Scheduled tasks and memories are the easiest things to lose

Code cannot be lost in this shutdown, but scheduled tasks and memories can, precisely because they do not look like assets. A scheduled task is something you asked Jules to do regularly, such as checking dependency updates each morning, cleaning up stale branches each week, or running a test coverage report each month. When such a task stops, nothing errors immediately; it simply stops happening quietly. Discovering months later that a routine check has been dead for a while often means the damage is already done. After exporting, the first job is not to store the files but to copy out the scheduled-task list, item by item, and decide for each one whether it should continue, where it should run, and with what tool.

Memories work the same way. Jules' memories may include your project structure preferences, writing styles you dislike, checks you ask it to run every time, and deployment notes specific to one repository. None of that appears in code, yet it shapes the quality of the agent's work. The exported memories.json and memories.md are worth reading through, and the genuinely important entries should be rewritten into the next tool's rule files, such as a project's AGENTS.md or custom instructions. Dumping the whole memory file unchanged into a new tool usually works poorly, because the new tool's prompt structure differs from Jules'; picking the most important rules and rewriting them for the new tool is what makes migration effective.

Session history needs case-by-case judgement. For sessions whose pull requests are already merged, the history is mainly a record; keeping it is enough. For sessions still open or under discussion, the history is highly valuable, because it contains the back-and-forth reasons for each change. For those, verify that summary.md and the diff files are complete, and save the prompt and plan separately. After the read-only period, those discussions can only be reconstructed from the export files; if the files are incomplete, the discussion is effectively lost.

Verdict: the shutdown is not scary; mistaking export for migration is

The shutdown itself is not surprising. Experiment products exist to validate a direction, and once the direction is validated, consolidation is a normal outcome. What deserves vigilance is mistaking the official export for a completed migration. Export only takes things out of Jules' database and puts them on your disk; migration means making those things useful again in the next tool. One step in between is still missing, and no official tool currently walks it for you.

A checklist for Jules users can be kept short. First, before 10 November, finish or explicitly abandon every session you still want to continue; do not leave them for the read-only period. Second, confirm the GitHub connection, run the export, count repositories and sessions, and verify that summary.md and diff files open. Third, treat the secrets in the export folder as production secrets and keep them out of repositories. Fourth, reassess your task types: which truly need asynchronous background execution, and which can be done inside an editor. Fifth, decide whether to wait for Antigravity's remote background capability or bridge with another tool, and write that decision down instead of drifting.

For developers who never used Jules, there is a general lesson too: before adopting any agent that locks your working memory, scheduled tasks, and configuration inside the product, ask what an export looks like. Jules at least provided an export tool and two months of time; many products do not even offer that. When choosing tools, export capability is not a bonus; it is a baseline. Discovering only at shutdown time that your memories and tasks cannot be moved is far too late.