> For the complete documentation index, see [llms.txt](https://docs.robinmesh.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.robinmesh.com/providers/browser-worker.md). # Browser Worker A browser worker turns a Chrome tab into a paid inference node. Nothing gets installed on your machine: you connect a wallet on the Earn tab, pick a model, and jobs begin routing to your GPU. Inside the tab, inference runs through the WebLLM runtime on top of WebGPU. Prompts execute on your own hardware, inside the browser, and generated tokens stream back to whichever client submitted the job. *** ## What you need | Requirement | Details | | ----------- | ---------------------------------------------------------------------------------------------- | | Browser | Chrome 113 or newer, or any Chromium browser with WebGPU turned on | | GPU | Any card the browser can drive over WebGPU, with at least 3GB of GPU memory exposed to the tab | | Wallet | An Ethereum wallet: MetaMask, Rabby, or Robinhood Wallet | | Network | A reliable connection. Streaming quality tracks your upload bandwidth. | | Stake | None. Browser workers never need to stake. | **Checking for WebGPU:** open `chrome://gpu` and find the "WebGPU" entry in the graphics feature status list. "Hardware accelerated" means your machine qualifies. **What will not work:** Safari (its WebGPU implementation is unfinished), Firefox (WebGPU ships disabled in most builds), and every mobile browser. Worker mode is desktop Chromium only. *** ## Setup **1. Connect a wallet** Visit `robinmesh.com/app` and open "Earn" from the navigation. When prompted, connect an Ethereum wallet (MetaMask, Rabby, or Robinhood Wallet). USDG payouts land at whichever address you connect here. **2. Pass the compatibility check** The moment you connect, the Earn tab probes your setup. It determines: * whether WebGPU is available in your browser * how much GPU memory the browser can see * which models fit inside that VRAM budget Missing WebGPU produces an error message with instructions for enabling it, or a nudge toward a supported browser. **3. Pick a model** You will only be offered models that fit your detected VRAM. Bigger models tend to pay more per job, at the cost of making the rest of your machine feel sluggish while a job runs. | Model | Tier | VRAM required | Earnings per job | | ----------------- | -------- | ------------- | ---------------- | | Qwen3 1.7B (Q4) | Lite | 3GB | $0.015 | | Llama 3.2 3B (Q4) | Lite | 4GB | $0.015 | | Qwen3 8B (Q4) | Standard | 6GB | $0.060 | | Mistral 7B (Q4) | Standard | 6GB | $0.060 | **4. Go live** Hit "Start Earning" and the page pulls the model into browser memory. Expect anywhere from 15 seconds to 2 minutes depending on model size and connection speed. After the first load, the weights sit in browser storage, so subsequent starts are fast. With the model loaded, your worker registers with the orchestrator mesh and jobs start arriving on their own. The page displays each incoming job alongside a running USDG total. No further input is needed from you. *** ## What happens during a job Each job that reaches your tab goes through six stages: 1. The orchestrator delivers an encrypted payload over a WebSocket connection. 2. A Web Worker thread decrypts it with the ephemeral session key. 3. WebLLM runs the prompt on your GPU through the WebGPU API. 4. Tokens stream back to the orchestrator as the model produces them. 5. When generation finishes, the worker hashes the complete output with SHA-256, signs the hash with the wallet key, and submits that proof to the `settlement` contract. 6. Settlement pays USDG to your wallet, usually confirming in under a second. RobinMesh sponsors the gas through ERC-4337, so you never touch ETH. Inference lives on a Web Worker thread, which keeps the tab's UI responsive and lets you browse elsewhere while earning. Heavy GPU work in another tab will, however, eat into your inference throughput. *** ## Getting paid USDG hits your connected wallet after every completed job. There is no minimum balance to withdraw and no batching of payouts. The browser tier pays 75% of each job's value. Staking is never required to run a browser worker, but the 85% rate is out of reach on this tier: it belongs exclusively to `robinmesh-node` operators holding an active $RMESH stake. For the duration of the beta, browser workers also collect a 2x $RMESH reward multiplier alongside their USDG. Those $RMESH rewards come out of the Community/Provider rewards pool and vest over 18 months. *** ## Stopping and coming back Close the Earn tab and your worker goes offline immediately. A job caught mid-flight times out and gets rerouted to another worker; you are not paid for the portion you completed before closing. Nothing else is lost. USDG balance and on-chain reputation live on-chain, not in the tab, so reconnecting your wallet later restores your full history. *** ## Troubleshooting **"WebGPU not available"** Turn on hardware acceleration at `chrome://settings/system`. If it is already on, update your GPU driver. **The model will not load** The browser may be seeing less GPU memory than the model needs. Pick a smaller model, or free up VRAM by closing tabs running video, 3D content, or other WebGPU apps. **No jobs are coming in** Freshly loaded workers can take up to 60 seconds to appear in the orchestrator mesh. Still nothing after several minutes? Check your connection, then confirm the dashboard lists your worker as "Active." **Hourly earnings feel low** Lite-tier models simply pay less per job than the larger models native workers run. Owners of NVIDIA cards or Apple Silicon machines will earn considerably more per hour by switching to the \[Native Worker]\( ) tier. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.robinmesh.com/providers/browser-worker.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.