QwenPaw: a self-hosted personal AI assistant that runs on your own machine

The problem QwenPaw targets: an assistant that stays on your hardware

Most assistant products are hosted services. You send messages to someone else's endpoint, and the conversation history lives in their database. QwenPaw takes the opposite position. Its README states that all data and tasks run on your machine, with no third-party hosting and no data upload, and that you can deploy it locally or in the cloud. The package description in pyproject.toml repeats the claim: it talks to you over multiple channels and runs scheduled tasks according to your configuration.

The intended user is someone who already runs a home server or a small cloud VM and wants an assistant reachable from the chat apps they already use. The README lists DingTalk, Lark, WeChat, Discord, Telegram, iMessage and QQ as channels, plus a console, a terminal UI and a desktop app. That is a self-hosting audience, not a consumer one. The dependency list confirms it: discord-py, dingtalk-stream, lark-oapi, python-telegram-bot, slack-bolt, twilio, matrix-nio and paho-mqtt all appear in pyproject.toml, so each channel is a real integration rather than a webhook shim.

The second audience is people who want scheduled automation without writing a scheduler. The README describes recurring tasks such as news digests, report generation and multi-channel broadcasting, with apscheduler in the dependency list behind them.

Agent OS, Skills and the three-layer memory

QwenPaw 2.0 was a ground-up rewrite on AgentScope 2.0, and the README calls the result an Agent OS architecture. Three parts are described per agent: Resources, which are transparent on disk; Governance, which decides allow, deny, ask or sandbox; and Sandbox, with implementations for macOS, Linux and Windows. A separate driver layer connects MCP, A2A and ACP protocols, with encrypted credentials and a per-call policy gate.

The memory model is the most specific claim in the README. It describes three layers: live working context, full verbatim history, and a self-evolving personal knowledge base built on ReMe. A related feature called Scroll Context persists every turn and indexes evicted turns for on-demand recall, so nothing is summarized away. Whether that holds at scale is not something the README quantifies, and I would treat the phrase as a design intent rather than a measured property.

Skills are the extension unit. The README names cron, PDF and Office handling, news digest and file reading as built-in examples, and pyproject.toml pins several ReMe packages (reme-ai, reme-auto-fin, reme-daily-paper) that back some of them. Plugins are a separate layer with a marketplace. The split matters: a Skill is a capability the assistant can invoke, a plugin is a package you install. The README does not draw that boundary explicitly, which is a gap if you plan to write your own.

Installing QwenPaw and running a first task

The project is published on PyPI as qwenpaw, and pyproject.toml sets requires-python to >=3.11,<3.14. Pick a Python in that range before anything else, because the upper bound excludes 3.14.

python3.12 -m venv .venv
source .venv/bin/activate
pip install qwenpaw

After installation the qwenpaw package is importable and the console entry point is available. The README points to the documentation site for the full quick start, so the exact first-run command is not reproduced in the repository README itself. Check the installed package's entry points if the command name is not obvious.

If you prefer containers, the repository ships a docker-compose.yml that pulls a prebuilt image and publishes the console on port 8088, bound to localhost only.

services:
  qwenpaw:
    image: agentscope/qwenpaw:latest
    init: true
    container_name: qwenpaw
    restart: always
    ports:
      - "127.0.0.1:8088:8088"
    volumes:
      - qwenpaw-data:/app/working
      - qwenpaw-secrets:/app/working.secret
      - qwenpaw-backups:/app/working.backups

The three named volumes are the important part. qwenpaw-data holds the working directory, qwenpaw-secrets holds credentials, and qwenpaw-backups is separate. The compose file also shows commented-out authentication variables, and this is worth reading carefully rather than skimming.

    # environment:
    #   - QWENPAW_AUTH_ENABLED=true
    #   - QWENPAW_AUTH_USERNAME=admin
    #   - QWENPAW_AUTH_PASSWORD=yourpassword

They are commented out in the file as published. The port binding to 127.0.0.1 is what keeps that from being immediately dangerous, but if you change the binding to expose the console on a network interface, enable those variables in the same edit. The README does not state what the console exposes without them.

Where QwenPaw is the wrong tool

The release history is the first limitation. The three most recent releases are v2.2.0-beta.1, v2.2.0-beta.2 and v2.2.0-beta.3, all dated 2026-08-27 and 2026-08-28. Nothing in the repository shows a stable v2.2.0. If your deployment policy requires non-beta releases, you are pinned to an older line, and the README does not describe an upgrade or rollback procedure between major versions. A 2.0 rewrite that changed the workspace, memory and driver layers is exactly the kind of change where an upgrade path matters, and its absence is a real gap rather than a documentation nicety.

The second limitation is scope. QwenPaw is a personal assistant, not an embeddable agent framework. It ships its own console, its own session model and its own scheduler. If you want a library to build an agent into an existing product, the dependency on AgentScope is the relevant fact: you would more likely start from AgentScope directly and skip the assistant shell.

The third is operational surface. The dependency list is long and includes browser automation (playwright), desktop embedding (pywebview), screen capture (mss), ONNX runtime and a keyring integration. Each of those has its own system requirements. A headless Linux container will not exercise the desktop path, and the README does not map which features degrade when a dependency is unavailable. Expect to spend time on that mapping yourself.

QwenPaw vs a general agent framework

The closest comparison in the repository is AgentScope, the framework QwenPaw is built on. The difference is packaging, not capability. AgentScope gives you the agent primitives and leaves session storage, channel adapters and scheduling to you. QwenPaw ships those as part of the product: a console on port 8088, a scheduler backed by apscheduler, and channel adapters for a specific list of chat apps. Choosing QwenPaw means accepting its decisions about where data lives and how sessions are stored; choosing AgentScope means making those decisions yourself.

The README also refers to QwenPaw-Flash, a family of 2B, 4B and 9B models trained for agent tasks, with a built-in local runtime that needs no API key. That is a third position: not a framework and not a hosted model, but a bundled model plus harness. The README states it also works with Ollama, LM Studio and more than 14 cloud providers, so the local models are a default rather than a lock-in. If you already run a model server, pointing QwenPaw at it is the configuration to look for first.

Licence, upgrade cost and what to verify

QwenPaw is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files, and it includes a patent grant. The repository also carries a SECURITY.md, which is the file to read for the project's own vulnerability reporting process. Nothing here is legal advice; if you redistribute QwenPaw inside a product, read the LICENSE file in the repository rather than a summary.

Upgrade cost is the open question. The repository contains a RELEASING.md and RELEASING_zh.md, which describe the maintainers' release process rather than a user-facing upgrade path, and the README does not document rollback. The docker-compose.yml separates qwenpaw-data from qwenpaw-backups, which suggests the intended practice is to snapshot the data volume before pulling a new image. That is an inference from the file layout, not a documented procedure. Before upgrading across a major version, copy the qwenpaw-data volume and confirm that the new image reads the same working directory layout.

The last push to the repository was on 2026-08-28, and the newest releases are beta builds from the same day. The project is not archived, but the beta-only release line is the fact that should shape your adoption timing.

Editorial conclusion

Adopt QwenPaw if you want a personal assistant whose data stays on hardware you control and you are comfortable reading a Python repository to fill in gaps the README leaves. Do not adopt it if you need a documented, versioned API surface or a stable release line: the newest published releases are v2.2.0 beta builds, and the README does not document rollback or upgrade paths. Before committing, verify the Python version constraint (requires-python is >=3.11,<3.14), confirm which model backend you will point it at, and check the SECURITY.md file for the project's own vulnerability reporting process.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes