Recent news from Gemini-CLI team - The future is LLxprtise

[acoliver]

Google is -- well googling -- They're largely deprioritizing Gemini-cli and trying to push everyone to their proprietary and less capable Anti-gravity CLI. Note this project was never really dependent on Gemini-CLI continuing we used it as a jumping off point. While we've continued to cherrypick or reimplement their good ideas -- and skip their bad ideas -- the project has gone its own direction.

In my unbiased opinion, LLxprt Code is already a better option than Gemini-CLI for most people -- not only because there are fewer costly models and more capable ones than Google's, but also because a mix of models often produces better results. A different model can be used to plan, verify, and correct the plan, implement, verify, and correct the implementation, and verify holistically. Anytime you're running something long, any stupid problem with your inference provider (which Google is practically famous for) can ruin your generation cycle. It sucks to go to bed at night, wake up, and realize it stopped 1h into something complicated. LLxprt code specifically addresses all of this.

Google is likely to continue making the same engineering mistakes because it has no reason not to. A grep should be constrained so the model can't suck down the full 1M (or less) context in one call. For one, large contexts tend to lead to poorer focus and, as a result, worse results. Smaller contexts with closer-to-exactly what is needed "complete" better. LLxprt fixed these issues and augmented them with other tools to verify and correct code.

However, LLxprt Code isn't really enough. The companion project LLxprt Jefe enables you to manage multiple contexts across multiple projects and continue on where you left off. More than that, though, the soon-to-debut LLxprt Luther (a far more advanced version of the GitHub Action we experimented with earlier in the year) will tie this into an event-driven workflow.

The early stages of Luther are being used to develop LLxprt Code. We'll publish once it is hardened a bit. Basically, LLMs are bad at making deterministic calls. How many times has Claude screwed you over by deciding "the improvement in passing tests is sufficient to continue" or something like that (when most are still failing) or disabled or faked something and continued? The trick is to move the workflow outside the LLM and ensure that anything that can be static and deterministic is handled in a static, deterministic way, not judged or driven by a probabilistic system (such as an LLM).

Finally, the system should evaluate and improve itself. Luther will evaluate and improve on itself by itself.

CLIs and IDEs will continue to be an important part of our workflow for prototyping and planning, but in the future, I expect the system to self-improve much more and move further outside the CLI and into the issue tracker and evals. This is the overall direction things are going!

You might have noticed an interruption over the past few weeks. Rest easy. I was on vacation, lost connectivity to my more powerful home system, and sick. Expect the normal flow to continue!

Onward and upward.

[Zevan770]

Thank you for all your hard work on this. Would it be possible to pin this discussion, or perhaps add a reference to it in the README.md for better visibility and notification?

[acoliver]

pinned it. Good idea on the readme.

[acoliver]

FYI to all -- Gemini Auth still works in LLxprt for the moment... I'm not going to over-flag this as I don't want to draw attention but it is working so far.

[acoliver]

/model gemini-3.1-pro-preview also works (though we don't have it in the menu atm)