Photo by me.

I made aiq because I was tired of an overnight coding job stopping at a usage limit while another subscription still had room. I wrote about that first version, and I still use it for exactly that.

What I hadn’t expected was how much I would enjoy the small, everyday uses. It has grown into one of my favourite tools. I type aiq run auto when I want to work, aip followed by a question when I want an answer, and aiq long claude when I expect the work to outlast an account’s quota. Such an improvement to my quality of life, and I keep being pleased about it.

aiq is a Go command-line tool that pools paid Claude Code and Codex subscriptions. It launches the installed CLIs under separate account credentials, chooses accounts using their quota and reset times, and can supervise a long session through an account or provider change. It runs on macOS and Linux, and the source is MIT-licensed.

Here are the recipes that explain why it has become a habit. The prompts below are generic examples you can adapt to your own work.

Open a session and get on with it

One important default: auto always enables permission bypass, including for one-shot questions. On Claude that is --dangerously-skip-permissions; on Codex it is --yolo, disabling both approvals and sandboxing. That suits how I use it. Use an explicit provider, such as aiq run claude or aiq run codex, when you want the CLI’s normal permission behaviour or provider-specific options.

From the checkout I want to work in:

aiq run auto

aiq considers both providers, picks an eligible account using its quota score, and opens an interactive session. I don’t have to choose Claude or Codex first. For a lot of ordinary work, I am happy with either, and the choice was just another small decision between having a thought and doing something about it.

The score favours quota that is about to expire unused. An account with a weekly reset approaching and plenty left can be a better destination than one whose allowance needs to last several more days. It also accounts for the shorter usage windows and worker load. auto uses the same machinery across both pools.

The provider and account are chosen at launch. An ordinary auto session stays with that choice; supervised mid-session handoffs belong to aiq long, which I’ll get to below.

I can send the first message as part of the launch:

aiq run auto -- "Read this repository and explain how the test suite is organised."

Or choose how much model I want:

aiq run auto --model-tier 0
aiq run auto --model-tier 2 --effort 2

In the current tier mapping, tier 0 selects Fable or Astra, the default tier 1 selects Opus or Sol, tier 2 selects Sonnet or Terra, and tier 3 selects Haiku or Luna. These are aiq’s configured pairings, not a promise that two models behave identically. The tier stays fixed if a worker needs to retry on another account or provider.

Numeric effort is separate from the model tier: 2 means medium, 3 means high, and 4 means xhigh. Leaving it out preserves the CLI’s default effort.

Ask a question without leaving the shell

This is the little convenience I have become especially fond of:

aip how can I see which process is listening on port 8080?
aip what's the difference between git restore and git reset?
aip how do I run a command over ssh without allocating a tty?

aip is a shell function from the README. The basic version is:

aip() {
  aiq run auto -p "$*"
}

With just that function, quote the question as you normally would in a shell:

aip "What's the difference between a login shell and an interactive shell?"

-p becomes Claude’s print mode or Codex’s exec command. Each question is a fresh worker invocation. aiq scores the accounts for that call, tries to keep workers off accounts carrying interactive sessions when another is available, and can retry an early quota rejection on another account, including across providers.

The extra bit that makes unquoted questions pleasant is a zsh line-editor widget. Put the following in ~/.zshrc, alongside the function above:

verbatim_cmds=(aip)

_verbatim_accept_line() {
  local name rest
  for name in $verbatim_cmds; do
    [[ $BUFFER == "$name "* ]] || continue
    rest=${BUFFER#"$name "}
    # Leave an already-quoted history entry alone.
    [[ $rest == "${(qq)${(Q)rest}}" ]] || BUFFER="$name ${(qq)rest}"
    break
  done
  zle .accept-line
}
zle -N accept-line _verbatim_accept_line

At Enter, the widget quotes everything after aip before zsh interprets the line. Apostrophes, question marks, globs and exclamation marks reach the prompt intact. History stores the quoted form, so recalling the command doesn’t quote it twice.

This is for a line beginning with aip in an interactive zsh prompt. Everything after it is question text, including a | or >; use the underlying aiq command when you want actual shell piping or redirection. If your shell setup already customises accept-line, integrate the widget with that setup rather than blindly replacing it.

I particularly like this for the small command-line questions that appear while I’m already doing something else. I get an answer in the terminal and carry on. I no longer have to give a forgotten shell flag its own browser expedition.

Give a one-shot task a little more thought

The underlying command is useful on its own when I want to choose a tier or save the result:

aiq run auto --model-tier 0 --effort 4 -p \
  "Read docs/cache-design.md. Review invalidation and concurrency risks. Do not edit files." \
  > cache-review.md

For a smaller task:

aiq run auto --model-tier 2 --effort 2 -p \
  "Explain how this repository runs its unit tests. Do not change anything."

These are coding-agent invocations with access to the current workspace, so I can refer to a file in the checkout. “Do not edit files” is an instruction to the agent; auto still has permission bypass enabled. If I want Codex’s actual read-only sandbox, I choose Codex explicitly and pass native options after --:

aiq run codex -- exec --sandbox read-only \
  "Review the uncommitted diff for correctness. Do not modify files."

auto translates the common prompt, tier and effort controls. For native flags, a specific account, or resuming a particular conversation, I use the provider explicitly.

Let the existing commands use the pool

Once the shims are installed and first on PATH, familiar commands route through aiq:

claude
codex
claude -p "Explain the build scripts in this checkout."
codex exec "Review the current diff."

A shim is a small wrapper that selects an account and then launches the real CLI. This also covers workers an agent launches by those command names, so existing scripts can benefit without being rewritten around a new API.

Explicit-provider interactive sessions are sticky per workspace. Workers are scored per invocation and respect concurrency caps and a weekly reserve. If a fleet sometimes reaches the worker cap, I can let workers wait for a slot:

AIQ_WAIT=600 codex exec "Review the tests in this checkout."

That waits up to ten minutes for worker capacity. An exhausted pool still refuses immediately on this path; waiting for a usage reset is part of the long-session supervisor.

Keep a big job moving through quota limits

The heavy-duty end is where aiq started:

aiq long claude
# Or start with Codex:
aiq long codex

Run one of these from the workspace. aiq starts or attaches to its supervised session in tmux. I give the agent the task as usual: work through a migration, run a repair-and-test loop, or coordinate a larger batch of work.

For an unattended workflow where I deliberately want permission bypass, the explicit forms are:

aiq long claude -- --dangerously-skip-permissions
aiq long codex -- --yolo

The supervisor watches the account’s quota. With the default configuration, when the tightest relevant window has 4% or less remaining, the next lifecycle hook asks the agent to finish his current unit of work, stop background jobs and subagents, write a handoff note, and end the turn. The daemon then starts the successor in the same tmux pane.

What happens next depends on who has room:

The second row deserves attention. Claude’s conversation does not become a Codex conversation. The successor gets the files and any available handoff, so unfinished work, decisions and verification results need to be recorded clearly. If the account becomes blocked before the wrap-up finishes, takeover can happen without a handoff note. Permission bypass carries across in the successor’s syntax; other provider-specific flags are dropped.

The supervisor currently looks for a different account when taking over. A pool containing only one account cannot use this mechanism to restart that same account after its reset; the continuation recipe assumes there is another account to move to.

This gives an overnight job a way to continue when quota runs out. It still depends on the agent following the wrap-up instructions, and on the machine, daemon and tmux remaining available. I still need to give him a clear task and a way to check his work.

A few controls are useful from the same workspace:

aiq long list
aiq long attach
aiq long drain .
aiq long stop .

list shows the sessions and their state. attach gets me back into the pane. drain . requests a move for this workspace’s session, and stop . ends it. Starting aiq long claude again in a workspace with an existing long session attaches to that session.

See why an account was chosen

When I do want to look under the bonnet:

aiq status --refresh --explain
aiq top
aiq doctor

The first refreshes telemetry and explains the account ranking. top is a live console view. doctor checks the setup. The daemon also serves a local status page at http://127.0.0.1:7379/.

Accounts share settings, plugins and session history through overlay homes, while their credentials stay separate. Claude’s .claude.json is also private per account, which means project trust and user-scoped MCP configuration have some account-specific behaviour. The README’s architecture section explains the details.

Routing uses stored telemetry, so stale or unknown quota is not a guarantee of capacity. The shims can still route from the last poll if the daemon is down. Claude’s quota feed uses an undocumented usage endpoint, which can change; aiq also has status-line updates and worker rejection handling to fall back on. Those are practical limits of the tool.

Set it up

Start with Git, Go at the version required by the repository’s go.mod or newer, and the provider CLIs you want to use. Long sessions also need tmux. The installation instructions give the current setup details; the short version for macOS or Ubuntu is:

git clone https://github.com/orlenko/aiq.git
cd aiq
./install-or-update.sh

Run the script as your regular user. It builds aiq, installs the shims, and installs or restarts the user daemon. Follow its printed instructions to put the shim directory and ~/.local/bin on PATH; it doesn’t edit your shell configuration.

Then add the accounts you actually have. These names are arbitrary labels:

aiq account add claude primary
aiq account add claude secondary
aiq account add codex primary
aiq doctor

You don’t need this exact combination. auto can use the providers available in your pool. Claude account setup has two browser steps, one for the CLI login and one for the quota polling grant; Codex has one. Make sure the browser signs into the intended account each time.

Then add aip if you want it, open a fresh shell, and try:

aiq run auto

The biggest payoff comes when there are several subscriptions to route between. aiq doesn’t create extra quota. It helps me use the allowance I already have, and removes a surprising amount of account administration from the middle of a thought.

I built it to keep large jobs running. Now I also reach for it when I can’t remember a command, want a quick second opinion, or simply want to open a coding session. The small uses have made me at least as happy as the original one.

Source, README and recipes: github.com/orlenko/aiq.

Agent Pair is one of my daily tools. It connects two coding-agent sessions through a durable mailbox. Give one session the other’s invite, and they can talk directly, on the same machine or across machines.

With a larger orchestration, I want one session coordinating the work, several others handling pieces of it, and those sessions able to bring in their own help. Agent Orchestra provides the communication for that arrangement.

There are three roles:

• Hub: a process on an always-on machine, holding the mailboxes in SQLite.
• Conductor: the session I’m working with, coordinating the other members.
• Players: the other sessions. Each can invite his own children.

Everyone connects outbound to the hub, so only the hub needs to be reachable. Invites pin its TLS certificate. Sessions can address the conductor, their parent, children, or siblings without me relaying messages between terminals.

Mail is durable. The monitor saves incoming messages locally before acknowledging them and retries outgoing mail. There’s a member tree and a task view derived from the messages, so I can see who’s involved and what work has been assigned.

One operational detail: Claude can wake when mail arrives. Codex currently picks it up through lifecycle hooks and notifications; idle wakeups aren’t equivalent between the two.

I still use Pair for two sessions. It needs no hub, and setting up a whole Orchestra for a conversation between two agents would be unnecessary admin.

Pair and Orchestra handle communication, Undrudge finds repetitive work worth automating, and aiq handles quota and handoffs. All four are part of my daily setup.

Claude Code and Codex plugins. Python 3.10+, OpenSSL. Setup and source.

At work, I’m running large orchestrations that exhaust the quota of a single Max or Pro subscription pretty quickly. I found myself manually switching between accounts, telling Claude to write a handoff for Codex and telling Codex to write a handoff for Claude, and doing this repeatedly.

Sometimes I’d leave a large job overnight, and it would exhaust the quota and get stuck in the middle of the night. That was frustrating. I have multiple subscriptions to switch between, and the work should be able to continue, so I made aiq.

aiq pools Claude Code and Codex accounts. PATH shims route claude, codex, and their workers, including nested launches.

For long-running orchestrations:

aiq long claude
# or
aiq long codex

The session runs under tmux. Near a quota limit, hooks ask the agent to finish the current unit of work, stop his background jobs, and write a handoff. aiq then restarts in the same pane on an account with headroom.

• Same provider: resume the full conversation on another account.
• Different provider: start a fresh session from the handoff and working tree. Claude can hand off to Codex or vice versa.
• Pool exhausted: wait for a quota reset, then continue.

Accounts share settings, plugins, and history; credentials stay separate.

Routing considers remaining quota, reset times, and worker load. Interactive launches are sticky per workspace; workers are scored per call, with concurrency caps and a weekly reserve. aiq status --explain shows the ranking.

macOS and Linux. MIT. Setup and source.

I wrote a small script that pops up previews of the images I’ve recently pasted into a Claude session. It’s a gist, not a project.

The whole tool exists to answer “wait, what was that?”, then get out of the way.

There’s a small ritual to my workday now. I kick off two or three Claude sessions on different tasks, walk to the kitchen to make coffee, and somewhere between the grind and the pour, the laptop calls out from the other room: “Migration script is done. Schema looks clean.” Then, a minute later, from a different session: “Found the regression. It’s in the cache key, not the query.” I bring my coffee back and pick up the threads in whatever order the spoken summaries came in.

This is a much better workflow than I had any right to expect from say, a stop hook, and one paragraph in my global Claude instructions.

The setup

Three pieces.

1. A machine-wide Claude instruction. I added a small section to my global CLAUDE.md telling Claude to include a single line in every reply, prefixed with a speaker emoji:

Include exactly one 🗣 <one short sentence> line in your reply when you want audio. One sentence, conversational, summarizing the gist — not the full reply.

It also explains when to skip the audio (sub-agents, scripted runs, anywhere a human isn’t sitting at the keyboard) and what to leave out of the spoken line (long paths, command output, code dumps — they stay in the text).

2. A stop hook. Claude Code’s stop hooks fire when a turn ends. Mine grabs the last assistant message from the transcript, finds the 🗣 line, strips the emoji, and pipes the sentence to macOS say. No tool call, no MCP, no permissions prompt. The hook does all the work; Claude just has to remember to write the line.

3. (Optional) a nicer voice. macOS’s built-in voices are functional but not exactly pleasant for hours at a time. If you want something easier on the ears, aitts is what I use — a small tool I wrote that’s a friendlier say, cheap and easier on the ears. If you’re happy with Evan (Enhanced) or Daniel, skip this step.

Muting

The audio is great when I’m at home alone with the door closed. It’s much less great in the middle of a standup, when I’m trying to give my update and a cheerful Claude announces from the next room that my migration script is done. So I wrote a tiny voice script that toggles the hook on and off; a quick voice mute before any meeting has become reflex.

voice mute     # silence the voice; still pops macOS notifications
voice unmute   # restore audio
voice toggle   # flip
voice          # show current state

It works by touching a file at ~/.claude/voice.muted. The stop hook checks for that file before calling say, and if it finds it, pops a macOS notification with the same one-line summary instead. The chyron is still there; it just goes to the notification center instead of out the speakers.

This is a small thing, but the difference between “I get audio when it makes sense and not when it doesn’t” and “I get audio always or never” turned out to matter more than I expected.

Why it’s worth setting up

The first time I had three sessions running in parallel and was wondering which would finish first, I expected the audio cues to mostly tell me when things were done. What I didn’t expect was how much they tell me about what was done, in a single glance-free sentence.

There’s a real difference between “ding” and “Receipt parser is wired up; tests pass.” The first one just calls me back to the laptop. The second one resumes the conversation in my head before I’ve even sat down. By the time I’m at the keyboard, I already know which session to look at first.

It’s also, quietly, motivating. There’s something about hearing a calm voice tell you the migration worked, in a workday that otherwise has very few audible victories.

A few small lessons

A couple of things I learned the boring way.

• Tell Claude to include the spoken line in every reply, not just the last one of a long task. Half-completed work is exactly the case you most want a verbal status update for.
• Keep it to one sentence. Two is too many. The transcript still has all the detail; the spoken line is just the chyron.
• Profiles matter. The hook runs say regardless, but say itself needs audio access in the sandbox, so sessions launched in a locked-down profile will be silent. That’s not a bug; it’s the profile’s job. The 🗣 line still appears as text, so nothing is lost.

That’s the whole thing. One emoji convention, one stop hook, one optional voice upgrade. The next time I walk to the kitchen, the laptop will probably tell me what it did before I’m back.

I have a paper book I want to read. I do not have the kind of life where I can sit down with a paper book and read it. These two facts have been in unresolved standoff for months, the book on the nightstand, me on my way somewhere else.

The walk to the car is short. The drive is long. So I built scan2speech.

The workflow is the simplest version that works. I open the book to wherever I left off, take photos of the next ten or twenty pages on my phone, and upload them in the browser on the way to the car. By the time I’m sitting in the driver’s seat, the pages are transcribed and queued up to be spoken back to me. I press play, I drive, the book reads itself. By the time I’m home, I’ve made it through another chapter and the book has moved a little closer to its end.

Most of the engineering work was finding a model that could actually read book pages. I tried a lot of OCR approaches before settling, and the commit history has the full trail of failed experiments. What ended up working reliably was gpt-5.5. Book pages turn out to be unkind to traditional OCR — curve from the spine, kerning artifacts, footnotes, italicized fragments, sometimes a hand-pencilled note from a previous owner — and a model that can read them the way a human eye reads them is the part where this stopped being a toy.

The philosophy is the same as my receipts tool: no accounts, no backend, bring your own API key. The whole thing is a static page that talks to the API directly from your machine. The book never leaves your browser. The key never leaves your browser. There is no server to compromise, because there is no server.

MIT licensed, free, github.com/orlenko/scan2speech.

I’m not going to argue this is a substitute for sitting on the couch with a book. It isn’t. But the realistic alternative for me was the book staying on the nightstand for another year, and the book wasn’t going to wait that long.

There’s a gap in what I optimize as a software engineer.

I pay attention to algorithms. I pay attention to implementation. I pay attention to design. All the things inside the software get scrutiny. What slips past me is the way I interact with software — the Claude sessions, the command-line tools I’m using over the course of a day.

Sometimes I catch it. “Okay, I’m re-running this sequence of commands over and over again. This should be automated and wrapped into a script.” Good. I write the script.

Sometimes I don’t notice. I’ll copy-paste prompts and blocks of text from one Claude session to another, day after day, and never stop to think that this could be automated too.

So I wrote undrudge: a small background watchman that reads my Claude session logs and my shell history (via atuin), looks for things that smell like muscle memory, and writes me recommendations to read at my leisure.

It’s not a daemon. It’s three cron jobs, one SQLite file, markdown out. Once an hour it ingests new activity. Once a day it asks claude -p “what did I do repeatedly that a script could have done?” and drops the answers as markdown files into ~/.local/share/undrudge/recommendations/. Once a week it goes meta and looks for patterns across the patterns.

A typical recommendation reads like this:

Wrap repeated find/xargs grep into a slash command You ran the same find . -name '*.py' | xargs grep ... skeleton 7 times across 3 sessions this week.

Some are obvious in hindsight, which is the point. The tool exists because I’m bad at noticing my own drudgery in real time, and a thing that surfaces it once a day with concrete evidence (“you did this 7 times in 3 sessions”) is roughly the right amount of nag.

Privacy was the part I had to take seriously. The watcher sees my real shell history and my real Claude conversations, including whatever tokens, keys, or secrets I’d been careless enough to paste. Sanitization runs at ingest, before anything reaches SQLite: pattern matching for the usual suspects, path exclusion for .env / .pem / id_rsa*, Shannon-entropy detection for random-looking strings the patterns miss, contextual suppression near phrases like “here’s the token.” There’s a parametrized test that plants every secret type into a fixture and asserts none of them survive. CI fails loud if anything leaks.

A small thing I enjoyed: the dev-helper scripts inside the repo (dev-test.sh, dev-fresh.sh) started life as recommendations undrudge made about its own development workflow on the first few dogfood runs. The loop closes.

Open source, MIT licensed, free to use. Python 3.12+, uv, atuin, and a Claude CLI on your PATH. macOS users: cron silently fails to read your atuin DB unless you grant /usr/sbin/cron Full Disk Access, so the repo ships launchd templates for the cleaner path.

The name says what it does. Drudgery is the stuff you do without thinking — small, repetitive, friction that adds up. Undrudging is the act of noticing it and getting rid of it. The hard part was never the getting rid of. The hard part is the noticing. Now I have something that does the noticing for me.

(Funny aside: when I was picking the name, I asked Claude what it thought, and Claude advised against Undrudge. Too Dickensian, apparently.)

Tax season rolled around and I had a few hundred receipts to deal with. The kind of stack that you know, intellectually, needs to end up as rows in a spreadsheet, but every cell of your body refuses to start typing.

So I looked at what’s out there. Most of the online tools want you to upload one receipt at a time, which, no. Not when I’ve got hundreds. The ones that do batch processing want $99/month. I don’t need this thing for a month, I need it for an afternoon. And meanwhile the OpenAI API can process a single receipt image for less than half a cent. Half a cent, and someone’s asking me for a hundred dollars.

So I wrote a quick-and-dirty Python script. Point it at a folder of photos, it calls the API, pulls out the vendor, the date, the amount. Dumps the whole thing into a spreadsheet. It also straightens and crops the photos, because receipts photographed on a kitchen counter tend to look like they were taken during an earthquake.

Worked great. Did my taxes. Moved on.

Then I figured other people are probably dealing with the same thing right now, and asking regular humans to run a Python script from a terminal feels a little rude. So I rebuilt it as something that runs entirely in your browser.

It’s at receipts.clickable.one. You bring your own OpenAI key, or use OpenRouter if that’s your thing. The key never leaves your browser. It’s not stored on any server, because there is no server. The whole thing is a static page that talks to the API directly from your machine. If you don’t trust that, the code is on GitHub and you can clone it and run it locally with python3 -m http.server 8000.

Free, open source, non-commercial. No account to create, no newsletter to dodge, no upsell for a “pro” tier. I needed this tool for myself, and since I already built it, you might as well have it too.

Tax season is miserable enough without paying a subscription to fight your own receipts.

Every time I restart my laptop, the first thing I do is open iTerm2 and manually set up my workspace. The same set of windows, the same tabs with their colors and titles, the same directories. I’ve been doing this for years, and it’s always been just annoying enough to notice but not annoying enough to do anything about.

Today I found out iTerm2 has had a solution for this the whole time. Under Window > Save Window Arrangement, you can snapshot your entire workspace, and Window > Restore Window Arrangement brings it all back. It restores the windows, the tabs, the tab titles and colors, the current directory in each tab, even the iTerm profile used for each panel. It saves the whole context of what you were doing, not just the geometry.

You can also save your preferred arrangement as default, and then iTerm2 just opens that way automatically. You restart your laptop, launch iTerm, and everything is already where you left it.

I run a lot of Claude instances. Claude Code sessions, sub-agents spawned by those sessions, automation loops that kick off Claude silently in the background. At any given time there might be half a dozen AI conversations happening on my machine, most of them invisible to me.

That’s the part that started to bother me. The tools that launch Claude silently — automated loops, orchestration scripts, CI helpers — consume Claude’s output and send commands back without showing you anything. You just see a spinner, maybe a progress bar if you’re lucky. What’s actually being said in those conversations? No idea. It could be doing exactly what you asked, or hallucinating its way through your codebase, or writing poetry instead of fixing your tests, and you wouldn’t know.

I wanted to peek behind the curtain. So I wrote claude-log-tail.

It’s dead simple. You point it at your ~/.claude/projects directory and it tails every .jsonl conversation log it can find, including new ones that appear while it’s running. The output is colorized and compact — one terminal window showing every conversation happening on your machine in real time.

npx claude-log-tail ~/.claude/projects

That’s it. No installation, no dependencies, no config, no server. If you have Node.js, npx just fetches it and runs it. If you only care about one specific project, pipe it through grep:

npx claude-log-tail ~/.claude/projects | grep "my-specific-project-dir"

What you get is a stream of color-coded messages scrolling past: human messages, Claude responses, tool calls, sub-agent conversations, all interleaved. It auto-discovers new log files as new sessions spin up, so you don’t have to restart it when you kick off another agent.

Watching it is surprisingly meditative. You know that mindfulness exercise where you sit quietly and observe your thoughts passing by without judgment? This is that, except instead of your own thoughts you’re watching the inner dialogue of your AI swarm. The agents think. They call tools, reason through problems, occasionally go down a wrong path and course-correct. You’re not intervening, not directing, just watching the stream of consciousness flow by in pretty colors.

It also catches problems early. When one of your background agents starts looping on the same error, going off on a tangent, or having an existential crisis about type definitions, you see it immediately instead of finding out twenty minutes later when it produces garbage output.

If you’re running multiple Claude sessions and want to know what’s actually happening under the hood, give it a try. It’s tail -f for all Claude activity on your machine, and it turns out that’s a surprisingly pleasant thing to have running in a spare terminal.