ARMANOS

Limits

Action ceilings and the edges of protection

Every profile carries a recommended daily pace for its use case. A new one starts at a fifth of that pace and grows over a week. The app counts pages for you, shows the rest as advice, and never blocks an action.
7 days, 20% to 100%
Warm-up
Pages opened, per profile
Counted by the app
None
Actions blocked
3 to 14 seconds, random
Pause before each bulk launch

A ceiling is a number you can see, not a wall

When you create a profile you pick a use case. It sets the start page, the tracker lists, and the daily numbers this page is about. You can change it later in the profile editor.

The numbers are plain data in one shared file, next to the rest of the use case description. There are two kinds. One is a ceiling for the whole profile, counted in pages opened per day. The other is a set of ceilings for single actions, such as invitations or budget changes.

The Privacy use case has neither. It is ordinary browsing without tracking, not an account game, so the card reads no limit and no bar is drawn.

These are our defaults, not rules published by any platform. No site handed us a number. They are conservative working figures per use case, and the app has no field for setting your own.

Use casePages a dayPer-action ceilingsPages on day 1
Social20010 actions40
E-commerce1205 actions24
Ad accounts405 actions8
Freelance406 actions8
Privacyno ceilingnoneno ceiling

A new profile starts at a fifth of its pace

The ramp is seven numbers: 0.2, 0.35, 0.5, 0.65, 0.8, 0.9, 1.0. Day one is the day you created the profile. From day seven on, the full ceiling applies.

The reason is simple. A session that appears today and does a full day of work today is a pattern. Growing over a week looks closer to a person settling into a new account.

The curve touches the page ceiling and every per-action number alike. A ramped number never rounds down to zero: an action allowed twice a day shows 1 on day one, not 0.

The card names the warm-up day, and after the ramp it says how long ago the profile was created. That wording is deliberate. It is the age of the ARMANOS profile, not of the account behind it, and the app cannot know the second one.

Day 1
20% · social: 40 of 200
Day 2
35% · 70
Day 3
50% · 100
Day 4
65% · 130
Day 5
80% · 160
Day 6
90% · 180
Day 7 and after
100% · 200

The same fractions apply to every per-action number, with one rule on top: a ramped ceiling never becomes zero.

ARMANOS profile cards showing a safe pace bar reading 0 of 24 today, warm-up day 1 of 7, and a list of safe daily ceilings
An e-commerce profile on its first day: 24 pages instead of 120, and every action ceiling ramped by the same curve.

The app counts pages, and only pages

One counted action is one top-level page load in a profile window. The window reports it, and the app adds one to that profile's day.

The profile is derived from the window that sent the report, never read out of the message. A page cannot claim to belong to another profile and cannot inflate a counter that is not its own. The hidden window used by the fingerprint self-test is never registered as running, so its loads are not counted.

On ARMANOS Browser there is no session hook to listen on, so the profile's protection extension posts the counts instead. A single report can add at most 5000, because a local process must not be able to write any number it likes into what you read.

Counts live in memory and reach pace.json in the app's data folder at most once a second, with owner-only permissions, flushed when you quit. The file carries its date. On the first read of a new date the previous day is cleared, and deleting a profile removes its counter with it.

  • Counted

    A page you open in the profile window: an address you type, a link you follow, a redirect that lands somewhere new.

  • Not counted

    Frames inside a page, images, background requests, and a tab you leave open and read for an hour.

  • Not counted

    The hidden window behind the fingerprint self-test, which never registers as a running profile.

  • Reset

    On the UTC date change, not at your local midnight. The stored file names its own day.

Per-action numbers are advice, because nothing can count them for you

ARMANOS is a browser. It sees that you opened a page. It does not see that the page was an invitation being sent or a budget being changed.

Counting those would mean reading each platform's page structure and keeping a scraper per site. Every layout change would break the count in silence, and a silently wrong number is worse than no number at all.

So per-action ceilings are shown, not tallied. Each row reads today's ramped number and the full one, for example 2 / 10 on the first day of an e-commerce profile. The left number is what today allows, not what you have already done.

Each ceiling also carries a warn threshold in the data, between 50 and 99 percent depending on how dangerous the action is. It travels to the window with everything else, and nothing draws it yet. The lowest ceilings tell you where the risk sits: payment details, payout details and account switching.

ActionUse caseFull dayDay 1
InvitationsSocial153
LikesSocial12024
PostsSocial153
New listingsE-commerce102
Review requestsE-commerce408
Budget changesAd accounts41
Payment editsAd accounts11
ProposalsFreelance102
Payout editsFreelance11
Account switchesSocial, e-commerce21

Nothing here stops you

The bar under the count is green below 80 percent of today's ceiling, amber from 80, and red at or past it. That is the whole of the enforcement.

Blocking would mean the app deciding for you, on a figure we chose, about an account it knows nothing about. A three-year-old account with a payment history behaves nothing like one opened yesterday, and the same ceiling cannot be right for both.

The tooltip in the app says it in one line, so the promise is not only on this page. The counter is guidance and it never blocks you.

There is exactly one refusal in this area, and it concerns your machine rather than your accounts: the app can decline to open one more browser. It never closes a window that is already open.

Guidance, not a lock

No number on this card is a promise about any platform. It is a conservative pace for a kind of work, and the decision stays with you. Nothing here prevents an action, and nothing here claims an account will not be blocked.

A burst of launches in one minute is the cheapest way to be noticed

Bulk launch used to open the whole selection back to back. Fifty accounts signing in inside one minute, from one machine, is exactly the shape a platform reads as one script behind all of them.

A fixed pause would be a pattern of its own, and an easier one to measure. So the pause is drawn at random between 3 and 14 seconds, once per launch. Across fifty profiles the batch stretches over several minutes.

The pause sits only in front of opening a browser. Deleting profiles, moving them into a group or exporting them runs with no pause at all, because no site sees any of it.

One bulk run at a time. A second press used to start a second queue over the same selection, and two interleaved queues bring the spread back to nothing. Every bulk button is disabled while a queue is running.

  1. 1

    You select and press Launch

    The first profile opens straight away. Waiting before the first one only leaves you looking at a still screen.

  2. 2

    A random pause

    Between 3 and 14 seconds before each following launch, drawn fresh every time.

  3. 3

    A slot check

    If the machine is already at its browser limit, the queue waits instead of marking the profile failed.

  4. 4

    The task centre follows along

    One task with a running count, and one message per batch when the queue starts waiting for a slot.

  5. 5

    Cancel lands where you pressed it

    It is checked between profiles and again right after each sleep, so a cancel during a pause is not one launch late.

The open-browser limit is soft, and the queue waits for it

How many browsers you may keep open at once is computed from this machine. Take the memory in gigabytes, leave 3 to the system, allow 1 per browser, then keep the result between 4 and 32. When memory cannot be read the answer is 8.

You can set your own number in the Browser engine screen, inside the same 4 to 32. The screen says which of the two you are looking at, the figure you chose or the one the app computed.

The limit earns its place twice. Each profile is a whole browser of hundreds of megabytes, and thirty of them give you a stalled machine rather than a working day. Thirty browsers knocking on one platform from one address at the same second look like what they are.

A slot is taken by intent, in the same step as the check, with no pause between the two. Eight scheduled runs firing at once used to all see zero open and all pass. The refusal carries a flag rather than a message to match, because that message exists in 22 languages. The bulk queue and a flow run read the flag, poll every 5 seconds for up to 30 minutes, then stop the batch and report how many opened.

The ARMANOS Browser engine screen with a Browsers at once setting reading by this computer's memory
Browsers at once, computed from this computer's memory. The limit refuses to open one more and never shuts down what is already open.

What isolation cannot cover

A separate session and a consistent device remove two reasons out of many. The rest is not in the browser at all, and no setting on this page reaches it.

Pace is the one item on that list where a browser can help, and it helps only by putting a number in front of you. Everything below is yours to manage, and it is where accounts are actually linked to each other.

We do not promise that an account will never be blocked, and we do not claim a site cannot tell. What the app gives you is isolation, a consistent device and an honest counter.

  • Behaviour

    The same actions at the same hours, the same message text in twenty inboxes, the same order of clicks. Platforms compare accounts to each other, and a copy is visible.

  • Phone numbers

    One number verifying ten accounts links those ten on the platform's side. Nothing in a browser touches it.

  • Payment and payout details

    The strongest link of them all. On ad accounts and marketplaces the card is the identity, and the profile it sits in makes no difference.

  • Account age and history

    A profile created today is a new profile whatever the account inside it. Age, past activity and standing belong to the platform, not to your machine.

  • What you publish

    The same photos, the same bio, the same links across accounts connect them with no technical signal involved.

What this does not do

  • The app never counts platform actions. Invitations, likes, listings and budget edits are shown as recommended numbers and none of them is tallied. Only pages opened are counted.
  • The ceilings are not editable. They are the defaults in the code, one set per use case, and there is no field for your own figure.
  • The warn threshold each action carries is sent to the window and drawn nowhere. The only colour change is on the page bar, at 80 and at 100 percent.
  • The day rolls over at the UTC date change, not at your local midnight. An evening west of UTC starts a new day earlier than you would expect.
  • Warm-up counts from the day the ARMANOS profile was created, not from the age of the account. A profile made today for a three-year-old account still reads day 1 of 7.

How to check

Each claim, the file that implements it, and the stand that guards it.

Per-use-case ceilings and the seven day ramp are plain data in one shared file, and the merged LinkedIn use case keeps its numbers for the profiles that chose it
packages/shared/src/index.js · apps/desktop/test/слитый-сценарий.js
The daily counter starts a fresh day on a date change and forgets a deleted profile
apps/desktop/src/lib/pace.js · apps/desktop/test/delete-leaves-nothing.js
A page count is attributed to the window it came from, never to a profile named inside the message
apps/desktop/src/main/main.js · apps/desktop/test/page-ipc-trust.js
Bulk launch waits a random 3 to 14 seconds before every launch but the first, and a second press cannot start a second queue
apps/desktop/src/manager/renderer.js · apps/desktop/test/запуск-не-залпом.js
A profile that meets the open-browser limit is queued instead of failed, and the limit grows with the machine's memory
apps/desktop/src/manager/renderer.js · apps/desktop/test/очередь-запуска.js · apps/desktop/test/предел-открытых.js

See your own numbers on the first profile

Two profiles are free, with no card. Pick a use case when you create one, and the safe pace card appears on it right away.