ProactiveAgent: A Proactive LLM Agent That Watches Your Screen and Proposes Tasks
A LLM-based Agent that predict its tasks proactively.
At a glance
- What is it?
- ProactiveAgent is a research release from Tsinghua's THUNLP group that couples an ActivityWatch-based environment monitor with an LLM agent that proposes tasks before you ask. The repository ships a data pipeline, annotated datasets, and a reward model, but the user-facing agent is still a research prototype with a thin integration story.
- Who is it for?
- ProactiveAgent is worth adopting if you are a researcher studying proactive agents, human-in-the-loop task suggestion, or reward-model-based filtering, and you want the 6,790-event dataset and the generation pipeline rather than a finished desktop product.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 127 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem ProactiveAgent Targets: Assistance Before the Request
Most LLM agents are reactive. You type a prompt, the model responds. ProactiveAgent inverts that loop: the agent watches what you are doing on your desktop and proposes an action or task before you ask for one. The README states the project "aims to construct a fully active agent, who may anticipate user's requirements and take the initiative, offering assistance and suggesting actions without explicit requests from user." That is the whole thesis. The intended user is not a general consumer; it is a researcher or engineer who wants to study whether an LLM can infer intent from activity traces and whether a reward model can filter bad proposals before they reach the user. The repository ships three things: a data collection and generation pipeline, annotated datasets split across coding, writing, and daily life, and prompts plus scripts to fine-tune an LLM for proactive behavior. If you want a plug-and-play desktop assistant, this is not it. If you want a reproducible testbed for proactive suggestion, the pieces are here.
How the Pipeline Fits Together: Activity Watcher, Environment Gym, Agent, Reward Model
The architecture visible in the README has four named components. First, Activity Watcher (an external project, activitywatch.net) collects human traces: the README says the team uses it "to collect the human traces across all the scenes." Second, the Environment Gym generates training instances; the README states "All the training instances for the Proactive Agent were generated from our GYM." Third, the Proactive Agent itself consumes those instances and produces proposals. Fourth, a Reward Model scores proposals, and the README reports it reaches a 0.918 F1 score on the test set. The data flow is: raw desktop events from ActivityWatch feed the Gym, the Gym emits synthetic task instances, the agent is trained or prompted on those instances, and the reward model acts as a filter at inference time. The README also describes a Dynamic Generation loop where "the feedback from user could affect events afterwards," meaning accept, reject, or ignore signals from the toast UI feed back into what the agent proposes next. The dataset spans 136 instances and 6,790 events across coding (46 instances, 2,275 events), writing (46, 2,354), and daily life (44, 2,161). Those numbers come from the README table and are the only scale figures I can confirm.
Getting ProactiveAgent Running: Commands and Config Keys
The README gives a concrete install sequence. Clone with `git clone git@github.com:thunlp/ProactiveAgent`, then `cd ProactiveAgent`. Create a Python 3.10 environment with `conda create -n activeagent python=3.10` and `conda activate activeagent`, then `pip install -r requirements.txt`. ActivityWatch is a separate install: download the main app from the official site, load the Chrome extension from `./agent/resource/aw-watcher-web.zip` via `chrome://extensions/` or `edge://extensions/` with developer mode on, and for VS Code install `aw-watcher-vscode` from the marketplace. The README says to verify by opening `http://localhost:5600/#/timeline` and checking that four traces appear: `afk`, `vscode`, `window`, and `web`. Configuration is a TOML file: copy `example_config.toml` to `private.toml` and set `default_completions_model`, `api_key`, and `base_url`. To run the agent, enter `./agent` and follow that folder's README. The reward model connection is documented as "__TO BE UPDATE__," so you cannot wire it up from the README alone. The interaction model is toast-based: click the toast body (Windows) or button (macOS) to accept, click the dismiss x to reject, or do nothing to ignore. The README states ignoring makes the agent "try to make less proposal in the following turns."
What the Reward Model Does and What the 0.918 F1 Does Not Tell You
The reward model is presented as an automatic evaluator for proactive behavior. The README defines three evaluation categories: Missed-Needed (MN), where the user needs help and the agent stays silent; Non-Response (NR), where the user does not need help and the agent correctly stays silent; and Correct-Detection (CD), where the user needs help and the agent detects it. The reported 0.918 F1 is on the test set, and the README frames it as "a good indicator of the performance of the Proactive Agent." Two caveats apply. First, the F1 is for the reward model's agreement with human annotators, not for the agent's real-world usefulness; a high-agreement judge can still bless proposals users find annoying. Second, the README does not break the F1 down by scenario (coding, writing, daily life), so you cannot tell from the supplied material whether performance is uniform or skewed toward one domain. The README also does not report latency, cost per proposal, or how often the agent fires. Those gaps matter if you plan to deploy this against a paid API, because every proposal consumes tokens.
The Integration Gap and Other Limits You Should Know Before Adopting
The most concrete limitation is stated in the README itself: the section titled "Connect the Reward Model" ends with "__TO BE UPDATE__." That means the filtering component, the one the project uses to justify its evaluation numbers, is not documented as connected. You can run the agent, and you can run the reward model, but the README does not tell you how to join them. A second limit is platform coverage. The Chrome extension is shipped as a zip under `./agent/resource/` and the README says it "is not tested under Safari," so macOS Safari users are on their own. A third limit is scope: the README states ProactiveAgent "is intended for coding, writing and daily life scenarios only at present." If your work is in another domain, the 136 instances likely do not represent it. A fourth issue is the dependency on ActivityWatch running locally with four watchers active. If any watcher is missing, the agent's view of your activity is incomplete, and the README gives no fallback behavior for partial traces. Finally, the repository has no tagged releases, so you are tracking `main`.
Alternatives and the Actual Difference in Approach
The clearest alternative in the same space is ActivityWatch itself, which ProactiveAgent already depends on. ActivityWatch is a passive time tracker: it records `afk`, `window`, `web`, and editor events and presents them in a timeline at `http://localhost:5600/#/timeline`. It does not call an LLM, does not propose tasks, and does not ship a reward model. ProactiveAgent sits on top of that data and adds the inference and suggestion layers. The trade-off is direct: ActivityWatch is a stable, widely used desktop application with no API key requirement, while ProactiveAgent adds an LLM dependency, a TOML config with `api_key` and `base_url`, and a research-grade pipeline whose reward-model hookup is unfinished. If your goal is to understand your own time allocation, ActivityWatch alone is sufficient and cheaper. If your goal is to test whether an agent can anticipate needs from that same data, ProactiveAgent provides the scaffolding, the annotated test set, and the prompts. The two are not competitors so much as layers, which is worth noting because it means adopting ProactiveAgent does not replace your ActivityWatch install.
Maintenance, Licence, and What to Check First
The repository is Apache-2.0 and not archived. There are no tagged releases, and the last push recorded is 2026-05-12, so the project is active but versioned only by commit. The README lists two news items: the paper was accepted by ICLR 2025 on 2025-01-22, and the Proactive Agent and Reward Agent models were released on 2025-03-21 with weights at Hugging Face under `YancyLee/ProactiveAgent`. The README also states a forward intention: "we will continually improve the data quality and increase the coverage of real-world scenarios." Treat that as a stated plan, not a commitment with a date. On licence: Apache-2.0 permits commercial and private use and modification, and requires that you retain copyright and attribution notices and state significant changes. The dataset carries its own note that it covers coding, writing, and daily life only and "should not be constructed as reflecting the opinions or views of the creators, owners, or contributors." I am not a lawyer and this is not legal advice. Before you build on it, check three things: whether the Hugging Face checkpoint matches the config keys in `example_config.toml`, whether your ActivityWatch install actually emits all four traces at `localhost:5600`, and whether the reward-model wiring has moved out of "__TO BE UPDATE__" since the last commit you can see.
Editorial conclusion
ProactiveAgent is worth adopting if you are a researcher studying proactive agents, human-in-the-loop task suggestion, or reward-model-based filtering, and you want the 6,790-event dataset and the generation pipeline rather than a finished desktop product. It is the wrong tool if you need a stable end-user assistant: the reward model integration is marked TO BE UPDATE, the browser extension is untested on Safari, and the whole stack presumes ActivityWatch running locally on port 5600. Before committing, verify that your target scenario (coding, writing, or daily life) is covered by the 136 instances, and confirm the reward model weights on Hugging Face match the checkpoint your pipeline expects. The project is Apache-2.0, so redistribution and modification are permitted, but you inherit the obligation to preserve attribution notices and the dataset's own usage caveats.
Community notes