One assistant can follow you across several interfaces
QwenPaw keeps the same agent, memory, sessions, skills, and MCP tools available through its browser console, terminal interface, desktop client, and supported messaging services. That continuity is the point. A scheduled report can run in the same workspace used for an interactive chat, while editable Markdown memory gives the operator something inspectable instead of an opaque profile. The project also supports local models and more than a dozen cloud providers.
The breadth comes with weight. Our checkout contained 4,372 files and roughly 989,080 lines of source before installation added 277 packages. QwenPaw covers agent workspaces, sub-agents, plugins, cron jobs, browser tooling, messaging drivers, model management, permissions, backup handling, and a web console. A developer who wants only a private chat page will spend time learning machinery that solves problems they do not have.
Local models remove API keys, not operating work
QwenPaw can use its built-in local runtime, Ollama, or LM Studio without a cloud model key. The supplied QwenPaw-Flash family has several model sizes and quantizations, and the console helps select one. Cloud models are configured through the console, an initialization prompt, or environment variables. Extra tools such as web search bring their own keys, so secret inventory grows with capability.
A 999 MB Python installation is only the base layer we measured. Local model weights consume additional storage and must fit the machine's memory and compute limits. Ollama needs a context length of at least 32k according to the README, while LM Studio must expose its local server. In Docker, a model service on the host is not reachable as localhost; the documentation gives host-gateway and Linux host-network alternatives.
Permissions matter because the agent can act
This system can run shell commands, browse, read files, schedule jobs, install skills, call MCP servers, and post into communication channels. QwenPaw answers that risk with platform-specific sandboxes, per-tool approval rules, a file guard, skill scanning, and an access policy. Those controls are useful, but their presence should change the deployment conversation: an exposed console or over-permissive channel connection can reach much more than a normal chatbot.
The repository had 33 CI workflow files at commit 3f13a7b, which fits the number of platforms and integration paths being maintained. The Docker example binds the console to 127.0.0.1, stores normal data and secrets in separate volumes, and warns users to keep ModelScope deployments non-public. Those are sensible defaults. Operators still need to decide which tools can run automatically, which paths are protected, and who can send commands through each channel.
What happened when we ran it
Our sandbox install succeeded in 108 seconds. It pulled 277 packages and occupied 999 MB on disk, a substantial footprint before any local model download or accumulated memory. The build passed in 7 seconds. pip-audit reported 0 known vulnerabilities in the installed Python environment at that commit.
The test command did not complete before our 900-second cap. The final log lines did not show a crash or a clear failing assertion. They showed an app server returning 200 OK for health, cron deletion, and chat deletion requests, followed by workspace initialization, service reuse, memory-manager startup, and more progress markers. We can say the suite exceeded our window; the tail does not establish why.
That distinction matters for evaluation. A 900-second timeout makes full verification expensive on the 3-CPU, 8 GB sandbox we used, even though installation and compilation were uneventful. Teams changing core behavior should budget for a longer test job or use the repository's own split CI structure. Treating the green build as a substitute for the unfinished suite would hide the main result of our run.
The desktop shortcut is still a beta path
The pip route requires Python 3.11 through 3.13. A script installer can set up uv, Python dependencies, Node.js, and frontend assets, while published Docker images offer another path. The desktop application is easier to approach, but its own documentation warns that compatibility coverage is incomplete and that performance or features may still be unstable. macOS packages may also require a manual Gatekeeper approval because the app is not notarized.
Recent issue activity gives those warnings substance. An open v2.1.0 report describes legacy MCP migration creating a credential reference without a corresponding entry when a client has an empty environment; the reported result is that the MCP tools fail to register on new sessions. Another report concerns the bundled desktop TLS stack on certain carrier networks. Both are specific edge cases, yet they touch exactly the integrations that make QwenPaw attractive.
Active development does not make the queue small
GitHub showed 34,467 stars, a last push on 2026-08-26, and release v2.1.0 published on 2026-08-13. The open count was 910 issues and pull requests combined, so it cannot be read as 910 confirmed defects. Current discussions and patches covered desktop packaging, MCP migration, model handling, test coverage, and channels. This is busy software with a busy queue.
QwenPaw earns consideration when one assistant genuinely needs to persist across devices, tools, and communication systems. The 73.1 MB checkout, 999 MB installed environment, and unfinished 900-second test run set the correct expectation: ownership resembles operating an application platform. If that platform replaces several bits of custom glue, the cost can make sense. If chat is the whole requirement, Open WebUI is the simpler first trial.