Gemini-CLI vs our roadmap

[acoliver]

#394 (comment)

Hello,
I have a question regarding the development vision for llxprt in relation to the original Gemini project, and I'd appreciate any insight you could share.
I'm curious to know if, at a certain point, llxprt's development path intentionally diverged from Gemini's. Is the plan to continue incorporating ongoing improvements and bug fixes from the Gemini codebase, or is llxprt on track to become a completely distinct tool?
My question stems from the user perspective that it would be wonderful if llxprt could continue to inherit the core enhancements from Gemini, while layering its own unique optimizations and features on top.
Please note this is purely out of curiosity to better understand your vision for what llxprt is today and where it's headed in comparison to its origins with Gemini.
Thank you for your time and for this great tool.

LLxprt has substantially diverged architecturally from GeminiCLI in these ways:

• Multiprovider support / local model support
• Atomic tool execution
• Telemetry removal (the one that reports to google on what you do)
• Todo implementation (ours predates theirs / different implementation)
• Configurability (model parameters etc)
• Context management (they have a big fat ugly array and the code is complete spaghetti and was unmaintainable)
• Authentication
• They keep adding new calls to flash (first was the nextSpeakerChecker, then LoopDetector, now "smart edits") - these are all bad and don't work well and waste tokens. We've removed them.
• a slew of other features

We will continue to diverge in these ways:

• Componentization - the gemini-cli code that we inherited is a mess of spaghetti - we'd like to clean this up and make it more maintainable
• Subagent Support - Google is doing this differently than we are. We're starting with in process. Also their way isn't very compatible with multi-model/multi-provider subagents
• Focus - Google is adding more stuff that is more google ecosystem stuff. We are not practically going to be able to test all of this stuff because we're not going to buy a bunch of different google products to do so... So we may not pick those.
• Compression / Context - because Gemini pushes context management to the server (you do not really have 1m cause it ignores a lot of it) the way they manage memory is not good. We deal with more small context models.

We will continue to cherrypick from upstream

• Tool support - i.e. we picked up Zed right after them and enhanced it to support multiple models and more!
• Interesting UI / Tools

Why we're so far behind at the moment:

1. I went on vacation
2. Refactoring things to support in-process multi-model subagents with full visibility and approvals for tools -- was a lot of work.

What's next:

1. In my branch subagents are working, I'm just debugging all the edge cases and sanding them off
2. We will put out a 0.5.0 reelase that is basically the current stuff + subagents
3. I'll then do some cherrypicking to get us closer to the current features of gemini-cli. We may be a bit more selective until now we've cherrypicked almost everything! and skip things that are clearly not of interest
4. We'll then start refactoring this into smaller parts - part of this is because "yuck," some is practical, and some is imperative. Because the sourcecode has gotten so big it is hard (and expensive) for models to work on it. We need to break it up so you can just "add a new provider" rather than suck down all of llxprt-code into context to know how.

What you can do:

No one can say we don't listen - most issues are addressed in process. Tell us what features from gemini-cli you like and wish we had. Heck tell us what feature from OpenCode or Claude Code you want. You can help drive the roadmap!

[pidgeon777]

Thank you for the excellent explanation. This tool has a lot of potential, keep it up!