An agent run takes minutes, not seconds. The writer reads the website profile, the rules and the outline, then produces a whole post, and for that stretch you are looking at a card that says "Writing" and wondering whether anything is happening. This release is about that stretch. It puts what is running in one place, tells you the moment it ends, and keeps the monthly count where you can see it.
Working now
The Working now panel is one list of everything the team's agents are doing, grouped by project. It is docked at the top of the projects page, and it opens from the Working now entry in the sidebar or, on a phone, from the bar pinned to the bottom of the screen. The sidebar entry reads Idle when nothing is running and shows the count when something is.
Each row is one run. It shows the kind of work (Research, Find topics, Writing, Editing, Audit fix), the post or project it is working on, a counter of how long it has been going, and a state pill: Waiting, Running, Finished, Failed or Stopped. Waiting and running look different on purpose. A waiting run is a still outline. A running one is filled in and carries a pulsing dot, so you can tell a queue from a job in progress without reading a word.
When nothing is running the panel says so: Nothing is running, with a button through to your suggested topics. It never disappears, because an empty panel and a broken one should not look alike.
Stop
A run you no longer want gets a Stop control on its row. Stopping asks you to confirm and says what it costs, which is nothing new: the run was counted when it was queued, and stopping does not give it back. Three kinds of work cannot be stopped, and instead of a button that would do nothing the row explains why. The fix an audit makes runs to the end in this panel, and the audit itself and an AI edit of the website profile do the same wherever their row appears, because interrupting them would leave a project half checked or a profile half rewritten. They usually take two to four minutes and you can leave the screen.
A run that passes ten minutes gets a note underneath saying it will not finish on its own and that stopping it clears the way for new work. Ten minutes is the limit an agent has for a single turn, so a row that has gone past it is not going to recover.
What the panel is not
It is not a transcript. RankMill's agents run as one request to a model, and nothing records the tools they called or the text they exchanged on the way. What the panel can show is the outline of the run: what it was, what it worked on, when it started, when it ended, and, if it failed, one sentence about why. That is also all the Activity page has, so there is nothing hidden behind a more detailed view.
Status without a refresh
Before this change the app only polled: a screen with an in-flight run asked the server every so often whether anything had changed, and a finish could sit unseen for most of that gap. Now every open tab holds one connection to the server for the team, and the server pushes a signal the moment a run starts or finishes. The tab answers by refetching the lists that signal touches, so the board, the post, the Activity feed and the run count all update together.
The connection is a nudge, not a data channel. It carries which kind of run changed, whether it started or finished, and which post or project it belonged to, and nothing else. Every title, status and body still arrives through the same authenticated requests as before.
The panel tells you what state that connection is in, in words, at the top of the list:
- Live. Starts and finishes appear the moment they happen.
- Reconnecting. The link dropped and is coming back. The list refreshes every fifteen seconds until it returns.
- Not live. Still correct, refreshed about every fifteen seconds. Runs that finish during the gap all appear together.
The fallback is real. If the connection is down for any reason the panel goes back to polling, every fifteen seconds, and the rest of the app to its own fallback timers, so nothing on screen is ever quietly stale. The pulsing dot next to a running row doubles as the indicator: while the connection is down it stops pulsing and greys out.
When a run ends
A research, writing or editing run that finishes stays in its place on the list for six seconds, marked Finished, then leaves. A topic hunt or an audit fix simply leaves. Nothing reorders while you are looking at it. Above the list a short notice says what happened, with a link: Your post is ready and Read it, New topics are ready and Open the project, Your website profile is ready, and so on for each kind of work.
A finish clears itself after ten seconds. A failure does not. It stays until you dismiss it, with the reason behind a Show detail disclosure, so a failure you missed while you were in another tab is still there when you come back. The notice only covers runs this tab saw start, and a run you stopped yourself raises nothing, because you already know.
If you collapse the panel on the projects page, that notice is the one thing that still shows through. Not seeing a failure because the panel happened to be shut is exactly what the panel exists to prevent.
One run allowance for the team
Every agent run counts against one monthly allowance for the whole team, twenty runs by default, counted over the calendar month in UTC. Every member spends from the same pool. There is no per-person count and no per-kind count: a profile build, a topic hunt, a written post, an edit turn, an audit and an AI import each cost one run, whatever it did and however long it took. Importing a post as is runs no agent and costs nothing.
The count now sits at the foot of the Working now panel as Runs this month, with a meter, a sentence saying how many are left and when the count resets, and a link to the Activity page reading See everything that has run. The same numbers show in the sidebar meter and under Usage this month in team settings. All three read one rule, so the note beside a button and the meter in the sidebar can never disagree.
The meter has three conditions and it never blurs them:
- Under eighty percent of the allowance, the usual tint.
- Eighty percent or more, amber, and the note says how many are left and that anything starting several runs at once will say how many it uses.
- At the cap, red. A banner appears above the list: work already running will finish, and nothing new can start until the reset date.
Every button that spends a run says so on the button, and one that spends nothing says nothing about cost. So the meter tells you where you stand, and the button tells you what the next click does.
What counts, and what does not
A few rules are worth knowing, because the count is taken when a run is queued, not when it ends:
- A failed run counts. So does a cancelled one. The row was written at queue time.
- Retrying a failed write is free. Re-running a post that already finished is new work and costs a run. Retrying our own failure does not, because charging for it would let a bad week burn a whole month.
- Audit fixes are free. The audit costs one run. Working through its findings afterwards runs under that same one.
- Updating a pull request is free. Where a project publishes through GitHub, pushing an edited post to a pull request RankMill already opened is recorded in Activity but never counted.
- Auto-approve stops before the cap. If you let RankMill approve its own topic suggestions, you can set how many runs it must leave in hand. It stops there and the remaining suggestions wait for you, while every manual action can still run right down to the cap.
Where the history lives
The panel is what is happening now. The Activity page in the sidebar is everything that has happened: every run the team owns across all of its projects, newest first, filterable by project, run type and status, with the filters kept in the URL so a filtered view can be shared. Each project also has its own Activity tab with the same rows scoped to that project. Both use the same row as the panel, so a run looks the same wherever you meet it.
Above both feeds sits a Planned card listing the automated work that is scheduled but has not run yet: each project's next topic hunt and, where GitHub publishing is set up, any post queued to publish on its own. The card says so itself: these are plans, not promises. A project at the cap, or with nothing to do, is skipped and appears there again next time.
What to do with it
Open a project, approve a topic, and leave the panel where it is. You will see the row appear, the counter start, and, a few minutes later, the notice that your post is ready, without pressing anything. Then look at the foot of the panel before you approve the next four. That is the whole change: the app tells you what it is doing, when it is done, and what it has cost, in the same place, every time.