14 — AI Gateway and Email Workers: Two Specialized Edge Layers

Two products I kept filing under "miscellaneous edge features" — AI Gateway and Email Workers — have nothing to do with each other, which is exactly why conflating them hid both. Pulled apart, each is a focused layer for a specific kind of traffic: AI Gateway is a control plane in front of AI providers, and Email Workers is a compute layer for incoming email. [1][2] Different problems, same shape — a Worker sits in front of some traffic and applies logic to it.

The framing that landed is what each one is _not_. AI Gateway is not where models run (that's Workers AI); it's the layer between my code and wherever the models _do_ run, including external providers. Email Workers is not an email server I host; it's a hook into Cloudflare's email routing that lets a Worker intercept and act on mail addressed to my domain.

AI Gateway: control over AI traffic

When an application calls an AI provider — OpenAI, Anthropic, Hugging Face, even Workers AI — the default experience is a direct HTTP call from my code to the provider's API. That works, but it leaves me with no control over the traffic. AI Gateway inserts itself as a layer between my code and the provider(s), and the value is entirely in what that layer can do [1][3]:

• Caching. Identical prompts return cached results instead of re-calling the provider. For non-deterministic workloads this is huge — repeat queries cost nothing and return instantly.
• Rate limiting. Cap requests per second to a provider, so a bug or a traffic spike doesn't blow through an API quota or budget.
• Observability. Logs and metrics on every request — which model, what latency, what cost, what status. The traffic that was previously opaque becomes queryable.
• Routing and fallback. Send requests to one provider, fall back to another on failure, or load-balance across providers. Reduces single-provider lock-in at the runtime layer.

The model that clicked: AI Gateway is to AI calls what an API gateway is to any API traffic. It's the place where cross-cutting concerns (cache, limit, observe, route) live, so my application code is just "produce a prompt, send it, get a result" and the policy is centralized.

The distinction from Workers AI is worth restating, because it's easy to conflate. Workers AI _runs_ models at the edge. AI Gateway _manages traffic to_ models, wherever they run — including Workers AI, including external providers. They compose: I can put an AI Gateway in front of Workers AI to get caching and observability on those calls too. Workers AI is the compute; AI Gateway is the policy layer.

Email Workers: code on incoming mail

Email Workers is the email equivalent of an HTTP Worker — instead of intercepting an HTTP request, it intercepts an incoming email addressed to a domain I control [2][4]. The email arrives at Cloudflare's mail routing; instead of (or in addition to) forwarding it to a mailbox, Cloudflare runs my Worker against it.

The capabilities the Worker has, mapped to the three layers in the reference [5][6][7]:

Routing

The Worker decides where the email goes [5]. Based on the sender, recipient, subject, or any other header, the Worker can:

• Forward to one or more mailboxes.
• Trigger custom logic — fire a webhook, write to a database, enqueue a task.
• Reject (bounce) the message outright.

This is routing as code, not as a static rules file. A rule like "if the sender is in this KV list of VIPs, forward to my phone; otherwise file in the inbox" becomes a few lines of Worker code rather than a fragile filter chain in a mail client.

Processing

Once the email is routed to the Worker, the Worker can read and manipulate its contents [6]:

• Read headers, body (text and HTML), and attachments.
• Extract data — parse a confirmation number, pull a tracking link, scrape structured content.
• Modify the message — append a disclaimer, translate, redact.
• Trigger downstream work — store an attachment in R2, post the parsed data to an API, kick off a Workflow.

The pattern that clicked: an inbox becomes an API. Any service that sends email (Stripe receipts, GitHub notifications, monitoring alerts) becomes a structured input to my application, not just a message a human reads. The Worker turns the email into data and an action.

Filtering

Filtering is the selective layer — which emails the Worker processes at all, and how [7]. The rules can be based on:

• Sender or recipient address, or domain.
• Subject-line keywords or patterns.
• Header values (a list-id, a spam score).
• Body content.

A common pattern: filter to detect spam or phishing (a known-bad sender list, suspicious link patterns), filter to classify (transactional vs. personal vs. alert), then route and process accordingly. The filtering happens before the heavy processing, so the Worker doesn't waste effort on messages it doesn't care about.

How these two fit together

The unifying shape is "a Worker in front of a traffic stream it can intercept." For AI Gateway, the stream is calls to AI providers and the value is centralized policy. For Email Workers, the stream is incoming mail and the value is programmatic control over routing and processing. Neither is a compute product in the Workers-AI sense — both are control planes for a specific kind of traffic.

How I use this

For AI Gateway: I reach for it the moment an application makes more than a handful of AI calls per day, because the observability alone pays for itself — knowing what's being called, at what latency, at what cost, is the difference between an AI feature I can operate and one I can't. Caching is the second win, and it's often larger than I expect.

For Email Workers: I use it when email is an input to my system, not just a human-readable notification. The trigger is usually "I'm getting an email I want to turn into data" — receipts, alerts, form submissions, third-party notifications. For purely human-to-human mail, a regular mailbox is simpler.

References

[1] Cloudflare, "Cloudflare AI Gateway," Cloudflare Developer Platform, 2024. [Online]. Available: https://www.cloudflare.com/developer-platform/products/ai-gateway/

[2] Cloudflare, "Email Workers — Cloudflare Email Routing," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/email-routing/email-workers/

[3] Cloudflare, "Cloudflare + AI," ai.cloudflare.com, 2024. [Online]. Available: https://ai.cloudflare.com/

[4] Cloudflare, "Announcing route to Workers — automate your email processing," Cloudflare Blog. [Online]. Available: https://blog.cloudflare.com/announcing-route-to-workers/

[5] Cloudflare, "Email Workers — Cloudflare Email Routing," Cloudflare Docs. [Online]. Available: https://developers.cloudflare.com/email-routing/email-workers/

[6] Cloudflare, "Email Workers routing — Runtime API," Cloudflare Docs. [Online]. Available: https://developers.cloudflare.com/email-routing/email-workers/runtime-api/

[7] G. Chmr, "Implementing an email delivery service with Cloudflare Workers," Medium. [Online]. Available: https://medium.com/@georgechmr/implementing-an-email-delivery-service-with-cloudflare-workers-c141422109d0