Model or dataset
User0332/rewards-farmer avatar
User0332/rewards-farmer

User0332/rewards-farmer: a Selenium bot that farms Microsoft Rewards points from a real Edge profile

Automation for MS Rewards based on https://youtu.be/4qdPcMNaioA

881 stars146 forksPythonMIT

At a glance

What is it?
rewards-farmer drives Microsoft Edge through Selenium to complete Microsoft Rewards tasks, generating its search strings with either a local Ollama model or public trend feeds. It is a personal automation script with a blunt warning attached, and the Docker path has a hard Windows limitation.
Who is it for?
Use rewards-farmer only if you accept the README's own warning that Microsoft may take action against accounts for automated point collection, and only if you can run it on a Linux host or run the script directly on Windows. Do not adopt it on a Windows host through the Docker path, because the README states that Chromium's DPAPI-wrapped cookie key cannot be unwrapped in the Linux container and the profile arrives effectively logged out.
Can I use it commercially?
Yes. MIT 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 3 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 16, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What rewards-farmer automates and who it is written for

Microsoft Rewards pays points for searches, quizzes and a visual search task, and collecting them by hand means repeating the same small actions every day. rewards-farmer exists to do that repetition for you. It launches Microsoft Edge under Selenium, works through the Rewards tasks, and types generated short strings into Bing instead of asking you to think of them. The README frames the whole project around a single YouTube video, and it says the video contains more details about the techniques implemented to avoid detection. That framing tells you who this is for: one person automating their own account, not a team building a product. There is no service, no API, no dashboard. The repository is a Python script with a nouns.txt seed file, a Poetry lockfile and a compose file. The README's second line is a warning in capitals that you use it at your own risk and that Microsoft may take action against your account. Treat that as the project's own statement of its risk profile, because it is.

Where the search queries come from: llm versus trends

The bot needs short strings to type into Bing, and the README describes two backends selected by the QUERY_SOURCE environment variable. The default is llm, which sends seed words to an Ollama model and asks it to complete twenty searches. That path needs an Ollama account, the ollama tool installed, a sign-in through ollama signin, and a model download; the README names gemma4:cloud and says the project uses a minimal amount of Ollama cloud usage. Swapping models means editing the model parameter in the get_ollama_response function in src/llm_utils.py, which is a source change rather than a config key. The second backend, trends, pulls from Google Trends, Wikipedia and Bing autosuggest and needs no account, no API key and no model. The README states that if every feed is unreachable it falls back to nouns.txt rather than failing the run. That fallback is the more interesting design decision here: a query source that can silently degrade to a static wordlist will still produce a run, but the searches stop reflecting anything current, and nothing in the described behaviour halts to tell you that happened.

Installing rewards-farmer and getting through the first sign-in

The README requires Python 3.12 or newer and Poetry, and it notes that you may have to use python -m poetry instead of poetry. Clone the repository and install the dependencies:

sh
git clone https://github.com/User0332/rewards-farmer
cd rewards-farmer
poetry install
eval $(poetry env activate)

On Windows PowerShell the activation line is iex (poetry env activate). The README documents a specific failure there: if that command reports that it cannot bind an argument to parameter Command because it is null, poetry install did not create an environment, and the usual cause is an older Python. You also need a webdriver for Microsoft Edge, which the README says you probably already have if Edge is installed. The first run is deliberately incomplete. Start the script from the repository root so the relative paths resolve, then stop it:

sh
python src/main.py

The README says to wait for the page to launch and then press CTRL-C. In the profile that was created, sign in to your Microsoft account on both Bing and rewards.bing.com. European users may have to accept a consent banner once on each site; the README states the choice is saved for future runs on the same profile. Close all webdriver browser instances and run main.py again, and the automation should start working. The visual search task needs an image, and the repository includes a helper that downloads one from Wikipedia:

sh
python src/random_image_for_visual_search.py

That writes visual_search.jpg into the project root. If you supply your own image instead, the README says to put its absolute path in the VISUAL_SEARCH_IMAGE_PATH constant at the top of rewards_tasks.py.

Running several Microsoft accounts, one profile directory each

Rewards is per Microsoft account and the browser profile holds the sign-in, so in this project an account is a profile directory. REWARDS_ACCOUNTS takes a comma separated list, and each name gets its own directory under data-dir:

sh
REWARDS_ACCOUNTS=personal,spare python src/main.py

Each account is signed in once by hand using its own directory, with a command the README gives in the form msedge --user-data-dir="<repo>\data-dir\personal" --profile-directory=Default https://rewards.bing.com. The accounts then run one after another. The README states that an account which fails is reported and skipped rather than ending the run, whether it fails to start or dies partway through, which is the right behaviour for a batch of profiles but also means a partial run looks like a finished one unless you read the output. Leave REWARDS_ACCOUNTS unset and the script uses the single profile in data-dir. The profile name itself is a constant: src/constants.py sets the profile directory to Default, and the README suggests creating a new profile manually and changing PROFILE_NAME to Profile 1 if Default signs you into a global profile you do not want to automate.

The Docker path, and why it does not work from a Windows host

The compose file builds an image that carries Edge, a matching Edge driver and the Python dependencies, so the host needs none of them. The container defaults to QUERY_SOURCE=trends, which is why it needs no Ollama account, and it sets REWARDS_HEADLESS to 1. The build pins the driver to the Edge version the image layer installed rather than to latest, because the Dockerfile comment notes those drift apart between releases. Two commands are given:

sh
docker compose build
docker compose run --rm rewards-farmer

Sign-in still has to happen once on the host, because the profile in data-dir starts logged out and the container has no display. The README is unusually direct about the consequence on Windows: Chromium encrypts cookie values with a key held by the operating system, and on Windows that key is wrapped with DPAPI and tied to the Windows account that wrote it. The Linux container cannot unwrap it, so cookies are unreadable. The README reports that a profile signed in on the host showed 73 cookies on disk, of which Edge in the container could read 19, the ones it had just set itself, while .MSA.Auth and ANON came back absent. The container starts, looks healthy and behaves as though it were logged out. On a Windows host the README's answer is to run python src/main.py directly. A Linux host does work, because with no keyring running Chromium falls back to a fixed key. There are two more operational traps in the compose file: Chromium needs more than the default 64MB of shared memory, so shm_size is set to 1gb, and visual_search.jpg is mounted read-only, so a path that does not exist yet is mounted as an empty directory rather than a file. The README also warns that Chromium allows one process per profile directory, and that a profile whose browser was killed keeps a SingletonLock naming the machine that wrote it, which the container reads as the profile being open elsewhere.

A real alternative: a userscript in the browser you already use

The related searches around this project point at a different family of tools, userscripts such as Tampermonkey-based Rewards automators, and the difference in approach is worth stating plainly. A userscript runs inside your existing browser session. There is no profile directory to create, no webdriver to match to a browser build, no Python environment, no container, and no sign-in step to perform twice. The bot here takes the opposite route: it drives a separate Edge instance through Selenium, which is why it needs a driver, a profile, and a first manual run before automation works at all. The trade-off is control. Because rewards-farmer owns the browser process, it can set a query source, run headless, rotate across named accounts in sequence, and skip an account that dies without ending the batch. A userscript generally cannot do those things. If you want a single account automated with the least setup, the userscript shape is simpler. If you want several profiles run unattended in order, or a container that needs nothing installed on the host, the Selenium approach is the one that supports it.

Maintenance cost, licence and what the repository does not promise

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole licence implication here; nothing in the repository adds terms on top of it. Maintenance is the weaker signal. The last push was on 2026-09-13, three days before this writing, and the repository is not archived, so the code is current. But there are no releases, so there is no version to pin to and no changelog to read before upgrading. Upgrades mean pulling the branch and re-running poetry install against a lockfile that pins selenium to the 4.46 line, which matters because the Dockerfile pins msedgedriver to the Edge build the image installed. A host upgrade that moves Edge forward without moving the driver leaves you with a mismatch, and that is the failure you are most likely to meet after a working setup. The README does not document rollback, does not describe a test suite beyond the presence of a tests directory, and does not state a support commitment. The pyproject file lists matplotlib, pygetwindow, keyboard and pygame-ce as dependencies, but the Dockerfile comment says those belong to the recording and visualisation scripts and that two of them are Windows-only, so the container installs only what a run reaches. That split is worth knowing before you assume the dependency list describes the runtime.

Editorial conclusion

Use rewards-farmer only if you accept the README's own warning that Microsoft may take action against accounts for automated point collection, and only if you can run it on a Linux host or run the script directly on Windows. Do not adopt it on a Windows host through the Docker path, because the README states that Chromium's DPAPI-wrapped cookie key cannot be unwrapped in the Linux container and the profile arrives effectively logged out. Before a first real run, verify three things: that your Python is 3.12 or newer so poetry env activate has something to bind to, that the Edge webdriver matches your installed Edge build, and that visual_search.jpg exists in the project root, since the compose file mounts a missing path as an empty directory rather than a file.

Frequently asked questions

Does rewards-farmer need an Ollama account to run?

Not if you set QUERY_SOURCE to trends, which pulls from Google Trends, Wikipedia and Bing autosuggest and needs no account, API key or model download. The default is llm, which does need an Ollama account, the ollama tool and a sign-in through ollama signin. The Docker compose file defaults to trends for this reason.

Can I run rewards-farmer with Docker on Windows?

The README states that it does not work from a Windows host. Chromium encrypts cookie values with a key wrapped by DPAPI and tied to the Windows account, which the Linux container cannot unwrap, so the profile arrives effectively logged out. On a Windows host the README says to run python src/main.py directly.

How do I automate more than one Microsoft Rewards account with rewards-farmer?

Set REWARDS_ACCOUNTS to a comma separated list, for example personal,spare, so each name gets its own directory under data-dir. Each account is signed in once by hand using its own profile directory. They run one after another, and an account that fails is reported and skipped rather than ending the run.

Is using rewards-farmer against the Microsoft Rewards rules?

The README opens with a warning that you use it at your own risk and that Microsoft may take action against your account for using automated scripts to gain rewards points. It points to the linked YouTube video for details about the techniques implemented to avoid detection.

Official sources

  1. Issues
  2. License: MIT
  3. Project website
  4. README
  5. User0332/rewards-farmer on GitHub
Community notes

Community notes