The biggest speed win in many agent workflows is fast agent cold start work, not prompt rewriting. OpenAI says cutting 50% of output tokens may cut latency by about 50%, but cutting 50% of input tokens often improves latency only 1–5%. In n8n, Make, Cloud Run, and Lambda, the first delay often happens before GPT-5 or Claude is even called.
I figured this out the annoying way.
I had a workflow that looked perfectly reasonable on paper. Webhook comes in. n8n picks it up. A worker runs some logic. GPT-5 or Claude Opus 4.6 gets called. Response goes back. Simple.
But users kept describing it with the same cursed sentence: “It feels slow before it even starts thinking.”
That line bothered me because it was too specific. People were not saying the model was rambling. They were saying the workflow felt dead on arrival. No spinner energy. No sense that anything was happening. Just a pause.
So I did what a lot of us do first. I attacked the prompt.
I trimmed instructions. Removed examples. Shortened system messages. I got precious about every token like I was tuning a Formula 1 car with a toothbrush.
And yes, some of that mattered. But not where I expected.
The real problem was happening before the model call. Once I saw that, a lot of "AI latency" stopped looking like AI latency at all.
The embarrassing part: my prompt wasn’t the main problem
OpenAI is actually pretty blunt about this in their latency guidance. Generating tokens is usually the biggest latency component. If you cut output length by 50%, latency can drop by about 50% too.
But cutting input tokens is often way less dramatic. OpenAI says trimming 50% of prompt/input tokens may improve latency by only 1–5% unless the context is huge.
That was the first punch to the ego.
I had spent hours shaving prompt text that maybe saved a few percentage points, while the workflow was burning time in webhook handling, queue handoff, worker startup, dependency loading, and scale-from-zero delays. Classic engineer move: optimize the visible thing, ignore the line of people waiting outside the building.
And once I started tracing requests end to end, the pattern got obvious.
Where is the delay actually hiding?
If your agent feels slow, split the timeline into three parts:
- Trigger latency — how long it takes to accept the webhook or event
- Worker/startup latency — how long it takes before your code is actually running
- Model latency — how long GPT-5, Claude Opus 4.6, Grok 4.20, Qwen, or Llama takes to produce tokens
Most teams stare at part 3 because it’s the sexy part.
A lot of real pain lives in parts 1 and 2.
n8n is a perfect example
In n8n queue mode, the main instance receives the webhook, creates an execution, pushes the execution ID to Redis, and then a worker pulls that job and loads workflow data from the database.
That means your “slow AI workflow” may be waiting on queue orchestration and worker availability before GPT-5 ever sees a token.
And queue mode absolutely has a purpose. It improves scalability. It’s the right move for a lot of serious workloads. But it also means you should stop pretending every millisecond belongs to the model.
A typical setup looks like this:
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=<redis-host>
QUEUE_BULL_REDIS_PORT=6379
That config is fine. The mistake is assuming queue mode is free from a latency perspective. It isn’t.
n8n even documents that webhook calls are handled by the main instance and delegated through Redis to workers, and in queue mode the webhook response can travel back from the worker to the main instance through the queue. That is useful architecture. It is not magic.
And then I noticed Make had the same lesson hiding in plain sight.
Why did the same automation feel fast in Make one day and sluggish the next?
Because Make lets you choose behavior that changes perceived latency a lot more than people expect.
An instant webhook executes immediately and, by default, in parallel. A scheduled webhook stores requests in the webhook queue and processes the whole queue later on schedule.
Same business logic. Totally different vibe.
If you are testing a scenario and thinking, “Claude feels slow today,” there’s a decent chance Claude is innocent and your orchestration mode is the real culprit.
That’s the pattern I keep seeing across background ai processes: people blame prompts and models first because those are visible, while the workflow engine and compute layer quietly eat the first second or two.
That’s where serverless makes things even more interesting.
What if your worker is asleep when the webhook arrives?
This is the classic cold start problem, and it’s still very real.
On Google Cloud Run, scaling from zero can introduce slow container start times. Google explicitly recommends minimum instances to reduce service latency, and even suggests configuring at least 3 minimum instances for high availability.
They’re not subtle about it. If min-instances is set to 10 and active instances are 0, Cloud Run keeps 10 idle instances ready.
If you need your agent endpoint to feel alive, this matters more than another round of prompt dieting.
Here’s the dead-simple command:
gcloud run services update SERVICE --min-instances=3
On AWS Lambda, the equivalent conversation is Provisioned Concurrency and SnapStart. Same idea: reduce initialization delay without rewriting your application logic.
This is why I’ve become weirdly opinionated about a good headless ai server setup. If the first request after a quiet period matters, I would rather pay for warm capacity than keep pretending scale-from-zero is free.
Not always. But often.
The fastest front door I’ve used wasn’t a container at all
The biggest surprise for me was how good Cloudflare Workers are as a lightweight ingress layer.
Cloudflare’s runtime uses isolates, not the usual container-or-VM startup model. Cloudflare says isolates are designed to start very quickly and can start around 100x faster than a Node process on a container or virtual machine.
Their limits page also lists Worker startup time as 1 second maximum, and Cloudflare says the average Worker uses about 2.2 ms CPU time per request.
That doesn’t mean Cloudflare Workers should run every heavy agent task. They shouldn’t.
It means they’re excellent for the fast acknowledgment part. Accept the webhook at the edge. Validate it. Write a job. Return immediately. Let the slower downstream work happen elsewhere on Cloud Run, AWS Lambda, n8n workers, or your own backend.
That architectural split changed how my workflows felt more than any prompt rewrite did.
The options I’d actually choose
| Option | What it’s good at |
|---|---|
| AWS Lambda Provisioned Concurrency | Keeps execution environments initialized for double-digit-ms startup; best for predictable traffic or strict latency SLOs; costs extra for pre-provisioned capacity |
| Google Cloud Run Min Instances | Keeps container instances warm to reduce scale-from-zero latency; great for HTTP agent backends and webhook handlers; billed for warm instances and still subject to restarts |
| Cloudflare Workers Isolates | Isolate-based runtime designed for very fast startup; ideal for fast webhook ingress and lightweight edge logic; different runtime model and limits than Node or container serverless |
If I had to pick winners:
- Cloudflare Workers win for fast webhook ingress and immediate acknowledgment
- Cloud Run min instances win for HTTP-heavy agent backends that need normal container ergonomics
- Lambda Provisioned Concurrency wins when AWS is already home and latency SLOs are strict
Prompt optimization still matters. But for first-response feel, these levers are often stronger.
How I make slow agent workflows feel instant now
This is the playbook I wish I had started with.
1. Acknowledge first, think second
If a user or another service is waiting on a webhook, return fast.
In n8n, one clean pattern is setting the Webhook node Respond option to Using 'Respond to Webhook' node, then placing a Respond to Webhook node early enough to control when the HTTP response goes out.
That lets you separate “request accepted” from “full agent run completed.” Huge difference in perceived speed.
2. Prewarm anything container-shaped
If you run agent backends on Cloud Run, set minimum instances.
If you run on AWS Lambda, look at Provisioned Concurrency or SnapStart. If you own the VM, keep a worker process hot and stop rebooting the world for every request.
3. Trim startup dependencies before touching prompts
A lot of “cold start” pain is self-inflicted.
If your worker boots Python, loads half of Hugging Face, imports five SDKs, opens three database clients, and initializes observability before doing useful work, you built a latency tax collector.
Cut imports. Delay noncritical initialization. Move bulky setup out of the request path.
4. Separate trigger latency from model latency in your logs
Don’t log “request took 4.2s” and call it a day.
Log:
- webhook received timestamp
- queue publish timestamp
- worker start timestamp
- model request start timestamp
- first token timestamp
- final response timestamp
Until you can see those boundaries, you are guessing.
5. Only optimize prompts where prompts actually matter
If your agent writes long reports, model generation time can still dominate. OpenAI’s guidance is clear here.
If you cut output tokens by 50%, you may cut latency by about 50%. That’s real. So yes, shorten verbose outputs when speed matters.
But don’t confuse that with fixing a cold worker, a queued webhook, or a sleeping container.
So are cold starts always the villain?
No. And this is where people overcorrect.
If your workflow asks GPT-5, Claude Opus 4.6, or Grok 4.20 to produce a long structured answer, token generation can absolutely be the main bottleneck. Cold starts are not a universal explanation.
Prewarming also costs money. Cloud Run minimum instances are billed, and Google says the minimum is a best-effort target, which means it can temporarily drop below the configured floor. Warm capacity is useful, not magical.
Still, I’d rather make that trade consciously than spend another week rewriting prompts for a 3% win while Redis, queueing, and worker startup quietly steal the first second.
That was the real lesson for me.
The fastest workflows don’t always think faster. They just start faster.
And once you see that, you stop blaming the model for problems that began long before GPT-5 or Claude got the request.