It’s a shame Google picked the wrong system design for Jules. Claude Code’s system design is clearly superior at this point.
Jules is going to simply be another vendor locked walled garden play.
Jules, remote coding agent from Google Labs, announces API
11–20 of 81 posts
Re: Jules, remote coding agent from Google Labs, announces API
#12It’s a shame Google picked the wrong system design for Jules. Claude Code’s system design is clearly superior at this point. Jules is going to simply be another vendor locked walled garden play.
I've been using AI coding agents since the very early days of Aider and I think this is not quite true.
There's a place for async agents. There's a place for collaborative agents. Collaborative agents may even soon be delegating off to multiple async agents and picking best results. There's so much complexity here and we haven't even begun to explore a corner of the possible design space. We're still trying to plug AIs into human-shaped holes instead of building around their interesting/weird capabilities.
Re: Jules, remote coding agent from Google Labs, announces API
#13Would anyone at Google be willing to tell me how many people are working on this project? I’ve been building something functionally similar for my employer, but it’s a nights and weekends project with only one contributor (me).
Re: Jules, remote coding agent from Google Labs, announces API
#14It’s a shame Google picked the wrong system design for Jules. Claude Code’s system design is clearly superior at this point. Jules is going to simply be another vendor locked walled garden play.
I think they are doing both (in true Google fashion), there is an open source Gemini cli with a generous free tier that more directly competes with Claude code.
https://github.com/google-gemini/gemini-cli
It was pretty rough at launch but has gotten a lot better. So has Claude code though, so I’ve never really switched over.
Re: Jules, remote coding agent from Google Labs, announces API
#15It’s a shame Google picked the wrong system design for Jules. Claude Code’s system design is clearly superior at this point. Jules is going to simply be another vendor locked walled garden play.
I fail to see how comparing Jules to Claude Code is relevant. They’re completely different.
A good Jules comparison would be OpenAI Codex.
For a Claude Code Google equivalent there’s Gemini Code Assist CLI
Re: Jules, remote coding agent from Google Labs, announces API
#16Was able to build a personal MCP server that connects to the Jules API, letting me dispatch tasks to Jules, from Copilot Chat in VS Code.
Video here: https://www.youtube.com/watch?v=RIjz9w77h1Q
Re: Jules, remote coding agent from Google Labs, announces API
#17Jules can add all it wants and I will still not use it simply because it's a Google product and Google doesn't know how to make products in the past 20 years.
Also, why the heck are Google's offerings so fragmented?! We have `gemini`, `jules`, and we also have two sets of different Gemini APIs (one is more limited than the other), and no API is entirely OpenAI-compatible.
Come on Google...
Re: Jules, remote coding agent from Google Labs, announces API
#18It’s a shame Google picked the wrong system design for Jules. Claude Code’s system design is clearly superior at this point. Jules is going to simply be another vendor locked walled garden play.
[deleted]
Re: Jules, remote coding agent from Google Labs, announces API
#19It’s a shame Google picked the wrong system design for Jules. Claude Code’s system design is clearly superior at this point. Jules is going to simply be another vendor locked walled garden play.
I fail to see how comparing Jules to Claude Code is relevant. They’re completely different. A good Jules comparison would be OpenAI Codex. For a Claude Code Google equivalent there’s Gemini Code Assist CLI
Exactly. As the sibling comments point out. Async and collaborative are different ways to work. Both have its place.
Re: Jules, remote coding agent from Google Labs, announces API
#20Earlier quoted context omitted.
How expensive are the API charges? Seems like it might be a bit too easy for a customer to rack up a big bill testing out minor changes if things weren't configured correctly.
There is a free plan with 15 tasks/sessions. It doesn’t count tokens AFAIK. There would obviously be a runtime limit of some sorts for sure. But it’s not the same as API keys and token situation
The free tier is 15 tasks per day (of gemini-2.5-pro) which is EXTREMELY generous. I've had plenty of tasks run for 1-2 hours. I do think that after 1 or 2 hours it's told it needs to wrap up and just present what it's done; I couldn't get it to keep going longer than 2 hours. But Jules is very slow as it seems to be batch processing on spare capacity, so 15+ hours a day is not quite as absurd as it sounds.
I haven't tried Jules in a couple weeks, but the UI/UX had a lot of issues such as not being given any progress updates for very long times. The worst thing was not being able to see what it was doing and correct it: you only see the state of files (without a usable diff viewer, WTF) at the last point that the agent decided to show you anything (the last time it completed a todo list item I think, and I couldn't get it to update the state when asked, though it will send a PR if you ask), and gemini-2.5-pro can often try really stupid things as it tries to debug. I've also been impressed at its debugging abilities a number of times.
Still, I found Jules far more usable than Gemini CLI (free tier), where Gemini just constantly stops for no reason and needs to be told to continue, and I exhausted the usage limit in minutes.
Aside from the unlimited free tier, probably the best part of Jules are its automated code reviews. Once, I was writing up some extensive comments on its code and then unexpectedly a code review was dropped in the conversation which gave exactly the same feedback I was writing. Unfortunately if it never reaches the point of submitting for review, it doesn't get an automated review. It does often ask for feedback before it's done, which is nice. So probably I needed to prompt better.