Free unlimited Gemini API via Canvas + Chrome extension postMessage bridge. No WebSocket, no Local Network Access issues. OpenAI-compatible endpoint.
Functional proxy with clear docs and Docker option, but no CI, no dep manifest, and thin adoption.
postMessage bridge bypasses Chrome 142+ Local Network Access blocks that break WebSocket-based Canvas proxies
Canvas auto-injects unlimited, model-scoped API keys when code contains `const apiKey = \"\";` at compile time
window.postMessage, an IPC mechanism Chrome cannot treat as a blockable network call.| Rating | Summary | |
|---|---|---|
| Quality | decent (14/24) | Solid documentation and a working Docker path, undercut by Python-only tooling, no manifest, no tests, and thin adoption. |
| PAI Relevance | watch (0.50) | A clever browser-bridge pattern worth studying, but the manual extension/Canvas setup and ToS-fragile mechanism keep it out of direct integration. |
14/24 — maintained / adequately-documented / early-or-minimal
Failed:
.github/workflows/ reference.Passed:
isArchived is false.Failed:
Passed:
./setup.sh.Failed:
Passed:
| Dimension | Score | Assessment |
|---|---|---|
| Harvest Value | 1 | The postMessage-over-WebSocket IPC trick to bypass Chrome's Local Network Access sandboxing is a reusable pattern worth studying, though it maps to no named PAI subsystem directly. |
| Integration Readiness | 1 | Exposes a clean OpenAI-compatible HTTP endpoint (localhost:8765) any agent could call, but the Python native-messaging host plus manual Chrome-extension/Canvas paste-in setup isn't a bun add-able CLI. |
| Overlap Risk | 1 | Partially overlaps PAI's Interceptor (stealth Chrome automation), which already covers browser-extension-based automation, though this repo's free-inference-via-Canvas trick is a distinct use case. |
| Gap Fill | 1 | Touches an area PAI has limited coverage in — sourcing free/alternate LLM inference — though PAI's Agents skill already manages cross-vendor model routing (GPT-5.4, Kimi-K2.6, Claude). |
Composite: 0.50
ToS/fragility risk monitoring: Bookmark this repo and check monthly whether Google patches the Canvas session-key auto-injection it exploits — the entire approach depends on an undocumented credential leak that could be closed in a single Canvas UI update, same failure mode that already killed the WebSocket-based CanvasToAPI predecessor.
postMessage-vs-WebSocket bridge pattern: Run a 30-minute standalone test spinning up the Docker/noVNC container and hitting the OpenAI-compatible endpoint with curl, timing latency and checking for rate-limit walls under sustained load — this validates whether the postMessage IPC bridge is actually stable enough to depend on before using it for anything beyond casual scripting.
Re-evaluate on condition: Upgrade this from watch to active use only if the repo survives a Chrome major-version bump (144+) without breaking and gains a second contributor — both are objective signals the exploit-dependent bridge has more than single-maintainer shelf life.
Category: Web & Browser Automation
In this category: first entry — no prior appraisals recorded in this category for cross-referencing.
Standing: As the first Web & Browser Automation entry in the vault, it stands alone rather than being compared against ChromeDevTools-MCP or crawl4ai-class tools, which target scraping/DOM control rather than credential-bridging.
Density: 8/10 — Available: full README (8KB), description, language/license, star/fork/issue counts, creation and last-commit timestamps, release tag. Missing: dependency manifest ("Not available"), no visible CI config, no topics tags, no contributing/limitations doc beyond the inline security note.
The core mechanism relies on exploiting Google's Canvas auto-injected API credentials — a quota loophole rather than a sanctioned API path. This makes the tool inherently fragile to upstream changes (Google could patch the credential injection at any time) and raises ToS considerations that are out of scope for quality scoring but worth flagging for anyone considering production reliance.