[KongchangAI]
· 1 min read· 968 words

rakazo: An Open-Source Grok Bot Alternative with Custom Models and Sandboxing

rakazo: An Open-Source Grok Bot Alternative with Custom Models and Sandboxing

Open-source rakazo decouples models and sandboxes to build a self-hostable Grok Bot alternative.

The article introduces the GitHub project elie222/rakazo, a computer-use AI agent positioned as an "open-source Grok Bot alternative." Its core design separates two layers that are hardwired in traditional products: the model layer lets users choose their own providers, balancing cost, capability, and data compliance; the sandbox layer lets users choose the execution environment, making AI computer operations controllable and addressing the biggest security concern. Written in TypeScript, the project has 5,315 stars and 948 forks, with 1,166 new stars in a week, showing genuine developer demand for customizable, self-hostable agents. The article also notes that current public information focuses on positioning and metrics; model integration, sandbox implementation, and documentation completeness still need to be verified by developers, and early-stage open-source projects often have weak documentation and stability.

Why We Need an Open-Source Grok Bot Alternative

Tools like Grok Bot let AI directly operate a user's computer—opening browsers, running code, and handling files. Behind this convenience lies the hidden concern of a closed ecosystem: you cannot choose the underlying model, you cannot audit what it executes on your machine, and you certainly cannot deploy it on your own infrastructure. The GitHub project elie222/rakazo offers an answer: give the choice back to users.

rakazo GitHub project homepage

According to its GitHub page, rakazo positions itself as an "open-source Grok Bot alternative," with its core selling points being custom models and custom sandboxes. Written in TypeScript, the project has already gained 5,315 stars and 948 forks, including 1,166 new stars in a single week—a growth rate that shows a considerable number of developers are looking for self-hostable computer-use AI agents.

Two Core Design Principles: Decoupling Models and Sandboxes

rakazo's most valuable design idea is to separate the two layers that are hardwired together in traditional Bot products.

The Model Layer: No Vendor Lock-in

Most similar products only support their own models, while rakazo lets users connect the models they prefer. This means you can trade off between cost and capability based on task complexity: simple operations go to cheaper models, while complex reasoning switches to stronger ones. For teams with data compliance requirements, connecting privately deployed models also becomes possible.

Vendor lock-in refers to a product hardwiring its underlying model to a single provider's service, making it impossible for users to swap it out and creating high migration costs. For computer-use agents, lock-in also means two risks: costs are accepted passively, and data must flow through a third party. Custom models are typically implemented through a unified model-calling interface that abstracts different vendors' APIs (or local inference services) into the same request format, so users only need to change the model identifier and key in the configuration. This also makes "model routing" possible—dispatching requests to different models based on task difficulty. It's worth noting that different models vary in their support for function calling and structured output, and connecting privately deployed models often requires adapting prompts and tool schemas yourself—this is the main engineering cost when implementing a custom-model approach.

The Sandbox Layer: Controllable Execution Environment

For an AI agent to operate a computer, it must have an execution environment. rakazo makes the sandbox optional, letting users choose where the agent runs—an isolated container, a remote machine, or another controlled environment. This directly addresses the biggest security concern with such tools: letting AI run code is not the same as letting it freely touch your main system.

Project interface or architecture diagram

Sandbox in computer security refers to an isolated runtime environment that lets untrusted or high-risk code execute in a restricted space, so that even if it fails or behaves abnormally, it won't affect the host machine. Common implementations include containers (such as Docker), virtual machines, and syscall-filtering-based approaches like seccomp / gVisor. For AI agents, the value of a sandbox lies in narrowing "can operate a computer" to "can only operate within defined boundaries": the agent can run code and access files, but its visible filesystem, network egress, and system permissions are all restricted. Common industry isolation levels, from lightest to heaviest, are roughly: process-level permission restrictions, container isolation, microVMs (such as Firecracker), and dedicated physical/cloud hosts. Which sandbox you choose directly determines the blast radius an agent could cause after a malicious prompt injection—this is exactly the security significance of rakazo making the sandbox an optional layer.

Tech Stack and Project Status

The project is written in TypeScript, making it relatively accessible for developers in the frontend and Node.js ecosystems—both reading the source code and building on it are low-cost. Judging from community feedback, nearly a thousand forks indicate that quite a few people are already customizing it.

What deserves a sober perspective is that current public information focuses mainly on the project's positioning and basic metrics. The specifics of model integration, sandbox implementation details, and the completeness of deployment documentation still require developers to check the repository themselves. In the early stages of open-source projects, documentation and stability are often weak points.

Computer-use agents differ from ordinary conversational AI in a key way: they have "hands and feet," directly changing the computer's state through browser automation, shell commands, file read/write, screenshots and clicks, and other tools. Their typical work loop is "observe—plan—execute—observe again," with the result of each step fed back to the model to decide the next one. The capability ceiling of such agents depends on the richness of their toolset, while the risk comes from the irreversibility of executed actions (deleting files, sending requests, changing configurations) and from prompt injection attacks—malicious instructions embedded in web pages or files can induce an agent to take unauthorized actions. Therefore, least privilege, action confirmation mechanisms, and rollback-capable sandbox environments are three unavoidable requirements in the design of such systems.

Who It's For

  • Teams that prioritize data sovereignty: those who don't want to hand over operational permissions to closed-source SaaS and need a self-hosted solution.
  • Developers who want to control inference costs: balancing expense and effectiveness by switching models.
  • Security-sensitive scenarios that require auditing execution: an optional sandbox means execution boundaries can be defined and inspected.

Signals Worth Watching

The growth of 1,166 stars in a week reflects genuine market demand for "customizable, self-hostable AI agents," not just novelty. While closed-source Bot products still use ecosystem lock-in to retain users, open-source alternatives compete for the same group of control-sensitive users through decoupled design. Whether rakazo can go from "alternative" to "first choice" depends on whether its sandbox implementation is robust enough and whether model integration is smooth enough—and only by actually running it will you know.

#rakazo#Grok Bot alternative#open-source AI agent#self-hosted AI#AI sandbox#custom AI models
Share:

Related articles