WeSight: A Desktop Console for Local Coding Agents

The gap WeSight is trying to close

Terminal coding agents each carry their own setup ritual. Claude Code, Codex, Kimi Code, OpenClaw, Hermes Agent, OpenCode, Qwen Code and DeepSeek-TUI install differently, read different config files, and authenticate against different providers. Once they run, their model routing, permission prompts, file diffs and token spend sit in separate terminal windows with no shared history.

WeSight is aimed at the developer who already has one or two of those CLIs working and wants the rest of the surface unified. The README frames the problem directly: setup, model routing, permissions, IM entry points, file changes and runtime metrics "often live in separate places." The project's answer is a single Electron desktop app that installs or detects the CLIs, runs them through a chat interface, and records what each call cost in tokens and time.

That audience is narrower than "everyone using AI." If you run a single agent and never change models, a terminal and a config file are cheaper than a desktop app. WeSight earns its place when the count of engines, providers or entry points grows past what you can hold in your head.

How the Electron shell, engine adapters and model router fit together

The repository is a Vite and React frontend with an Electron main process, TypeScript throughout, built by electron-builder. The package.json declares node >=24 <25 and points main at dist-electron/main.js, so the desktop shell is compiled separately from the renderer.

WeSight does not reimplement the agents. It treats each CLI as an engine it can install, detect or reuse, then drives it and reads back structured events. The README lists the engines explicitly: Claude Code, Codex, Kimi Code, OpenClaw, Hermes Agent, OpenCode, Qwen Code, DeepSeek-TUI, plus a built-in runtime. Above that sits a provider layer covering OpenAI, Anthropic Claude, Google Gemini, DeepSeek, Qwen, Moonshot, Ollama, OpenRouter, GitHub Copilot and custom OpenAI-compatible endpoints, which is what makes per-engine model routing possible without editing each CLI's own config.

Two other pieces are visible in the layout. A top-level openclaw-extensions directory and an openclaw block in package.json pin OpenClaw v2026.3.2 and a set of channel plugins: dingtalk, feishu-openclaw-plugin, openclaw-qqbot, wecom-openclaw-plugin, openclaw-weixin, openclaw-nim, openclaw-netease-bee and an optional moltbot-popo from a private registry. That plugin list is the clearest signal of who the IM Agent Hub is built for: teams whose chat traffic runs through Feishu, DingTalk, WeCom, QQ or WeChat rather than Slack. The runtime dashboard then measures each call by engine, model, source, status, tokens, completion time, TTFT, output-phase TPS, estimated model TPS, tool latency and agent steps.

Installing WeSight and pointing it at an agent you already have

The README directs users to the releases page for a signed and notarized macOS build for Apple Silicon and Intel, or a Windows x64 installer. There is no package-manager install line in the README, so the realistic first step is downloading the installer rather than running a command.

If you want to build from source instead, the repository is a standard Node project. The engines field constrains Node to the 24.x line, so check that before anything else.

node --version
npm install
npm run dev

The dev script runs Vite, which starts the renderer for the Electron shell. Expect the app window to open against your local source tree rather than a packaged build.

For a distributable build, the README's scripts include a combined compile step:

npm run build

On macOS, the README states that WeSight can install supported local CLIs or detect the ones already present. The intended first real use is to open Agent Engines, let it detect an existing Claude Code or Codex install, and confirm that WeSight reuses your current account and config rather than asking you to sign in again. From there, open a Cowork chat, pick the engine, pick the model, and send a task. The Live Workspace panel on the right is where file writes and tool activity should appear while the agent works.

Where WeSight stops being the right tool

Platform coverage is the first hard boundary. The README advertises macOS for Apple Silicon and Intel and Windows x64. Linux is not listed, and neither the README nor package.json suggests a Linux build target. If your team develops on Linux, WeSight is not a candidate regardless of how well the feature list matches your needs.

The one-click CLI installation is also scoped. The README says that on macOS WeSight can install supported local CLIs or detect existing ones. It does not make the same claim for Windows, where the installer appears to be the distribution channel. A Windows user should expect to bring their own agent CLIs and let WeSight detect them, not the reverse.

There is a subtler cost. WeSight sits between you and the CLI, which means your agent's behaviour now depends on two config layers: the CLI's own files and WeSight's provider and engine settings. The README says WeSight can reuse existing accounts and config, but it does not document precedence when the two disagree, nor does it describe rollback if an engine install goes wrong. For a debugging session where you need to see raw CLI output, dropping back to the terminal is still the faster path.

WeSight against a terminal multiplexer and a bare CLI

The obvious alternative is what most people already do: run each agent in its own terminal pane, managed by tmux or Windows Terminal, and keep provider keys in each CLI's config. That approach has no Electron process, no build step, and no version skew between the app and the CLIs it wraps. It also works over SSH and in CI, which WeSight's README does not describe.

The difference in approach is where state lives. A terminal setup keeps routing and permissions inside each CLI, so switching a model means editing that CLI's config or passing a flag. WeSight centralises routing in a provider layer shared across engines and records metrics per call. You gain a single view of token usage, TTFT and tool latency across engines, and you lose the ability to reason about one agent in isolation without also reasoning about WeSight's settings.

A closer comparison is a general-purpose chat client that speaks to model APIs. Those give you a conversation and nothing else: no CLI installation, no file diffs, no per-engine bot profiles. WeSight's value is concentrated in the parts a chat client omits, which is also why it is heavier and more opinionated about how you work.

Maintenance, releases and what the MIT licence leaves you to decide

The last push to main was on 2026-08-24, the same day v1.0.6 was tagged, with v1.0.5 earlier that day and v1.0.4 on 2026-08-03. The repository is not archived. That is a recent, clustered release pattern, but a single month of activity is not a maintenance guarantee, and the README does not publish a support window or a deprecation policy for engines.

Upgrade cost is driven by the engines, not by WeSight itself. package.json pins OpenClaw v2026.3.2 and specific plugin versions such as @larksuiteoapi/feishu-openclaw-plugin 2026.3.8 and @tencent-connect/openclaw-qqbot 1.6.4. When an upstream CLI changes its event format or config layout, WeSight has to follow, and until it does, the affected engine may misbehave inside the app while still working in a terminal. Budget for that lag if you depend on a fast-moving engine.

The project is MIT licensed, which is permissive and places few obligations on how you redistribute or modify it. That is a statement about the licence text, not legal advice. What MIT does not settle is the licensing of the agent CLIs and the IM plugins WeSight orchestrates, each of which carries its own terms. If you plan to ship WeSight inside a commercial product, the engine and plugin licences are the ones to read, not WeSight's.

Editorial conclusion

Adopt WeSight if you already run two or more local coding CLIs on macOS or Windows and want one place to configure providers, watch token and latency metrics, and route Feishu messages into an agent. Skip it if you work on Linux, if you prefer a terminal-only workflow, or if you need a documented headless or CI path, because the README does not describe one. Before committing, verify three things on your own machine: that the signed and notarized macOS build or the Windows x64 installer covers your CPU, that WeSight detects the CLIs you already have rather than reinstalling them, and that the model providers you actually pay for appear in the unified provider list.

Frequently asked questions

Official sources

1. freestylefly/wesight on GitHub
2. License: MIT
3. Project website
4. README
5. Releases