fast-mailer: how taking the model out of the send step cut an email to seconds

BUILD STORY · AGENT TOOLING

An agent that takes one to four minutes to send a single email is not thinking hard. It is waiting: for a browser to load, for a button to appear, for its own next turn. The author of fast-mailer, a small open-source repo published on September 24, 2026, says a friend ran into exactly this. The fix was not a smarter model. It was taking the model out of the one part of the job that never needed it.

QUICK ANSWER

Why it is fast

The agent writes the email and hands it off. A plain script builds the message and posts it straight to the Gmail API. No browser, no extra tool server starting up, no model call between "send" and "sent".

The problem: an agent doing a script’s job

Many agent setups send mail the way a person would: open Gmail in a browser, click Compose, type, click Send. Each step is a round trip through the model, which looks at the page and decides what to do next. The repo's own skill file ranks the browser route last and labels it "minutes - last resort only". The author did not publish exactly how the friend's agent was sending before, so the browser path is the likely suspect, not a confirmed one.

What is in the repo

Part	What it does
send.py	Python standard library only. Builds a MIME message, refreshes the OAuth token in memory, posts to Gmail's send endpoint, prints JSON with the message ID and time taken.
triggers/ folder	Drop a .txt or .json file per email, then run python send.py watch --once. Sent files move to triggers/sent/, failures get a .failed suffix.
cli/gmaild.mjs	Optional Node 18+ daemon on 127.0.0.1 that keeps a warm TLS connection to Gmail and refreshes the token every 5 minutes.
cli/auth-server.js	One-time Google sign-in that stores a refresh token in secrets/.
skills/fast-mailer/SKILL.md, AGENTS.md	Instructions that tell Claude Code, Cursor, ZCode and similar tools which command to run, plus a ZCode plugin wrapper.

Where the 14 seconds come from

Before: agent drives a mail UI, one model turn per click→After: agent writes to, subject, body→One shell command→Script posts to Gmail API→JSON: message_id + ms

The send call is short. The heart of send.py is one HTTPS POST of a base64-encoded message to gmail.googleapis.com/gmail/v1/users/me/messages/send, the endpoint Google documents for this. The README puts that at 0.6-1 second cold and about 0.5 second with the daemon.

So where do the other ~13 seconds go? That part is my reading, not a measurement: the agent still has to read the request, write the command, wait for the result and reply. That is one model turn instead of dozens. The skill file even tells the agent to answer with "only the message_id + ms. No narrative", which trims the last step too.

The speed-up is not a faster send. It is fewer model turns between asking and done.

What I checked in the code

I ran send.py offline in a sandbox with fake credentials and the network call replaced, so nothing was sent. Building the message took about 1.4 ms. The security claims in the README held up in the paths I tested:

• Only two hosts are allowed: oauth2.googleapis.com and gmail.googleapis.com. A request to any other URL is refused.
• Trigger file names must match a strict pattern. ../x.txt, names with spaces and hidden files were rejected.
• Before each request the host is resolved and blocked if it points at a private or local address. Redirects are capped at 2.
• The Python sender never writes the token file. The daemon writes refreshed tokens with file mode 0600.

One gap: the subject and recipient fields are not checked for line breaks. In my offline test, a subject of Hello + newline + Bcc: attacker@example.net produced a real extra Bcc header. If the agent only sends text you typed, that does not matter. If it can put text from a web page or an incoming email into a subject line, it does. A short fix:

# add at the top of send_email() in send.py
for field in [to, subject, sender or ""] + list(cc or []):
    if "\r" in field or "\n" in field:
        raise ValueError("line break in a header field")

Try it: time your own path

To see where your agent's time goes, time the script alone and compare it with the whole agent turn. The script returns its own ms field; this wrapper adds wall-clock time around it:

start=$(date +%s.%N)
python send.py you@example.com "timing test" "hello" | tee /tmp/send.json
end=$(date +%s.%N)
echo "script wall time: $(echo "$end - $start" | bc) s"
# the gap between this and the agent's full reply time is model time

Analysis (Jack Gross)

The general lesson: keep the model off the hot path

The pattern is simple and worth copying beyond email. When a task has a fixed shape (to, subject, body), let the model fill in the fields and let plain code do the rest. Every step the model has to watch and approve costs seconds and adds a chance to go wrong. From 1-4 minutes to 14 seconds is roughly a 4x to 17x cut, and almost all of it comes from removing model turns, not from faster networks.

The trigger folder is the more interesting idea. It splits "decide what to send" from "send it". An agent, a cron job or a person can queue emails as files, and one scan sends them all. That also makes the outbox easy to inspect before anything goes out.

Limits to keep in view

• Brand new. Published the day this was written, v1.0.0, no tests in the repo, no outside users yet. The 14-second figure is one person's report from one setup.
• Wide permissions. Sign-in asks for gmail.modify and gmail.readonly. Google's docs list the narrower gmail.send scope as enough for sending. A stolen token from this setup can read and change your mail, not just send it.
• Header check. Add the line-break check above before feeding it untrusted text.
• Gmail limits still apply. Google caps sending per day (for example 2,000 messages per user on Google Workspace, 500 on trial accounts) and 500 recipients per API message. The script has no rate limiting or retry beyond one token refresh, so bulk runs will hit those caps.
• Speed cuts both ways. With no browser step there is no screen where a human glances at the draft. If your agent should ask before sending, that check now has to live in the agent's instructions.
• Setup friction. You need your own Google Cloud project and OAuth client, and the sign-in helper binds port 80 by default.
• Gmail only. No Outlook or generic SMTP, and no attachments in the current code.

Verdict

fast-mailer is a small, readable fix for a real and common problem, and its security model is more careful than most day-one tools. Treat it as a well-made starting point: narrow the scope to gmail.send, add the header check and keep a human approval step where it matters. The lesson travels well past email: fewer model turns beat a faster model.

FAQ

Does fast-mailer use an AI model to send email?

No. The agent writes the content, then a script sends it through the Gmail API with no model call in between.

Is 14 seconds the time to send one email?

It is the author's reported time for the whole agent turn. The send call itself is about 0.6-1 second according to the README.

Which agents does it work with?

Any agent that can run shell commands. The repo ships instructions for Claude Code, Cursor and ZCode.

Sources: fast-mailer on GitHub (code, README, SKILL.md, commit history, read September 24, 2026) · Gmail API: users.messages.send · Gmail sending limits in Google Workspace. Timings of 1-4 minutes and 14 seconds are the repo author's report.