Comment by Sajarin
2 months ago
Just blogged about this here[0] but at least they're not doing the usual canned PR response surrounding this.
Folks are already building on top of it:
thedavidweng/gork-build[1] — rebrand grok→"gork", stripped vendor telemetry, opt-out-only data retention, blocks x.ai auto-update. A "VSCodium-style privacy fork."
DigiGoon/digi-grok-build[2] — "dgrok" multi-provider CLI, builds from source instead of x.ai CDN.
victor-software-house/open-grok[3] — "opened to every provider."
LukaMucko/grok-build[4] — extra_body support for provider-specific request fields.
RapidAI/grok-build-desktop[5] — Tauri desktop GUI client.
mazdak/grok-build[6] — theming (Catppuccin).
thomas9120/grok-build-archival[7] — Windows telemetry-disable script.
saqoah/grok-build[8] — Kotlin MemoryBackend.
Thank you Sajarin mentioning my Gork-Build fork, I wanted to address some of the comments.
I agree that many of the responses in the comments are valid. It is a harsh reality that 80% of projects like this fail to gain traction and eventually fade away. However, I believe the significance of such a fork lies more in its existence as a statement. Regarding xAI, even if their current release of Grok has telemetry disabled by default, Zero Data Retention remains a feature exclusive to enterprise users rather than individuals. And Whole-repo research packaging is still controlled by their server-side settings; it isn't an option you can toggle within the software itself.
I am currently implementing more fences to prevent unnecessary data from being uploaded, in terms of long-term maintenance, one person certainly cannot build something on the scale of VSCodium, but I have drawn a lot of inspiration from that project. In the future, I want to automate Gork-Build further by turning these privacy protections and guardrails into patches. These could then be applied to new upstream Grok-Buil versions as they are released.
As for whether this project can become a daily driver for everyone, I don't think that is the primary concern. If you need a open source coding agent, you should definitely use Pi or OpenCode, there is absolute no necessity to use Grok-Build for non xAI models in the first place. But again I think its existence is vital. People need companies that demonstrate a truly open attitude and coding agents that are genuinely friendly to the open-source community, and while xAI's decision to open-source Grok-build was a great move, it isn't a community-maintained or community-built project. It remains a public snapshot of their internal monorepo, and they have disabled issues and pull requests. This is precisely why a fork like https://github.com/thedavidweng/gork-build needs to exist.
Nice, [3] reminded me of OpenGrok † the old Sun project that was basically LXR on steroids.
† https://oracle.github.io/opengrok/
These are all pointless forks, they will die in a year.
Bookmark this and check back.
Honestly. Some LLM enthusiasts throwing an agent at making a fork doesn't mean anyone is invested in this
That doesn’t mean they won’t be, or that the forks won’t be good.
3 replies →
While I'm sure most of them will die, there will certainly be 1 or 2 that the community rallies behind
Why when they can just fork it and improve it on their own with AI?
7 replies →
Or maybe Grok Build will implement some of these changes and render them obsolete.