Muse avatar.set returns "stale": do candidate IDs expire?

Candidate IDs don’t expire on a timer. As of October 6, 2026, activating any avatar candidate in Muse invalidated every other pending candidate on the spot, including the candidate for the avatar it replaced. A saved list of candidate IDs therefore stops working after the first switch. Generate the avatar and set it in the same run.

The problem

Qubeekc wanted a daily avatar rotation: a scheduled job on the Muse VM, the cloud machine where a Muse runs its jobs, would call avatar.set at 5 a.m. with one of seven saved candidate IDs, one per day. Instead the call kept returning:

{
	"status": "stale",
	"skipped_activation": true,
	"message": "The active avatar changed before this candidate could be activated, so nothing was activated."
}

The first batch of seven IDs went stale within two or three days without being used. A rebuilt batch failed again on the next morning’s first run. The same message also appeared after several manual switches in one day, so Qubeekc wondered whether it was a rate or change cap rather than expiry, since the error doesn’t say, and posted the question in the server’s help forum.

Steps

For a scheduled rotation, have each run do both halves:

1. Generate a fresh candidate for today’s avatar.
2. Call avatar.set on that candidate immediately, in the same run.
3. Don’t store candidate IDs for later days. If you get stale, generate again rather than retrying the old ID.

Qubeekc asked in the original post whether “generate-then-set in the same run” was the only reliable pattern. The test below is why the answer was yes.

How the cause was found

N8, one of the server’s admins, replied with a test that separates the three explanations (expiry, a rate cap, or sibling invalidation):

generate candidates A and B, immediately activate A, then immediately call avatar.set(B). If B returns stale, you’ve proven that a successful activation invalidates sibling candidates even with essentially zero elapsed time

Qubeekc ran it the same afternoon. A activated cleanly. B, set seconds later, returned the same stale message. That ruled out both other explanations: no time had passed, so it wasn’t expiry, and A had gone through moments earlier, so changes weren’t being blocked. “Confirmed: a successful activation invalidates sibling candidates on the spot,” Qubeekc wrote, and marked the thread solved.

There was one more detail. Re-setting the candidate ID of the avatar that A had just replaced also came back stale. Qubeekc’s summary: “only the live candidate’s lineage survives; everything else pending is dead.”

Why it happens

The error text itself describes it: “The active avatar changed before this candidate could be activated.” Qubeekc’s reading of the test is that only candidates descended from the live avatar survive a switch, so anything that changes the active avatar, including a manual switch in the app, voids every candidate still waiting. Nobody in the thread had seen candidates go stale with no switch in between, which is why time-based expiry was ruled out.