-
|
This is kind of a dumb question to ask since we know Claude Flow is overdependent on Anthropic's Claude Code, and that everyone is copying them. Qwen-code, Gemini CLI, etc... But at the same time, there are unified providers for LLMs like OpenRouter, ready to hot-swap models while everyone uses OpenAI-compatible API (instead of whatever GPT-OSS is doing with Harmony, OR Anthropic's API format needing Claude-Code-Router). https://github.com/musistudio/claude-code-router |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
|
My guess to the solution https://github.com/RoderickGrc/gemini-cli-proxy-for-ollama https://github.com/csyangwen/OpenAI-to-Gemini-API-Proxy |
Beta Was this translation helpful? Give feedback.
-
|
A potential solution https://github.com/acoliver/llxprt-code/ - a fork of gemini-cli that supports nearly every provider and model including local as well as auth to Qwen, Gemini and Claude Max/Pro -- and cerebras's new Cerebras Code system. It also has claude style todo lists. |
Beta Was this translation helpful? Give feedback.
-
So rUv updates Claude-flow on a pretty regular basis...I've had some health issues + life circumstances (destination wedding [not mine lol], etc.), so I've had to restrict my Claude-flow usage, which I was heavily dependent on to help build Gemini-flow, especially when as claude-flow updates with each command based on how I code, it'll call the latest claude-flow iteration. But rest assured, I'm definitely keeping a watch and intend to be a contributing member to rUv's community, so the end-goal will always be 1:1 parity, just on the Gemini side of things. I have a meeting with Google in early September where I'm going to try and get some Vertex AI credits and Gemini credits in order to test Gemini-flow for them, and if I can get some development flows worked out; I'll bring them up as Gists for everyone to use to start REALLY harnessing Gemini-flow. |
Beta Was this translation helpful? Give feedback.
-
EDIT & UPDATE: Also to say I'm going to be working with Codex and other dev tools that I have credits with (the new grok-coder-fast-1) and I'll be using this to try and punch up Gemini-flow with other tools while keeping to the Google native ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
How automated can a dev tool get when it comes to copying and optimizing for features? DGM is fascinating in that regard since the code will try to learn all the best practices to make itself run more smoothly. |
Beta Was this translation helpful? Give feedback.
-
So admittedly, as a bit more of a newbie in the game; I'm pretty unfamiliar with DGMs, but with a quick cursory agentic search...I understand COMPLETELY why you bring this up. This is definitely something I want to research more into to pare down some of the excess code baggage...but I do want to balance that with Google-native-ecosystem continuous self-optimization: Much like DGM, Gemini-Flow’s agents benchmark, monitor, and self-optimize for cost, throughput, and latency in real time, but I wanted to give a huge cross-modal amount of environments for it to talk amongst to. The system automatically tunes orchestration strategies and applies learned best practices to all active workflows. So you're still getting ntegrated automation for the full pipeline: You get multi-modal agent swarms that handle not just code but also research, documentation, testing, CI/CD, and even Google AI service integration—all through one orchestrator. Production deployments are automated with built-in Byzantine fault tolerance and rollback, aiming for zero-downtime releases. Let's just kind of call it, an open source graduated practice of being able to navigate my first local-side CNN->LSTM->RNN->CTC loops and giving that a massive shot of steroids. But you do raise extremely valid points where I need to use DGM like practices and components in order to not have to over-engineer and therefore introduce fault and potential for error downstream. |
Beta Was this translation helpful? Give feedback.
-
|
As a bit of heads up, OpenEvolve and DGM (others too) are a bit more systematic about it, just that they are not terminal-native or IDE-based. If just throwing some pocket change and tokens can make wonders, why not let it get smart over time? The only issue then would be "project management" algorithmicsuperintelligence/openevolve#197 |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting question! So natively, the purpose of this was to really harness and hone in on Google's native ecosystem as much as possible. Part of why I wanted to submit this project under an MIT license is that if someone wants to try to tie my tool to OpenRouter and the like, they're more than free to do so. What I will try to do is a meeting in the middle; there may be some sort of way I can try to work in a layer whereby there's an "interrupt" in the workflow where a workflow split branches off, and calls to something like OpenRouter, Together.ai, Groq, Samba, etc. that may allow for some limited customization, but tbh, this won't be something I prioritize (there's too many kinks that need to be worked out and way too much core development to do at this time...), but it is something I'll take into consideration as I develop along the project! |
Beta Was this translation helpful? Give feedback.
This is an interesting question!
So natively, the purpose of this was to really harness and hone in on Google's native ecosystem as much as possible. Part of why I wanted to submit this project under an MIT license is that if someone wants to try to tie my tool to OpenRouter and the like, they're more than free to do so.
What I will try to do is a meeting in the middle; there may be some sort of way I can try to work in a layer whereby there's an "interrupt" in the workflow where a workflow split branches off, and calls to something like OpenRouter, Together.ai, Groq, Samba, etc. that may allow for some limited customization, but tbh, this won't be something I prioritize (there's too many…