Why Renn Copilot

• One extension, zero moving parts. The backend and dashboard ship inside the .vsix. Install it and everything else starts itself.
• Local-first & private. The backend runs on your own machine — it is not a public, multi-tenant service.
• Plays nice with your config. It is the only thing that touches chatLanguageModels.json, and it edits only the single entry it owns — it never clobbers models you configured yourself.

Supported providers

Gemini CLI, Qwen, and iFlow have a caveat — see Known gaps.

Quick start

1. Install the .vsix (Extensions panel → ⋯ → Install from VSIX). The backend starts automatically; nothing else to install.
2. Open the dashboard — Command Palette → Renn Copilot: Open Dashboard, or click the Activity Bar icon.
3. Install the binary — on the Overview page, click Install binary (use Update version later when a newer release ships).
4. Log in — on Providers & Login, sign in or paste an API key per provider. Antigravity, Claude, and Codex open their auth pages; xAI shows a device code in the dashboard; custom providers can be added directly.
5. Pick models — on Models, toggle what Copilot Chat should see.
6. Sync — models sync on startup, or run Renn Copilot: Sync Models from Dashboard any time. Reload VS Code if its model picker doesn't refresh, then enable the Renn Copilot entries under Manage Models….

With the default rennCopilot.requireApiKey: false, no proxy key is needed. If you enable it, a changed sync copies the generated key to your clipboard — paste it when VS Code prompts for the Renn Copilot Custom Endpoint key.

The dashboard

Open it as a full editor tab (Command Palette → Open Dashboard) or as a compact Activity Bar sidebar.

The sidebar is a deliberate, focused summary — server status with Start/Stop/Restart, a one-line health line, the enabled-model count, and quick buttons for Sync Models / Copy API Key / Open Full Dashboard.

Settings

Commands

RTK — token savings for GitHub Copilot

RTK (Rust Token Killer) is a short-lived CLI that GitHub Copilot invokes through its official PreToolUse hooks to rewrite tool/bash output before it reaches the model, cutting token usage. It is not a daemon or a network proxy — there is no server to start or stop. RTK is distributed under Apache-2.0; Renn only downloads official release binaries and runs the official rtk init / rtk gain commands.

Open the RTK page in the dashboard to enable it in one click.

• Platforms. Managed binaries are provided for Windows x64, macOS (x64 / arm64), and Linux (x64 / arm64). Other combinations (e.g. Windows arm64) show an unsupported platform notice since RTK ships no official build.
• What Renn installs. A managed rtk binary under the extension's global storage, verified against the release checksums.txt (SHA-256) and validated before use. Archive entries are checked for path-traversal before extraction.
• PATH ownership. Copilot's generated hook calls rtk by name, so the binary must be resolvable on PATH. On Windows, Renn adds its managed bin folder to your user PATH (a VS Code restart is then required). On macOS/Linux, Renn creates a ~/.local/bin/rtk symlink it owns — it never edits your shell profiles and never overwrites an existing non-Renn file there.
• Scopes. Global wires Copilot everywhere (rtk init --global --copilot); Workspace wires only the current, trusted workspace (rtk init --copilot).
• Conflicts. If a different executable named rtk is already on PATH, Renn uses/reports it but never modifies it.
• Uninstall. Disable runs the official rtk init --uninstall to remove the Copilot hook and instructions. Delete managed binary removes only the binary Renn installed and the PATH entry / symlink Renn created — a user- or package-manager-installed rtk is never touched.
• Analytics caveat. The savings percentages come from rtk gain and reflect reduction in the tool/bash output RTK processed — not your Copilot billing or subscription usage.

Vision capability detection

Renn Copilot doesn't ship a "complete" global list of vision models — such lists go stale fast and can't describe arbitrary custom providers. Instead it resolves image-input support in order:

1. A per-model Vision / No vision manual override.
2. A successful live verification — asks the model to identify a property of a small test image.
3. Curated metadata for the handful of built-in models this project knows.
4. Unknown for everything else.

The Models page checks availability without sending chat requests. A live vision check runs only when you click re-check or enable a model whose support is still unknown — it uses a small amount of real quota. Auth, rate-limit, quota, timeout, and upstream errors stay Unknown rather than being mislabeled No vision.

Each check has a 30-second deadline and runs with bounded concurrency. Models still marked Unknown are exported with vision: false; image attachments turn on only after positive evidence or an explicit override. For a custom provider, leave the selector on Auto, or pick Vision / No vision when its docs are definitive.

Building from source

Requires Node.js 18+.

# install dependencies (root, backend, webview)
npm install
npm install --prefix backend
npm install --prefix webview-ui

# build the .vsix (webview build + backend deps + vsce package)
npm run package

Install the generated .vsix, or press F5 with this repo open to run it in the VS Code Extension Development Host while iterating.

Tests

npm test --prefix backend       # backend capability / provider / migration tests
npm test --prefix webview-ui    # webview pure-util tests (e.g. Activity graph)
npm run compile                 # type-check the extension host
npm run webview:build           # build the dashboard

Run npm audit independently in the root, backend/, and webview-ui/.

Project layout

Troubleshooting

Known gaps

• Gemini CLI / Qwen / iFlow OAuth aren't wired into the dashboard yet. CLIProxyAPI exposes ready-made OAuth endpoints for Antigravity, Anthropic, and Codex (and Renn Copilot implements xAI's device-code flow), but these three still need CLIProxyAPI's own CLI --login flags on the backend machine.
• Custom OpenAI-compatible providers vary in metadata and error behavior. When a provider doesn't expose definitive vision metadata, use live verification or a manual override on the Models page.