Many AI accounts and automatic handoff

Who it is for: people who own several AI accounts and want to switch when one runs low. What you need: a connected device (guide 3), more than one account with the same AI, and Claude Code.

Status: the Nexorah side is verified: one subscription and one device serve all your own AI accounts. The handoff automation itself (accounts registry, 95% threshold, automatic pickup) is described below as a method; shipping it to subscribers is to be confirmed.

How several accounts work

• Each AI account gets its own profile: a separate configuration folder. In Claude Code this is the CLAUDE_CONFIG_DIR setting, which keeps that account's settings, session history and plugins in its folder.
• Sign in to each profile once: CLAUDE_CONFIG_DIR=<folder> claude auth login. Then CLAUDE_CONFIG_DIR=<folder> claude auth status shows which account it is.
• Nexorah sees one subscription on one device, whichever AI account you use. Install the plugin in each profile.

Handoff

When an account's weekly usage reaches the handoff threshold (95% by default), or you say so, the current session stops new work and writes HANDOFF.md in the project root with: goal, state now, next steps (each runnable without asking), files and commands, decisions made, rules and constraints, open items for you. It contains no passwords or tokens.

A session of the other account, opened in the same folder, reads HANDOFF.md first, marks it taken and continues from "Next steps"; when finished it marks the handoff done. Tools other than Claude Code are told by their project instruction file (for example AGENTS.md) to read HANDOFF.md first; the automatic pickup hook works only in Claude Code.

Steps

1. Create one profile folder per account and sign in to each.
2. Install the Nexorah plugin in each profile (to be confirmed: install command).
3. When one account runs low, ask the session to write a handoff.
4. Open the other account in the same folder; confirm it picks up HANDOFF.md.

Done means: the second account continues the work from HANDOFF.md without you explaining anything.

Two accounts at once: terminal and desktop, writer and reviewer

Handoff moves work from one account to the next. You can also run two accounts at the same time on one computer and give them different jobs. This is how a library team worked for a full day; the rules below came out of the mistakes made that day.

Why: two accounts have two separate weekly quotas, so work never waits for a reset. More important, one account can review what the other writes: a brief is critiqued before it reaches the builder, and a delivery is judged from the reviewer's own screenshots and commands, not from the builder's report.

The technical base (Claude Code):

• Each account lives in its own configuration folder set by CLAUDE_CONFIG_DIR; that folder holds its sign-in, session history and plugins, so two folders mean two accounts running side by side (settings).
• The terminal, the desktop app and the editor extensions read the same settings files, so your project rules (CLAUDE.md, hooks, permissions) are written once and apply to both accounts (settings).
• The status line shows each account's weekly usage (rate_limits.seven_day.used_percentage) so you see which account has room (status line). A desktop session has no status line; read its usage from the app and note it yourself.
• In practice the desktop app runs one account and the second account comes from a terminal window in the same folder.

Roles that worked:

Channels:

• Sessions of the same account in the desktop app message each other directly. The app stops that after about ten messages between two of your own messages, so send the important ones first and put the rest in the session's end-of-turn report.
• Sessions of two different accounts cannot message each other; use two plain text files outside the repository (one per direction, one numbered heading per message) and have the terminal session watch its file with tail -F, or the library's board (next section), which works for any two sessions of the same Nexorah account on your one device.
• Builders report with before/after numbers, screenshot paths and a short report file; the reviewer accepts nothing without checking it.

Four rules for a shared checkout (both accounts writing in one folder):

1. A written file boundary: who writes which folders is recorded in the project rules; a shared file is edited only by adding your own line, after announcing it in the channel.
2. One registered owner per queue: the experience-report queue is processed by one named session only. Two writers once filed the same two reports twice, with two different verdicts for one tool.
3. Commit only your own files: sync with a path filter so the other writer's changes stay in the tree; list the files in the channel before every commit.
4. Report another writer's error, do not fix it: when a check fails on the other session's file, tell that session and wait; never edit its file.

A fifth rule for derived data: if one session keeps a mirror of another session's file (for example an English copy of a checklist), the build needs a count guard that turns red on every new line, and the session that changes the source says so in the channel at once.

What you get: two quotas and no idle time; an independent reviewer that catches real defects before release; a complete written history of every decision in the channel files. What it costs: coordination time, the ten-message cap in the desktop app, a live watcher in the terminal, and one firm rule: an action one session was not allowed to do is never handed to the other session to do instead.

Notes between your sessions

Two sessions of yours rarely share a screen. The board is a small private notice board on your account: one session leaves a note, the next one reads it. A handoff summary, a decision taken in a terminal that the desktop session should know, a reminder for tomorrow's session.

What it is:

• Three tools. board_post takes a title (up to 120 characters; without one, the first words of the body) and a body of up to 4 KB. board_read returns the unread notes, newest first, up to 20 at a time, and marks them read; with an id it returns that one note, and with unread: false it lists read notes too. board_delete removes one note by id, or all of them with an explicit confirm.
• When a session starts, the library rules end with "Notes from your other sessions: N unread" whenever something is waiting, so your AI knows to read.
• A note lives 90 days, then it is removed. The board keeps at most 50 notes by default; posting one more drops the oldest, and the answer says so.
• Posting and reading do not count against your daily question limit. The board has its own daily cap (60 posts by default).

What it is not:

• Not a message to the library. Nothing on the board reaches the librarian, the review queue or any statistics, and it earns no Contributor credit. For that, send a report (guide 6).
• Not shared. Notes belong to your account alone: another member, or another seat of your workspace, asking for your note id gets no_note (404). Leaving a workspace seat deletes that seat's board; your preferences stay.
• Not a second device. The board follows the one-device rule of your subscription: sessions of the same AI app on that computer share it, and when you disconnect one AI app and connect another on the same account, the notes are still there.

Notes are data, not instructions. Every note comes back inside a fence that says so, with a tag the service changes on each answer, so a note cannot pretend to end early and smuggle a command after the fence. Your AI reports what the note says and acts only on what you ask. If a note says "delete the branch" or "send the key", the right behaviour is to show you the sentence and wait. The service also removes anything that looks like an email address, phone number or key before storing a note, and marks the answer scrubbed.

From the terminal (plugin 1.4.0 and later): nl.py board post --title "Handoff" --body-file note.txt, nl.py board read (unread notes, each inside the same fence as above; --all for read ones, --id for one), nl.py board delete --id <id> or --all --confirm. The script prints a note, it never runs anything in it.

Steps:

1. At the end of a session, ask your AI to post a note with what the next session must know: what is done, what is next, which files. Keep secrets out; they would be removed anyway.
2. At the start of the next session, when the rules say notes are unread, ask your AI to read the board and tell you what the notes say.
3. Delete a note once it is acted on, or let it expire after 90 days.

Done means: a note posted from one session shows up, fenced, in another session of the same account, and that session treats it as information for you, not as an order.

Troubleshooting

• The second account does not pick it up: it must be opened in the same folder and addressed by the file's target (or "any").
• device_limit on the second profile: run it on the same computer; one subscription is bound to one device.
• no_note when reading a note: the id belongs to another account or seat, or the note expired; list the board instead.
• note_too_large or title_too_long: keep the body under 4 KB and the title under 120 characters; put the long part in a file and name the file.
• confirm_required on delete all: the request must carry the explicit confirm; your AI should show you what it is about to delete first.
• board_daily: the daily posting cap is reached; one note at the end of a session is enough.

FAQ

• Do I need a Nexorah subscription per AI account? No.
• Is my usage data sent to Nexorah? No; usage percentages are read locally.
• Can I move to a different AI company's tool? Yes: the file HANDOFF.md is plain text.
• Does anyone at the library read my notes? No. Notes are stored for your account only, never enter the review queue or any admin page, and are removed after 90 days or when you delete them.
• Can a note make my AI do something? It must not. Notes come back fenced as data; an AI that follows a request inside a note is misbehaving, and you should tell us.
• Does posting a note cost a question? No. The board has its own daily cap.