# BitFun: a desktop AI agent runtime from GCWing that turns each task into its own Mini App > BitFun ships a Rust agent runtime, a desktop application, and a self-hostable relay for multi-device control. The interesting part is not the chat box, it is the interface the agent builds around a task, and the cost model behind it. **GCWing/BitFun** — BitFun is a desktop-grade Agent runtimeand a ready-to-use suite of desktop Agent applications.with built-in Code Agent Cowork Agent Computer Use. It has memory, personality, and the ability to evolve over time. - Repository: https://github.com/GCWing/BitFun - Website: https://openbitfun.com/ - Stars: 2,325 · Forks: 244 - Language: Rust - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/gcwing-bitfun ## What BitFun actually solves for a desktop agent user Most agent tools put every task through the same chat transcript. The README states the design goal directly: a task gets its own interface, whether that is a chart, a board, a form or a panel, and the conversation is bound to that interface's live state. The practical effect is that you ask about what is on screen instead of re-describing it in prose every turn. The second problem is reach. BitFun's execution layer covers the filesystem, terminals, Git, browser operation, desktop applications, Computer Use and remote workspaces. That matters because a large share of real work leaves the editor: a build that only passes on your machine, a form that only exists in a browser, a spreadsheet nobody exported to CSV. The third problem is governance. Cross-device session sync and controlling one signed-in device from another run through a relay you deploy. The README frames this as the distinction that decides whether the tool is allowed inside a company network at all. That is a fair framing. If your security review rejects vendor-brokered session data, a self-hosted relay is the difference between a tool you can use and one you cannot. Who it is for: engineers working in real Git repositories, and people producing documents, presentations, meeting notes and reports from source material. Who it is not for: anyone who wants a hosted agent with no local components to run. ## The Rust workspace behind the desktop app The repository is a Cargo workspace, and its member list is the clearest description of the architecture available without building it. There are separate application crates for the desktop app, a CLI, a server, a relay-server, an sdk-host, a data-migrator, and two market servers (miniapp-market-server and skin-market-server). Below the apps sit interface crates (acp, app-server, app-server-client, app-server-protocol, sdk-host), execution crates (agent-runtime, agent-workflows, agent-stream, tool-contracts, tool-call-jsonrepair), and adapter crates for other agent ecosystems: opencode-adapter, claude-code-adapter, codex-adapter, dsh-adapter, pi-adapter, plus a webdriver adapter and a transport adapter. Services are split into services-core, services-integrations, relay-service, terminal, page-function-runtime and the market services. Two consequences follow from that layout. First, the agent runtime is separable from the desktop shell, which is why a CLI and a server crate exist alongside it. Second, the adapter crates suggest BitFun is designed to sit next to existing agent tooling rather than replace it outright. The README does not document how those adapters are selected or configured, so that is a gap worth checking in the source before you plan around it. The front end is a pnpm workspace with Node.js 22.12 or newer required by the root package.json engines field. There is a web-ui package, a mobile-web package, a miniapp-market-web package and a skin-market-web package, each with its own dev script. ## Installing BitFun and running a first task The README gives two paths. The short one is to download the latest installer from the Releases page for macOS, Windows or Linux, install it, and configure a model. The long one is to run from source. For source builds, the prerequisites listed are Node.js 22.12 or newer, pnpm 10.15.0 via Corepack, the Rust toolchain, and the Tauri prerequisites. The README gives these two commands: ```bash pnpm install pnpm run desktop:dev ``` The pnpm install step triggers a postinstall hook that runs copy-assets, which copies Monaco editor assets and generates brand assets. If that hook fails, the desktop shell can still start but the editor and branding assets will be missing. First run is four steps in the README. Launch BitFun, click Open on the Welcome tab and choose a project folder. Then open More options (…) → Settings → Models → Create First Configuration. Choose a provider, enter its API key, select one or more models, and save. The README states that BitFun makes the first saved model primary and tests the connection automatically. Finally, return to the Session tab, type a concrete task, and press Enter or click Send. The provider list is not enumerated in the README, and neither is the set of supported API key formats. The README only says you choose a provider. That is the first thing to confirm against your own model access before you commit to a rollout. ## KV cache stability and flashgrep as cost controls The README makes a specific argument about agent economics: cost is dominated not by generated tokens but by context re-sent every turn, and a single timestamp or reordered tool list invalidates the cache from that byte onward. BitFun's answer is byte-stable prompt assembly across turns, which the README reports as a 98.67% average KV cache hit rate over a SWE-Bench-Pro run. flashgrep addresses the other half. An agent re-searches the same repository dozens to hundreds of times per task, and cold traversal on every tool call can cost more than inference. BitFun keeps a resident cross-turn index, which the README reports as cutting search time by up to 94.6% on Chromium-scale trees, roughly 36x on average. Both numbers deserve the caveat the README itself supplies in a note: these are initial evaluation results, each case run once, measured with Deepseek-V4-Pro, and benchmarks fluctuate with task sampling, model versions, runtime environment and single-run variance. The README explicitly asks readers to treat them as an initial sanity signal rather than a fixed ranking claim. Take that at face value. A single-run cache hit rate tells you the prompt assembler is designed for stability; it does not tell you what your hit rate will be on your repository with your tool set. The design claim is still the more useful part: if your current agent reorders tool definitions or injects timestamps into the system prompt, cache invalidation is a real and often invisible cost line. ## Where BitFun is the wrong tool The self-hosted relay is the clearest boundary. Cross-device control and session sync run through a relay you deploy. If your team has no appetite for running another service, or no environment where that service can live, then the multi-device features are effectively unavailable to you, and what remains is a single-machine desktop agent. The README does not document rollback, migration between versions, or what happens to synced session data when the relay is upgraded. The repository does contain a data-migrator crate and a legacy-migration service, which indicates migrations exist, but the README does not describe when they run or what they preserve. Plan for that unknown if you already have agent state you care about. Benchmark scope is another limit. The reported figures come from SWE-Bench-Pro and SWE-Bench-Verified runs with one model. If your work is not repository-shaped, those numbers say nothing about your case. Office workflows are listed as a scenario, but the README does not publish equivalent evaluation data for them. Finally, the README itself flags a missing asset: a TODO comment asks for a 20 to 30 second demo GIF of a real task running end to end, and calls it the single highest-impact asset in the README. Until that exists, you are evaluating the product from prose and screenshots, not from a recorded run. ## How BitFun differs from editor-embedded agents The obvious comparison is an agent that lives inside your editor. Editor-embedded agents inherit the editor's context: open files, the language server, the workspace root. That is a strong advantage for refactoring and a hard ceiling for anything outside the buffer. BitFun's architecture puts the runtime in its own desktop application and gives it a separate execution layer with terminal, browser, filesystem, desktop application and remote workspace access. The Mini Apps layer is the more unusual difference: instead of returning a chat reply, a task can produce a persistent interface with state the conversation refers to. A market dashboard and domain-specific tools are the examples the README cites from community builds, and there is a public gallery at market.openbitfun.com/miniapp. The cost of that approach is surface area. A desktop application with a relay server, two market servers, a CLI, a server crate and a plugin host is more to install, more to keep current, and more to secure than an editor extension. The README's four customization tiers (custom Agents, then MCP / Skills / Hooks, then Mini Apps, then source-level changes) are presented as a continuous ladder, but each rung is a different kind of work. Writing a Markdown agent file is not the same commitment as forking the runtime, and the README does not give effort estimates for either. ## Licence, versioning and the cost of staying current BitFun is MIT licensed, with a THIRD_PARTY_NOTICES.md file at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice; if you are redistributing a modified build, have your own counsel read the actual file and the third-party notices, because the bundled dependencies carry their own terms. Versioning is release-please driven, with release-please-config.json and .release-please-manifest.json at the root. The recent release history shows a stable line (v0.2.19 on 2026-08-28), a beta (v0.2.19-beta.1 on 2026-08-21) and a nightly build published the same day as the stable release. The last push to the repository was on 2026-08-28. That cadence means three moving channels. If you run the nightly, expect the runtime and the Mini App contracts to shift under you; the root package.json carries a canvas:sdk:check script and a miniapp:appearance:check script, which suggests generated contracts are validated in CI and can break when the generator changes. Pinning to a tagged release is the lower-variance choice. The upgrade cost is not just the binary. Because the relay server and the market servers are separate crates in the same workspace, a version bump can require redeploying your relay. The README does not document a compatibility matrix between desktop clients and relay versions. ## Conclusion Adopt BitFun if you want an agent that can reach a real desktop, terminal, browser and Git repository, and if you are willing to deploy the relay yourself for cross-device control. Do not adopt it if you need a hosted service with no local infrastructure, or if you expect the relay to be a managed offering. Before committing, verify three things: that your model provider is reachable from the desktop build, that the relay-server crate builds in your environment, and that the Mini Apps you depend on exist in the public gallery or can be written as Markdown agents. The repository's own README calls its benchmark numbers an initial sanity signal from single-run cases, so treat them as a starting point rather than a settled capability claim. ## FAQ ### What is BitFun? BitFun is a desktop-grade agent runtime and a suite of desktop agent applications from GCWing, written primarily in Rust and released under the MIT licence. It ships Code Agent, Cowork Agent and Computer Use capabilities, and gives a task its own interface through Mini Apps. ### How do I install BitFun? The README points to the latest installer on the Releases page for macOS, Windows or Linux. To run from source you need Node.js 22.12 or newer, pnpm 10.15.0 via Corepack, the Rust toolchain and the Tauri prerequisites, then run pnpm install followed by pnpm run desktop:dev. ### Does BitFun need a cloud account? No vendor cloud sits in the path for session sync and cross-device control: the README states those run through a relay you deploy yourself, and that the relay is zero-knowledge, holding only Argon2id hashes and AES-GCM-wrapped material. You still configure a model provider and its API key in Settings. ### Is BitFun actively maintained? The repository is not archived, and the last push was on 2026-08-28, with v0.2.19 released the same day and a nightly build published alongside it. The release history also includes a beta channel, so there are three parallel tracks rather than one. ## Sources - [Official documentation](https://openbitfun.com/) - [Official README](https://github.com/GCWing/BitFun#readme) - [Project repository](https://github.com/GCWing/BitFun) - [Release notes](https://github.com/GCWing/BitFun/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gcwing-bitfun