I found the dumbest way to burn 500 LLM calls a day: polling an inbox every 5 minutes

If your OpenClaw agent checks an email inbox every 5 minutes, you’re probably paying for idle paranoia. Microsoft Graph and Gmail both recommend push-style notifications instead of polling, and one OpenClaw user reported nearly 500 wasted LLM calls per day from an MS365 mailbox loop that kept re-checking old mail.

I knew email-triggered agents were messy.

I did not expect them to still be this messy.

While researching OpenClaw workflows, I came across a thread on r/openclaw that felt painfully familiar. One user wrote: "At the moment, I have Openclaw job where agent checks its ms365 mailbox every 5 minutes... Wasted calls to LLM (nearly 500 calls to LLM per day)".

That sentence should bother anyone building production agents.

Not because polling is evil in some abstract architecture-purity way. Because it’s the exact moment your “cool automation” quietly turns into a machine for wasting model calls, reprocessing old messages, and occasionally embarrassing you by replying twice.

And the worst part? Polling an inbox every 5 minutes is still the default answer people reach for.

It’s easy. It works in a demo. It feels harmless.

Then your agent grows up.

The toy version works right until it doesn’t

Here’s the basic pattern everyone starts with:

1. Connect OpenClaw to an inbox
2. Check every 5 minutes with IMAP or Microsoft Graph
3. If there’s a new message, send it to GPT-5 or Claude
4. Hope you don’t process the same email twice

For a proof of concept, that’s fine.

Actually, I’ll go further: if you control one mailbox, volume is tiny, and you keep a local dedupe store in SQLite, polling can be good enough for a small internal workflow. Not elegant. Just good enough.

But “good enough” has a short shelf life.

Once the inbox matters, the cracks show up fast:

• you keep checking when nothing changed
• you burn model calls on already-seen messages
• you add brittle sender whitelists because you don’t trust intake
• you get delays by design
• you create weird failure modes when a scan runs late or twice

That last one is the killer.

In the same r/openclaw discussion, another user said: "I abandoned the interval based scanning... if the scan got out of sync I had repeated responses (more wasted calls) or ignored mails. I failed to get it to be reliable."

That’s the whole story in one sentence. Polling doesn’t just waste money. It makes your agent feel flaky.

And flaky is worse than expensive.

Why are Microsoft and Google both telling you to stop?

This is the part that surprised me.

The anti-polling advice isn’t coming from architecture snobs on Hacker News. It’s coming from Microsoft and Google themselves.

Microsoft Graph has change notifications specifically so apps can react to mailbox changes instead of hammering the API on a timer. Microsoft’s own docs frame this as a way to avoid throttling pressure and support near-real-time reactions.

Gmail says it even more plainly with push notifications: push "eliminates the extra network and compute costs of polling resources to determine if they've changed."

That’s not subtle.

If both Microsoft 365 and Gmail are telling you the same thing, you should probably listen.

Gmail’s production path

For Gmail, the clean setup is Gmail API watch on the INBOX label, publishing changes to Google Cloud Pub/Sub, which then hits your webhook.

It looks like this:

POST https://gmail.googleapis.com/gmail/v1/users/me/watch
Content-Type: application/json
{
  "topicName": "projects/myproject/topics/mytopic",
  "labelIds": ["INBOX"],
  "labelFilterBehavior": "INCLUDE"
}

Google returns a historyId and an expiration timestamp. That expiration matters. You have to renew the watch before it expires.

So yes, push is cleaner. No, it is not free magic.

You need Pub/Sub, a topic, a subscription, and the right permissions for gmail-api-push@system.gserviceaccount.com to publish. If you skip the boring setup work, your “event-driven” architecture becomes a very sophisticated outage.

Microsoft 365’s production path

For Microsoft 365, the equivalent move is Microsoft Graph change notifications for Outlook messages.

You create a subscription, validate notifications, and renew the subscription before it expires. Microsoft also documents a limit of 1000 active Outlook-resource subscriptions per mailbox for all applications, which is the kind of detail nobody cares about until they absolutely do.

There’s also clientState, which you can use to validate notifications, and Microsoft allows up to 128 characters there.

Again: cleaner than polling, but only if you treat lifecycle management as part of the design.

That sounds annoying. It is annoying.

It is still better than burning cycles forever because you didn’t want to set up a webhook.

Isn’t n8n enough?

Usually, this is where someone says, “Fine, I’ll just use n8n.”

Reasonable instinct. Wrong conclusion.

I found another r/openclaw thread where people were thinking through OpenClaw + n8n architectures, and it highlights a real distinction: n8n can absolutely improve the workflow, but it doesn’t magically turn polling into event-driven intake.

The n8n Email Trigger (IMAP) is still mailbox-checking infrastructure. Better mailbox-checking infrastructure, sure. But still mailbox-checking.

What n8n’s IMAP trigger does well

n8n gives you useful controls:

• mailbox selection
• mark-as-read behavior
• attachment download
• custom email rules/search filters
• Force Reconnect Every Minutes

That’s a lot better than a hand-rolled cron job glued to a Python script and a prayer.

But if the source of truth is still “go ask the mailbox if anything happened,” you haven’t really solved the core issue. You’ve just made the polling loop more civilized.

For some teams, that’s enough.

For a production OpenClaw agent that must react quickly and reliably, I don’t think it is.

What actually counts as a real inbound event?

This is where the architecture gets cleaner.

A real inbound event means the email provider or email service tells you when a message arrives. You don’t keep knocking on the door asking if anything changed.

That can take a few forms:

• Twilio SendGrid Inbound Parse Webhook
• Gmail watch + Google Cloud Pub/Sub
• Microsoft Graph change notifications
• email-native services people mention in OpenClaw threads, like AgentMail

The cleanest mental model is SendGrid.

SendGrid’s Inbound Parse Webhook receives the email, parses it, and POSTs the content and attachments to your endpoint. If your endpoint returns a 5XX, SendGrid retries. If you return 2XX, retries stop. It does not follow redirects. And it will retry for up to 3 days before dropping the message.

That retry behavior is a huge production advantage.

Polling loops fail in mushy ways. Maybe the cron job ran. Maybe the mailbox state changed. Maybe your dedupe logic worked. Maybe it didn’t. Webhook delivery gives you a much sharper contract.

There are constraints, of course. SendGrid documents a 30 MB total message size limit, including attachments. Setup also requires an MX record on a dedicated receiving subdomain pointing to mx.sendgrid.net with priority 10.

That’s more work than polling.

It’s also how adults build email intake.

Polling vs push: which one breaks first?

Here’s the practical comparison.

Approach	What you’re really signing up for
Polling mailbox with IMAP or cron	Setup complexity: low. Trigger model: interval polling. Failure mode: duplicate checks, wasted model calls, delayed reactions.
n8n Email Trigger (IMAP)	Setup complexity: low to medium. Trigger model: mailbox trigger via IMAP connection/search rules. Useful features: mark as read, attachment download, custom email rules.
Webhook or push intake (SendGrid Inbound Parse / Gmail watch / Microsoft Graph notifications)	Setup complexity: medium. Trigger model: event-driven POST or push notification. Production traits: lower idle waste, faster reaction, better retry/lifecycle controls.

That’s the real tradeoff.

Not “simple versus advanced.”

It’s demo-friendly versus production-friendly.

So what should an OpenClaw email trigger look like?

If I were building this today, I’d split it into two layers.

Layer 1: intake

Use one of these:

• SendGrid Inbound Parse Webhook if you want straightforward inbound email to HTTP
• Gmail watch + Pub/Sub if the mailbox lives in Google Workspace
• Microsoft Graph notifications if the mailbox lives in Microsoft 365
• n8n IMAP trigger only if you need a fast proof of concept and accept polling-shaped tradeoffs

Layer 2: idempotent processing

This part matters just as much.

No matter how the event arrives, your OpenClaw job should:

1. extract a stable message ID
2. check a dedupe store before calling GPT-5, Claude, or any other model
3. persist processing state
4. acknowledge receipt quickly
5. do heavier work asynchronously if needed

That last point is where teams get themselves into trouble. They try to fully process the email inside the webhook request itself.

Don’t.

Accept the event. Store it. Deduplicate it. Then hand it off.

That’s how you survive retries without duplicate replies.

The weirdly hard part isn’t triggering the agent

It’s trust.

The Reddit user with the MS365 polling loop also mentioned relying on sender-based whitelisting and feeling that it was weak. They were right. Sender checks alone are flimsy.

A production email intake path should also think about:

• envelope recipient or dedicated receiving address
• provider signatures or validation tokens where available
• attachment handling rules
• message size limits
• mailbox isolation per workflow

This is why “just check the inbox every 5 minutes” feels so attractive. It postpones all the real design questions.

But postponing them doesn’t remove them. It just means they come back later with duplicated messages and wasted LLM calls attached.

When is polling actually okay?

I don’t want to pretend every email-triggered OpenClaw job needs Pub/Sub, Graph subscriptions, and a dedicated SendGrid subdomain on day one.

Sometimes polling is the right shortcut.

Use it when:

• one internal mailbox is enough
• volume is low
• a few minutes of delay is fine
• you have dedupe in SQLite or Postgres
• nobody will care if you rebuild it later

That’s a proof of concept.

Just call it a proof of concept.

The mistake is treating that architecture like it’s ready for a customer-facing or always-on agent.

It isn’t.

The line between a toy automation and a production agent

I think the cleanest insight from those r/openclaw threads is this: the difference is not whether OpenClaw can read email.

Of course it can.

The difference is how the email arrives, and whether your processing is idempotent after it does.

A toy automation asks the mailbox every few minutes if anything happened.

A production agent gets an event, validates it, records it once, and processes it once.

That sounds less exciting than model benchmarks or prompt tricks. But it’s the kind of boring decision that determines whether your agent feels solid after three months or turns into a haunted house of duplicate replies.

If your OpenClaw workflow still polls an inbox every 5 minutes, I wouldn’t call it broken.

I’d call it unfinished.

And once you’ve seen "nearly 500 calls to LLM per day" wasted on mailbox checks, it’s hard to unsee.