Cookie robot
Warming up a profile
- 30
- Addresses in the built-in pool
- 6
- Groups to choose from
- 6
- Steps per address
- 1 to 40
- Sites per run
A profile with nothing behind it is itself a signal
Every fingerprint answer can be correct and the profile still stands out. A browser someone has actually used carries cookies from sites they never think about, entries in history, cached files, favicons, a pile of stored preferences. A profile created a few minutes ago carries none of that.
It is the same shape as an incognito window: right on paper, empty behind. A VPN changes the address you arrive from and nothing about the jar. A virtual machine hands you a whole clean computer, which has exactly the same emptiness one level up.
The robot spends time in the profile before you do. It opens ordinary public pages, lets them set their own cookies, scrolls, waits, moves on. By the time you sign in, the profile is a browser with a few hours behind it instead of nothing.
What this is and is not
What the robot does inside the profile
Starting a run launches that profile the ordinary way: its own fingerprint, its own proxy, its own storage folder, inside ARMANOS Browser 153.0.7978.0 when the fork is installed. Nothing is fetched on the side and nothing is injected afterwards. Cookies land the way cookies always land, set by the site, in the profile's own session.
Every address gets the same six steps. Open the page and wait for it to load, up to twenty seconds. Pause while it settles. Scroll, pause, scroll again, then pause longer before the next address.
The timing is a range, not a number. The seconds you pick are the centre; each real pause falls between 60 and 140 percent of it, and the three pauses take roughly a quarter, a third and a half of that spread. Scroll distances are drawn too: 400 to 1100 pixels, then 300 to 1200. A fixed rhythm repeated across thirty pages and ten profiles would be a pattern of its own.
- 1
Open
Navigate to the address and wait for the load event, with a twenty second ceiling.
- 2
Settle
A short random pause so scripts and images finish before anything touches the page.
- 3
Scroll
Move down 400 to 1100 pixels, the way a person skims the top of a page.
- 4
Read
A second random pause, the longest share of the dwell so far.
- 5
Scroll again
Another 300 to 1200 pixels further down.
- 6
Leave
A final pause, then the next address.
Ten profiles do not get ten identical histories
Selection and order are decided per profile, not per run. The run driver asks the flow for its steps once for each profile, and the robot answers with a fresh shuffle every time. Launch nine profiles into one run and you get nine different lists in nine different orders.
The shuffle is Fisher-Yates over a copy of the pool. Sorting by a random comparator is the common shortcut and it is biased: some orders come up far more often than others, which is the opposite of what this feature is for.
The reason is plain. Two profiles that visited the same nine sites in the same order inside the same minute have just traded one correlator for another. The stand draws the first position six hundred times and fails if one address wins more than fifteen percent of them, or if fewer than sixty percent of the pool ever comes up first.
Which addresses
Drawn from the groups you ticked, or from your own list.
In what order
Shuffled again for every profile in the run.
How long on each
Three pauses per page, each one drawn from the range.
How far down each page
Two scroll distances, drawn per step.
The pool is thirty public addresses that never ask you to sign in
Six groups, thirty addresses, all https, none repeated between groups. Nothing in the pool needs an account. A robot that lands on a sign-in wall produces no history at all, plus a run of failed sessions, which is worse than doing nothing.
Tick the groups that match what the profile is for. A shop profile can lean on shopping and search; a social profile on video and forums. Untick everything you do not want and the robot never touches it.
Or paste your own list instead. One address per line, http or https only, up to sixty of them. Your list replaces the groups completely, and the window says so before you start.
| Group | Addresses | What is in it |
|---|---|---|
| Search | 4 | Bing, DuckDuckGo, Brave Search, Ecosia |
| News | 6 | BBC, Reuters, The Guardian, AP, Al Jazeera, DW |
| Shopping | 5 | eBay, Etsy, AliExpress, IKEA, Zalando |
| Reference | 5 | Wikipedia, Stack Overflow, GitHub, IMDb, Archive.org |
| Video and forums | 5 | YouTube, Reddit, Pinterest, Twitch, SoundCloud |
| Everyday | 5 | Weather, Booking, Tripadvisor, Allrecipes, ESPN |
How long to run it
The window offers 3, 5, 8, 12, 20 or 30 sites, and 10 to 90 seconds on each. The defaults are 8 and 20, which is roughly three minutes. The run itself accepts anything from 1 to 40 sites and 5 to 300 seconds, so a caller cannot ask for a run that never ends.
The estimate is the number of addresses times the seconds on each, plus three seconds per navigation. Profiles run one after another unless you ask for more, so the window shows the per-profile figure and the total you will actually wait.
Run it once, after the proxy is attached and before the first sign-in. Browsing through the wrong exit is the one thing you do not want in that history. Building up history is the browsing half of warming a profile; the day by day half is the safe pace ramp on the profile card, which lifts the recommended daily ceiling over seven days from a fifth to the full figure.
- 8 sites, 20 seconds each
- about 3 minutes per profile
- 12 sites, 30 seconds
- about 7 minutes
- 20 sites, 45 seconds
- about 16 minutes
- 30 sites, 60 seconds
- about 32 minutes
- 5 profiles, 8 sites, 20 seconds
- about 15 minutes in total
The window shows these figures before you press start, and warns when the groups you ticked hold fewer addresses than you asked for.

The run promises the number of addresses it will really visit
The number you ask for and the number available are two different things. The Search group holds four addresses, while the window offers twenty. Asking for twenty from that group means four.
It used to promise the requested number anyway. The window said about eight minutes, the robot finished in ninety seconds, and the task centre kept a line reading done, 24 of 120 forever. The work was complete and looked cut short, which is the worst kind of wrong.
Now both halves count the same way. The window shows the addresses available and says that is how many will be visited; the main process clamps the total step count to the same number and returns both figures. The stand for this pulls the real run function out of the app and executes it, then executes the window's own two functions against a stub, and compares the promised minutes with the real ones.
Why it is counted twice
It rides the automation engine, not a second one
The robot has no engine of its own. It generates steps and hands them to the same runner that plays back your recorded flows. Same profile launch, same queue, same line in the task centre, same stop button, same run log on disk.
That is the whole reason it is built this way. One code path exercised every day beats two that quietly drift apart. Everything the automation engine learns, the robot gets for free.
It also inherits the honest parts. If the open window limit is reached, the run waits for a free slot for up to half an hour, checking every five seconds, instead of writing the profile off as failed. If steps failed, the profile ends as failed with the count, not as done.
Progress
One task centre line for the whole run, counting six steps per address per profile.
Stop
The stop button marks the run stopped, and each profile finishes at its next step.
Queue
Waits up to thirty minutes for a window slot; the limit is derived from the machine's memory.
Log
The last twenty finished runs are kept on disk, so a night run can be read the next morning.
Honesty
A page that failed to load counts as a failed step, and the run says failed rather than done.
Doing it
Everything happens in the profile list. One profile from its card menu, or several at once: tick them and press History in the bulk bar. The dialog names the profile, or says how many are selected.
Pick the groups, or switch to your own list. Pick how many sites and how many seconds on each, read the estimate, press start. The dialog closes and the run reports itself through the task centre from there, exactly like an automation run.
You can keep working while it runs. The profiles it drives are open browser windows, so leave them alone until the task centre says the run is finished, then sign in and start using the profile.
- 1
Attach the proxy first
History collected through the wrong exit is worse than no history.
- 2
Open the dialog
Build up history in the card menu, or History in the bulk bar with several profiles ticked.
- 3
Choose what to browse
Tick groups, or paste your own addresses, one per line.
- 4
Set the size
How many sites and seconds on each. The estimate updates as you change them.
- 5
Start and leave it
Watch the task centre, stop any time, sign in after it finishes.
What this does not do
- It does not create accounts and does not sign in anywhere. Every address in the pool is public, and the only steps generated are navigation and scrolling. There is no typing, no clicking and no form filling.
- It cannot make a profile old. The cookies and history it leaves are dated today. It gives a profile a few hours of past, not a few months, and nothing in the app pretends otherwise.
- It cannot be scheduled or called from outside. It runs from the app window only. The scheduler starts saved flows by id and the robot has no saved flow, so there is no robot method in the local API or in MCP.
- The built-in pool is thirty global addresses in six groups, with no per-country and no per-platform variants. For local sites you paste your own list, up to sixty addresses.
- It does not check the result. It does not verify that a cookie was actually stored or that a page rendered the way a person would see it. A step that threw is counted as failed, and that is the whole of the verdict.
How to check
Every claim above sits in a file you can open, and most of them are held down by a stand that executes the real code.
- Thirty addresses in six groups, shuffled per profile with Fisher-Yates, six steps per address
- apps/desktop/src/lib/cookieRobot.js · apps/desktop/test/cookie-robot.js
- The generated steps are accepted by the automation engine unchanged, with nothing dropped or rewritten
- apps/desktop/src/lib/rpa.js · apps/desktop/test/cookie-robot.js
- The run promises the number of addresses it will really visit, in the window and in the main process alike
- apps/desktop/src/main/main.js · apps/desktop/test/robot-promise-kept.js
- Each profile is asked for its own steps by the shared run driver, so no two get the same list
- apps/desktop/src/main/main.js · apps/desktop/test/robot-promise-kept.js
- A run that hits the open window limit waits for a slot instead of failing the profile
- apps/desktop/src/main/main.js · apps/desktop/test/сценарий-ждёт-места.js
Read next
Profiles
What a profile holds and why each one is a separate browser.
Proxies
Attach the exit before the robot collects any history through it.
Safe pace and limits
The day by day half of warming: a seven day ramp on the daily ceiling.
Automation builder
The engine the robot rides, with steps you write yourself.
Try it on one profile
Make a profile, attach a proxy, run the robot for three minutes and look at what the profile carries afterwards.