Google Jules Alternative: What to Use After the Shutdown

Google is closing Jules. A changelog entry dated 29 October 2026 says Jules will wind down on 31 December 2026, that users had until 11 November 2026 to finish their sessions, and that Jules would then stay read-only until the end of the year. For any team that had put Jules on its backlog, the question has moved from whether to use it to what replaces it, and the deadline is fixed.

A migration is easy to frame as a comparison of models and context windows. This guide asks a different question, because Jules was built around a particular idea of control. Jules asked a person to approve a plan before it wrote any code, then handed back a diff, a branch and a pull request. Approval sat at the start. What sat at the end was a review in GitHub, outside Jules, not a decision that Jules itself recorded. A replacement is a chance to keep the good half of that design and fix the other half.

This post holds one altitude: what a team leaving Jules should keep from plan approval, what it should add at the end of the task, and how to migrate before 31 December 2026. It cedes the merge-to-Done path on GitHub to our GitHub Copilot coding agent comparison, the session model of a hosted agent to our Devin alternative guide, rules and hooks to our Cursor Cloud Agents comparison, and sandbox design to our cloud agent isolation guide. The reader we have in mind is an engineering lead or VP Engineering who has to sign off agent work for people outside the repository.

This guide is shipped by the team behind Cognibl, from DILR.AI, a work tracker where people and cloud AI agents share one board and no task reaches done without proof of work. Or see DATS, our five-stage method for placing AI inside enterprise delivery.

What happened to Google Jules, and what are the key dates?

Google Jules, the asynchronous coding agent from Google Labs, is being shut down. Google's changelog entry of 29 October 2026 says Jules will wind down on 31 December 2026. Users could keep finishing sessions until 11 November 2026, and after that date Jules became read-only until the end of the year. Code, branches and pull requests stay in GitHub; the configuration and session history inside Jules has to be exported.

The Jules turndown notice frames the product as an experiment in how asynchronous coding agents could help teams clear a backlog, and says the lessons are shaping products across Google, naming its agent-first platform, Google Antigravity. It does not describe a migration path into Antigravity for existing sessions, and this guide does not assume one.

Three dates matter for planning. The notice is dated 29 October 2026. Sessions could be finished only until 11 November 2026, and with Jules read-only since then, a team reading this in mid-November should treat any open Jules work as frozen and plan new work elsewhere. The service winds down on 31 December 2026. The notice does not promise that the export described below keeps working right up to that date, so the safe plan is to run it now. From mid-November that leaves a working window of about seven weeks at most.

The changelog also carries a scale reminder. Its entry of 6 August 2025 said Jules had passed more than 140k public commits in its first two months. Any of that work still in a team's repositories had its plans and activity logs inside Jules, and the engineering lead who has to explain that code to an auditor or a client later will want that history kept somewhere they control.

How did Jules decide what to build, and who approved it?

Jules decided what to build through a plan. Once a person submitted a task, Jules cloned the repository into a virtual machine, studied the code and proposed a step-by-step plan, which the person could review, question in chat and approve before any code changed. Approval was a real control, but it was not always exercised by a person: the web app could approve on a timer, and API sessions approved plans by default.

Google's documentation was candid about the timer. In its own words on the plan review page: "If you navigate away, Jules will eventually auto-approve the plan, which is set on a timer." The same page presented this as a convenience, so that nobody had to sit and watch the agent. For a solo developer that is reasonable. For a team where the person who approves the plan is meant to be accountable for the outcome, an approval that happens because nobody looked is not an approval at all.

The REST API went further. The Jules API quickstart says that, by default, sessions created through the API have their plans automatically approved, and that a caller who wants explicit approval has to set a field called requirePlanApproval to true. The API itself was labelled an alpha release. Any team that wired Jules into Slack, Linear or GitHub through the API should check whether requirePlanApproval was set, because without it those plans were approved automatically and no person had to read them.

Google did add a safeguard for exactly this case. On 26 January 2026 the changelog introduced a Planning Critic, a secondary agent that reviews every plan that does not require human intervention before Jules executes it, and reported a 9.5% reduction in task failure rates. That figure is Google's own, from its changelog, not an independent measurement, and it measures task failure rather than whether the delivered change met the team's definition of done. It is still a useful signal. Our reading is that Google treated unattended plan approval as a risk worth a second agent.

The earlier changes point the same way. On 8 August 2025 Jules gained Interactive Plan, which asked clarifying questions before settling a plan, and a Critic Agent, which put every proposed change through adversarial review before completion. Jules also read an AGENTS.md file in the repository root to make better plans. All of this effort went into the front of the task: getting the plan right, then checking the code against it as it was written.

What did Jules hand back when a task was finished?

Jules handed back a summary and a diff. When a task finished, the summary listed files changed, total runtime and lines added or removed, with an option to create a branch, after which the person became the branch owner and Jules appeared as the commit author by default. A pull request could follow, either opened by Jules or by the person, and any acceptance decision then happened in GitHub review.

The running tasks guide describes that hand-back. Labelling a GitHub issue jules would start a task, and when Jules finished it posted a link to the pull request on the issue. From February 2026 a CI Fixer let Jules detect a failed GitHub Actions check on its own pull request, fix it and resubmit, and a user-level commit authoring setting let each user credit commits to Jules, to themselves, or to both.

Notice what is missing from that list. Jules recorded its own task status, and the Jules FAQ says that when a task kept failing after automatic retries, Jules marked it failed and notified the user. But nothing in the Jules pages we reviewed recorded, inside Jules, that a named person had compared the result with what was asked and accepted it. The plan was approved at the start; the code was reviewed and merged in the pull request; the question of whether the task was finished, as the requester meant it, was left to GitHub review and to whatever the team did next on its own board.

Where pull request review did that job informally, the gap was easy to miss. It becomes visible in three situations: when the person who asked for the work is not a developer and never sees the pull request, when a scheduled or suggested task runs with nobody waiting for it, and when someone has to reconstruct months later why a change was considered complete. Our guide to coding agent artefacts covers how to weigh the evidence an agent leaves behind; the point here is narrower, that Jules itself stored no acceptance decision against the brief.

Those limits matter for migration planning. The Jules limits page set 15 daily tasks and 3 concurrent tasks on the entry plan, rising to 100 and 15 on Jules in Pro and 300 and 60 on Jules in Ultra. The same page said paid plans ran through a Google AI Plans subscription available only to individual accounts ending in @gmail.com, with business users pointed to an interest form, so some teams may have used Jules through personal accounts. That is worth checking before export, because those personal accounts hold the session history.

What does a Jules export keep, and what does it leave behind?

A Jules export keeps nearly everything that lived inside Jules. Google's turndown notice says it covers account settings, environment variables, scheduled tasks, connected repositories, memories, setup scripts and every session, including the prompt, the plan, the full activity log and the code patches. It leaves behind anything that never lived in Jules, which includes any recorded decision that a task's result was accepted against its brief.

The export runs through Jules Tools, Google's command line client, which is installed with npm and signed in with a jules login command, and the notice supplies a prompt for a CLI coding agent to run the export. Each session lands in its own folder with a readable summary, the activity log and its diffs. Each summary lists the session's status with its created and completed times, which records how the agent saw the task, not how the team did.

Two practical warnings come straight from the notice. The export file for environment variables contains their actual values, so the export folder has to be kept private and out of every repository. And if the GitHub account was not connected to Jules at export time, the export will not include repository data. A team should run the export once per person who used Jules, because the history sits in individual accounts. Where prompts or activity logs name customers or colleagues, the export holds personal data, and the copy needs the same UK GDPR handling as any other record that contains it.

The export is therefore a good audit archive and a poor work record. It can answer what the agent planned and what it changed. It cannot answer who decided the change was the one the business asked for, because Jules did not record that decision; at most, a pull request review in GitHub did. That is the half of the design a replacement should add, and it is the subject of our guide to agent work management, which sets out what a definition of done and a proof of done look like when agents do the work.

What should a Jules replacement keep, and what should it add?

A Jules replacement should keep the plan-first habit and add an evidence gate at the end. Keep a written plan that a named person approves before code changes, and make that approval deliberate rather than timed. Add a rule that the task cannot be marked done until the agent has attached evidence that the result meets the definition of done, and record who accepted it on the team's own board, separate from the agent.

That gives five criteria a team can apply to any candidate, whether Google Antigravity, the GitHub Copilot coding agent, Devin, Cursor, Codex or Claude Code. First, approval of the plan is explicit: no timer and no silent API default. Second, the brief and the definition of done live with the task, not only in the prompt. Third, the agent runs in its own isolated machine and cannot push to the base branch. Fourth, a run that ends without evidence produces a visible blocked task, not a quiet failure. Fifth, done is a status that only evidence can reach, for agents and people alike.

The first and third criteria are properties of the agent. The fourth and fifth belong to the work tracker rather than to the agent, which is why changing agents alone does not settle them. A coding agent can produce excellent evidence and still leave the done decision to a dropdown that anyone can change, whether the board is Jira, Asana or a spreadsheet. That is why our coding agent review queue guide separates the merge gate from the done gate, and why this guide treats the migration as a change to the board as much as a change of agent.

The same diagnostic logic underpins our AI developer productivity work, where the question is less which agent writes the code and more where review time and acceptance decisions go once agents write much of it.

How does Cognibl handle the end of an agent task?

Cognibl, from DILR.AI, handles the end of an agent task with a refusal. A task cannot reach a done status until a proof of work is attached, and the database refuses the move without one, for people and agents alike. Cognibl agents run on Claude Code or Codex, each in its own microVM, open a pull request and attach proof; only a person can merge, and a merge moves the task one step forward, never straight to done.

The flow on the Cognibl product page runs in five steps. A person assigns a task to a named agent the way they would assign a colleague. The agent moves the card to In progress, works on a branch in its own machine, runs the repository's tests and opens a pull request early. It attaches proof of work, which is a CSV describing the run that references the artefacts, screenshots and hashes, plus a coverage report where tests are part of the claim. It then reports, and a person decides.

The end state is the part that differs from Jules. A Cognibl run that finishes without proof stops at Blocked with the comment "Run ended without proof." so somebody looks at it, rather than closing quietly. The proof is checked in three layers: deterministic checkers first, then an AI verification flow that reads the proof against the definition of done and writes a summary, then a human sample whose size is set by the agent's score. The two AI flows summarise and flag; they never decide.

The record is built to outlast the tool. Proof versions are immutable, records are append-only and hash-chained, and every write is attributed to the calling key by name. Jules kept an immutable activity log too, so the difference is not immutability. What a Jules export lacks is a stored acceptance decision: it can show what an agent did, while an evidence-gated record also shows the evidence the work was accepted on. Our guide to verifying AI agent tasks goes deeper on how each verification layer works.

Cognibl is not a like-for-like swap, and a fair comparison should say so. Its product page does not describe a plan-approval step before a run: the brief and definition of done sit on the task, so a team that wants explicit plan approval keeps it in its own process or in the agent tool. Its pages do not describe importing a Jules export, so prompts, plans and AGENTS.md conventions move by hand. It links GitHub repositories today, with GitLab and Bitbucket planned, so a team on either of those does not fit yet. And it runs Claude Code or Codex agents, not Google's models, so a team committed to Gemini will look elsewhere.

Jules and Cognibl side by side

The table sets the two designs next to each other on the points that matter for a migration. Jules entries describe the product as documented before the turndown; Cognibl entries come from its live product page and stated product rules.

The second row is the one to dwell on. An approval that a timer can give is a default, and a default is a policy a team inherits rather than chooses. The point of moving the gate to the end is not that plans stop mattering. It is that the final check is made against evidence that exists, by a rule that does not expire when someone navigates away.

How should an engineering team migrate off Jules before 31 December 2026?

An engineering team should migrate off Jules in five steps before 31 December 2026: export every account's history, inventory the scheduled and suggested tasks Jules was running, move setup scripts and conventions into the repository, revoke Jules's GitHub and API access, and re-create the live work on a board where done requires evidence. The export comes first because it is the only step with a hard deadline.

Step one is the export. Run it for every person who used Jules, keep the output in a private location outside any repository, and record where it lives, because the environment variable file holds real values. Treat it as an archive of agent activity, not as the system of record.

Step two is the inventory. Jules could run scheduled tasks, introduced on 10 December 2025 for jobs such as weekly dependency checks, and suggested tasks that turned TODO comments into plans for approval. With Jules read-only, assume none of them is still running. List them, decide which still matter, and give each an owner. Our guide to recurring agent tasks covers how to keep evidence for work that repeats on a schedule.

Step three is the repository. Jules learnt from setup scripts, memories and an AGENTS.md file, and the export captures the first two. Move the setup commands and test command into the repository itself, and keep AGENTS.md current, so the next agent inherits the same context whatever vendor it comes from. Instructions that live in a versioned library rather than in a person's settings are easier to audit, which our skills library governance guide explains.

Step four is access. The Jules FAQ says repository access is changed in GitHub settings under Applications, where Google Labs Jules can be configured; once the export is complete, our advice is to use that page to remove its access. Revoke any Jules API keys, of which an account could hold up to three, and rotate the third-party keys pasted into Jules settings, such as those for its MCP connections to Linear or Supabase and its Render integration, because Jules connected to those services with API keys.

Step five is the board. Re-create the open work as tasks with a written definition of done, assign them to the new agent, and require evidence before done. If the team wants help sequencing this across several repositories, our AI execution office provides embedded, long-term delivery support, and an AI placement diagnostic can rank where agents should work next.

What is the best Google Jules alternative in 2026?

The best Google Jules alternative in 2026 depends on where a team wants control. A team that wants to stay with Google should look first at Google Antigravity, the platform Google names in its turndown notice. A team whose code, issues and reviews all sit on GitHub may prefer the Copilot coding agent. A team that needs completion proved, not assumed, should choose a board that refuses done without evidence, such as Cognibl, from DILR.AI.

Four questions, drawn from the five criteria above, separate the options. First, explicit plan approval: can the team switch off unattended approval and see who approved each plan? Second, isolation: does each agent run in its own machine without the power to push to the base branch? Third, the end state: does a run without evidence produce a blocked task someone must look at? Fourth, the record: are the evidence and the acceptance decision kept on the team's board, separate from the agent, so that an agent exit like this one does not take them with it?

Google Antigravity is the natural first look for teams committed to Google's accounts, because Google names it in the notice, and that concession is real; describing its features is outside this guide, so test it against the four questions directly at antigravity.google. The Copilot coding agent keeps issue, agent and review on one platform, which our GitHub comparison examines, and Devin and Cursor have their own comparisons. Cognibl's case is narrower and checkable: it puts the refusal in the status change itself, so done rests on attached evidence and a person decides, whether a person or an agent did the work.

For teams that want to see how that works with a framework rather than a hosted agent, our LangGraph work management comparison examines a done gate on top of an orchestration framework, and the what is Cognibl overview sets out the product in full.

Frequently asked questions

Can I still start a new task in Google Jules?

Not in practice. Google's turndown notice says users had until 11 November 2026 to continue finishing sessions, and that Jules would then be read-only until the end of the year before winding down on 31 December 2026. A read-only Google Jules is a place to export history from, not to run work, so new work should go to a replacement agent.

Does a Jules export include my code?

Partly. A Jules export includes each session's code patches, the diffs Jules produced, but not the repositories themselves, because Google's turndown notice says code, branches and pull requests already live in GitHub and stay there. The rest of the export covers what lived inside Jules: settings, environment variables, scheduled tasks, connected repositories, memories, setup scripts and each session's prompt, plan and activity log.

Planning the move off Jules? Read our proof of done guide, open Cognibl on cognibl.com, see our DATS methodology, or browse more AI strategy guides. If a sign-off question is holding up the switch, talk to our engineers, read our approach to placing AI, or learn more about Dilr.ai.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.