Google's Jules is sitting on 300 tasks-per-day at the Ultra tier, and most engineering teams are using it for roughly the same three things: dependency bumps, test coverage gaps, and the bug tickets nobody wants to touch on a Friday. That's not a criticism - it's a signal about where async coding agents actually earn their keep.
The last few weeks clarified something that the tool demos have been blurring: there are now two genuinely different categories of AI coding agent, and confusing them wastes money and goodwill.
What "async coding agent" actually means
An async agent takes a task specification, disappears, and returns a diff. Jules is Google's asynchronous coding agent: you give it a task, it clones your repo into a secure cloud VM, writes a plan, executes multi-file changes, and opens a pull request. You review the diff and move on. You are not collaborating with it. You are reviewing its output - the same relationship you have with a contractor.
That distinction drives every other design choice. Review cost is the limiting factor on async agents, so a PR that is painful to review is a PR that costs more than it saves. Jules leans into this: pull requests tend to ship with readable commit messages and a plain-language summary of what changed and why - a deliberate design choice. Jules defaults toward small commits and descriptive titles even when the underlying change is multi-file.
Sync tools work the opposite way. Claude Code is interactive: it runs in your terminal or VS Code and you collaborate with it in real-time. Jules works asynchronously and delivers PRs. Antigravity CLI sits in the same category. It brings the full Antigravity experience to the command line: same harness, same agent, same quality of intelligence as Antigravity 2.0, with a product experience tailored for the terminal.
The category split, in short:
| Sync (Cursor, Claude Code, Antigravity CLI) | Async (Jules, Codex cloud) | |
|---|---|---|
| Where it runs | Your machine or terminal session | Cloud VM, isolated per task |
| Your role | Collaborator - you steer in real time | Reviewer - you evaluate the PR |
| Best task shape | Exploratory, ambiguous, multi-step | Well-specified, bounded, parallelisable |
| Interrupts you? | Constantly (by design) | No - it pings you when done |
| Network access | Yes | Jules: yes; Codex: no (strict sandbox) |
| Cost lever | Session length and token burn | Task count and review time |
The harness is now the product, not the model
This matters because the labs have started shipping it explicitly. Google spent years telling developers that the IDE was the right place to put AI assistance. At I/O 2026, it changed that answer. The IDE is now just one surface. The agent harness is the product.
Google announced Antigravity 2.0 at I/O 2026, upgrading its agentic coding tool into a full developer platform with a revamped desktop app, a new CLI built in Go, and an SDK for custom agents. Version 2.0 lets developers orchestrate multiple AI agents in parallel. The same harness runs across all of them: the Antigravity CLI shares the same agent harness as Antigravity 2.0, meaning all future improvements to core agents are automatically applied across both surfaces.
The Claude Code side is converging on the same shape. Repository-wide context windows are now routine, multi-step tool invocation is standard, and agent frameworks are converging on shared abstractions: system prompts, developer prompts, environment tools (git, CI, issue trackers), and memory layers. The model matters less at the margin than the scaffolding around it.
When to reach for the async agent
The practical answer is simple: use async when the task is a ticket, the brief is solid, and you have five other things running. For well-specified tasks, batched refactors, scheduled maintenance, and any context where parallelism matters more than real-time control, the async model is a genuine productivity unlock. The honest evaluation is not "which tool is best" but "which tool fits this task right now." Sync tools win on interactive exploration; Jules wins when the unit of work is a ticket, the brief is solid, and you have five other things to do while it runs.
The failure mode is assigning async agents to ambiguous work. Jules takes a GitHub issue, opens a cloud VM, clones your repo, reads the code, writes a plan, implements the fix, runs the test suite, and opens a pull request - while you're doing something else entirely. That pipeline is only as good as the issue it starts from. Vague acceptance criteria produce PRs that look complete and aren't. You burn review time instead of writing time.
Codex disables network access per task for strict sandboxing. Jules keeps network access so it can install dependencies and run builds. That difference matters for security-conscious teams: Jules can pull packages at runtime; Codex cannot. Neither is categorically safer - the right choice depends on what your task actually needs.
Beagle in action#eng, 10:47amThe two patterns belong in the same team
The agencies and platform teams getting the most from agentic coding in 2026 are the ones running both patterns in parallel, not picking a favourite. A useful rough split: sync for anything where the requirement is still being discovered, async for anything where the requirement is already a ticket.
The one place this breaks down is code review bandwidth. If your team merges three PRs a day from humans, adding 10 from Jules doesn't scale - the review queue becomes the bottleneck, not the agent. Size the async workload to what your reviewers can actually absorb. Jules's plan-first execution (it shows intent before writing code) helps, but it doesn't replace the discipline of writing a good brief before you queue the task.
The tooling landscape is moving fast enough that the "best tool" answer will be wrong in six months. The workflow discipline - write a tight brief, pick the right interaction model for the task shape, calibrate async volume to review capacity - stays useful regardless of which agent is running it.
Async coding agents: common questions
What is an async coding agent?
An async coding agent takes a task brief, runs the work independently in a cloud environment, and returns a pull request or diff for review. Unlike sync tools such as Cursor or Claude Code, it does not expect you to stay in an active session. You assign work, close the tab, and review the output when it is ready.
When should I use Jules instead of Cursor?
Use Jules when the task is well-defined - a bug ticket, a dependency update, a test gap - and you want to parallelise work across multiple issues. Use Cursor or Claude Code when the requirement is still being figured out, when you need real-time steering, or when the task spans ambiguous architectural decisions. The two tools complement each other; they are not substitutes.
Does Jules have network access during tasks?
Yes. Jules keeps network access inside its cloud VM so it can install dependencies and run builds during a task. OpenAI's Codex cloud agent takes the opposite approach and disables network access per task for stricter sandboxing. Which model you prefer depends on whether your task needs to fetch packages at runtime.
How many tasks can Jules run at once?
The free tier runs 15 tasks per day with 3 concurrent. The Ultra tier (part of Google AI Ultra at $100/month) raises that to 300 tasks per day with 60 concurrent tasks running simultaneously. Google Workspace and business accounts cannot yet subscribe to paid Jules tiers; enterprise pricing is not yet published.
What makes async agent PRs hard to review?
The main failure mode is a poor task brief. Vague requirements produce PRs that look complete but miss the actual intent. A second issue is volume: if async agents ship more PRs per day than your team can absorb, review becomes the bottleneck. Jules mitigates this with small commits, plain-language summaries, and a plan-first step that shows intended changes before writing any code.