How I Share One Project Across Several AI Coding Assistants Without Running Out of Quota

Most people use one AI coding assistant until it hits its limit, then wait. There is a better way: treat several assistants like a small team, give each the job it is good at, and keep the expensive one for the work that really needs it.

Today is October 31, 2026, and this topic matters right now because usage limits on AI assistants have become the real bottleneck for solo developers. The models are capable enough; the quota is what runs out first. This week my main assistant was down to a few percent of its weekly allowance, with a release still to ship. Here is how the work got done anyway.

The idea: route work by type, not by habit

The project is a web application for compliance management, built with Next.js and PostgreSQL, deployed on a single server. I had three kinds of AI help available:

• The main assistant — the most careful one, but with the tightest weekly limit.
• A coding agent with a generous allowance, good at writing code and running long test suites.
• Four accounts on a fast, cheap model with large token allowances, good for small single tasks such as summaries, one-file edits and translations.

The rule I settled on is simple:

• Small, self-contained tasks go to the fast model accounts.
• Coding, test runs, verification and read-only reviews go to the coding agent.
• The main assistant only handles security-sensitive code (sign-in, permissions, tenant separation), releases, and one short review of anything the others changed.

That split alone moved most of the token spend off the scarce assistant.

Step-by-step setup

Step 1: Write every task as a self-contained spec file

The other assistants have none of your conversation history. So each task becomes a small Markdown file in the project, for example reports/codex-<task>.spec.md, with:

• what already exists and where,
• exactly what to build or check,
• the rules (work in a separate git worktree, never touch the live database, never push, plain commit messages),
• what "done" means, including which tests must pass.

A good spec is the difference between a helper that finishes and one that wanders. It also leaves a written record of what was asked.

Step 2: Run the coding agent in a visible terminal

Instead of launching the coding agent as a hidden background job, it runs inside a named tmux session. A task is handed to it by typing into that session:

tmux send-keys -t codex-app "Read reports/codex-task.spec.md and do it exactly as written." Enter

The benefit is human, not technical: I can attach to the session at any time and watch what it is doing, instead of trusting a summary afterwards.

Step 3: Watch it with a script that costs nothing

Asking the main assistant "is it done yet?" every few minutes burns its quota on reading screens. So a small bash script does the watching instead. Every 60 seconds it captures the last lines of the tmux pane and decides one of three states:

• working — the agent's "press Esc to interrupt" hint is visible,
• idle — the normal input prompt is back,
• waiting — it is asking a yes/no question.

On each change it writes a line to a log, sends me a phone notification, and, if a task is queued, types the next spec into the session. Checking progress now costs one line of output:

codex-watch.sh status
# codex-app: working since 19:42 | task: reports/phase1.spec.md | queue: 1 | watcher: yes

No AI is involved in watching, so it uses no tokens at all.

Step 4: Let the small-task relay pick the account with the most quota

For small jobs, a relay script checks every account's remaining quota first, orders them (the large-allowance accounts first, then whoever has the most left), and runs the task on the top one. If that account hits its limit mid-task, the tool prints a quota error, the relay recognises it, and starts the next account with a note: an earlier attempt may have left partial work, so inspect it and finish rather than start again.

One honest limit: what carries over is only what was saved to disk. The first account's reasoning is gone; the next one re-reads the files.

Step 5: Hand over deployment with a written guide

Deploying is the riskiest step, so it got its own document: a numbered merge-and-deploy guide written from the steps that had actually worked on previous releases. It covers checking each branch, merging, building in a separate worktree, backing up the database and environment file, applying migrations, switching the live release, smoke tests, and rollback. Every point where the agent must stop and ask a person is marked STOP.

With that guide, the coding agent could do a full release while the main assistant only checked the result.

What went wrong, and what it taught me

The setup worked, but not on the first try. Each failure became a line in the guide.

• A false "do not deploy". The watcher appended "do not merge, push or deploy" to every task it sent. That safety line silently overrode an approved deploy, so the agent stopped after its checks. Fix: each spec file states what is allowed; the sender adds nothing.
• A quiet build mistaken for a hung build. The production build prints almost nothing for most of its 30 minutes. The agent waited 48 minutes, saw no new output, and stopped it. Fix: judge a build by its CPU time still growing, not by output.
• The agent paused itself on low quota. Its own rule was to stop below 5 percent of its five-hour limit. That was correct behaviour, so a tiny scheduled script resumed the task a few minutes after the limit reset.
• Hundreds of type errors that were not real. The test copy reused generated database client code from the main folder. Regenerating it inside the copy made every check pass.
• A label that lagged one release. The update log marked new entries as "live" in a commit made after the build, so the running app still said "built". Fix: mark them live before the build, and undo that commit if the deploy fails.

None of these were dramatic, but each one would have cost a confused hour without a log to read.

Images cost tokens too: how to count them

When quota is tight, it helps to know what a screenshot costs. A common habit is to paste screenshots of error messages, terminals or web pages into the chat. That is often the most expensive way to share the same information.

How text is counted

For English text, a useful rule of thumb is about 4 characters, or about three quarters of a word, per token. So 100 words is roughly 130 tokens, and a full page of 1,000 words is roughly 1,300 tokens. The exact number depends on the model's tokenizer, but this estimate is close enough for planning.

How an image is counted

An image is not counted by its file size. A 9 MB photo and a 200 KB screenshot with the same width and height cost the same. What matters is the number of pixels the model actually looks at.

Most assistants work roughly like this:

1. The image is shrunk if it is larger than a limit (for one widely used model family, a long side of about 1,568 pixels, or about 1.15 megapixels in total).
2. The cost is then about width x height / 750 tokens.

So a full-size image usually lands somewhere between 1,000 and 1,600 tokens, whatever it shows. Check your own provider's documentation for the exact limits, because they differ and they change.

Practical examples: same information, text versus image

Here are four situations from this week, worked out with the rules above.

Example 1: a one-line error message. The text Error: Cannot find module '.next/standalone/server.js' is about 15 tokens. A screenshot of the terminal showing that line, captured at 1920 x 1080 and shrunk to about 1,430 x 805, costs about 1,430 x 805 / 750, or roughly 1,530 tokens. That is about 100 times more for the same sentence.

Example 2: a page of documentation. A 1,000-word page as copied text costs about 1,300 tokens. The same page as a 1200 x 1600 screenshot is shrunk to about 930 x 1240, which costs about 1,540 tokens. The cost is similar, but the image is worse: small text can become hard to read after shrinking, and the assistant cannot search or quote it exactly. Text wins.

Example 3: a very tall full-page capture. A browser "capture whole page" screenshot was 2,434 x 27,211 pixels. Viewed in one go, it would be shrunk to about 140 pixels wide, so nothing would be readable. To read it properly it has to be cut into about 12 to 14 screen-sized slices at about 1,500 tokens each, so 18,000 to 25,000 tokens. The text on that page, copied out, would have been around 3,000 words, so roughly 4,000 tokens.

Example 4: a dashboard where the layout is the question. A normal 2408 x 644 screenshot of a page header, shrunk to 2000 x 535, costs about 1,430 tokens. Here the image is the right choice: the question was "why does this badge say Built and not Live", and the colour, position and wording of the badge mattered. Describing that in text would have been slower and less reliable.

Markdown versus PDF for the same document

The same logic applies to documents. A Markdown (.md) file is plain text, so it costs only its text tokens. The assistant can also read just part of it, such as one section, or search it for a word.

A PDF usually costs more. Many assistants give the model both the text extracted from each page and an image of each page, so it can see layout, tables and charts. That page image adds roughly 1,500 tokens or more per page on top of the text.

Example 5: a 10-page report of about 4,000 words. As Markdown it costs about 5,000 to 5,500 tokens. As a PDF it costs about 5,000 tokens of text plus 10 page images at about 1,500 each, so roughly 20,000 tokens, three to four times more for the same words.

A PDF is still the right choice when the document is a scan (pictures of pages with no real text, unless you run text recognition first), when the layout, charts or design are what you want checked, or when it is all you have. Even then, extracting the text first is usually much cheaper:

pdftotext -layout report.pdf report.txt

Rules of thumb

• Share text when the content is text: error messages, logs, code, configuration. Copy and paste it.
• Share an image when the look is the point: layout, colours, alignment, a broken design.
• Crop to the part that matters. A crop of one panel costs the same as a full screen but shows the detail at a readable size.
• Avoid giant full-page captures. Take a normal screenshot of the section in question instead.
• Send Markdown or plain text instead of PDF when you only need the words read; keep the PDF for scans and layout checks.
• Remember that file size is irrelevant. Compressing a screenshot does not make it cheaper; making it smaller in pixels does, up to the point where it is still readable.

Conclusion

You do not need one perfect AI assistant. You need clear task files, a sensible split of who does what, a free way to watch progress, and a written deploy guide with hard stop points. With that, a near-empty quota on your main assistant slows you down very little.

Merits

• Most token spend moves to assistants with larger allowances.
• Progress tracking costs nothing because a plain script does it.
• Work stays visible in a terminal you can attach to at any time.
• Written specs and guides make each task repeatable and auditable.
• Failures turn into guide updates, so the same mistake does not repeat.

Demerits

• Writing good specs takes real effort up front.
• Only saved files survive a handover between accounts; in-progress reasoning is lost.
• Screen-scraping a terminal to detect state is fragile and needs tuning.
• Several assistants means several sets of rules and habits to keep consistent.
• A person still has to approve releases, so it is not fully hands-off.

Caution

This article is educational and describes one personal setup. Names, paths, session names and commands are examples or placeholders and must be replaced with your own. Usage limits, tool behaviour and pricing change often, so verify how your own assistants count and reset quota before relying on any of this, and never let an automated helper deploy to a system that serves real customers without a human approval step and a tested rollback.

Frequently asked questions

• Why split work across several AI coding assistants? — Each has its own usage limit and strengths, so routing tasks by type keeps the scarcest one free for work that needs the most care.
• How can I track an AI agent without spending tokens? — Run it in a tmux session and use a small shell script that reads the terminal and logs state changes; no AI is needed for that.
• What happens when one account runs out of quota mid-task? — A relay can detect the quota error and restart the task on the next account, which continues from the files already saved.
• Is it safe to let an AI agent deploy to production? — Only with a written guide, backups, smoke tests, automatic rollback and a human approval step.
• Why did my build look hung when it was not? — Production builds can be silent for long periods; check whether CPU time is still growing before stopping one.
• What should a task spec file contain? — Context, the exact goal, the rules and limits, and a clear definition of done including tests.
• Is a Markdown file cheaper than a PDF for an AI assistant? — Usually yes; Markdown costs only its text tokens, while a PDF often adds an image of every page, making it three to four times more expensive.
• How many tokens does a screenshot cost an AI assistant? — Roughly width times height divided by 750 after the image is shrunk, which usually means 1,000 to 1,600 tokens per full-size image, regardless of file size.

Tags

#aicodingassistants #developerproductivity #devops #tmux #automation #llmquota #imagetokens #deployment #codingagents #softwareengineering