I thought prompt tweaks would fix my slow agent, but the real win was chasing cold starts first

I spent way too long trimming prompts for a workflow that felt slow.

Not expensive. Not inaccurate.

Slow.

And not even in the obvious way.

Users kept saying some version of:

It feels slow before it even starts thinking.

That line turned out to be the clue.

I was blaming GPT-5 and Claude Opus 4.6 for latency that was happening before either model saw a single token.

Once I traced the full request path, the biggest speed wins came from fixing cold starts, queue handoffs, and webhook behavior — not from shaving a few lines off the system prompt.

If you run agents on n8n, Make, Cloud Run, Lambda, or your own serverless stack, this is probably worth checking before you do another prompt rewrite.

The part I got wrong

My mental model was simple:

1. webhook arrives
2. workflow starts
3. model gets called
4. response comes back

So I optimized the visible thing: the prompt.

I shortened instructions.
I removed examples.
I cut down system messages.
I obsessed over token counts.

Some of that helped.

But not much.

OpenAI's latency guidance is pretty clear on this:

• cutting output tokens can reduce latency a lot
• cutting input tokens often helps much less unless context is huge

The rough rule they give is:

• cut output tokens by 50% -> latency may drop by about 50%
• cut input tokens by 50% -> latency may improve by only 1–5%

That was the ego check.

I was polishing the prompt while the real delay was sitting in:

• webhook handling
• queue publish
• worker pickup
• cold container startup
• dependency loading
• scale-from-zero behavior

Classic engineering mistake: optimize the thing you can see, ignore the line of waiting work behind it.

Break agent latency into 3 buckets

If an agent feels slow, I now split the timeline like this:

1. trigger latency
2. worker startup latency
3. model latency

That means:

• Trigger latency: how long it takes to accept the webhook or event
• Worker startup latency: how long until your code is actually running
• Model latency: how long GPT-5, Claude Opus 4.6, Grok 4.20, Qwen, or Llama takes to generate

Most teams jump straight to bucket 3.

A lot of pain is in buckets 1 and 2.

n8n made this obvious

If you're running n8n in queue mode, the request path is not just “webhook in, model out.”

The main instance receives the webhook.
It creates an execution.
It pushes work to Redis.
Then a worker pulls the job and loads workflow data from the database.

Typical config:

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=<redis-host>
QUEUE_BULL_REDIS_PORT=6379

That architecture is good. It's how you scale n8n.

But it also means your “slow AI workflow” may be spending time in orchestration before GPT-5 or Claude is even called.

So if a user says your agent feels dead for the first second, don't assume the model is the villain.

Sometimes Redis, worker availability, or execution handoff is the villain.

Make has the same trap

I hit the same pattern in Make.

Two scenarios can run the same business logic and feel completely different:

• instant webhook: executes immediately, usually in parallel
• scheduled webhook: stores requests in a queue and processes later

Same automation.
Different latency profile.

If you're testing and thinking, “Claude feels slower today,” there's a decent chance Claude is innocent and your orchestration mode changed the user experience.

This comes up constantly in background AI processes.

People blame prompts and models first because those are visible.
The workflow engine quietly eats the first second or two.

Cold starts are still a real problem

Then there was the serverless layer.

If your worker is asleep when the webhook arrives, you pay startup tax before any useful work happens.

Google Cloud Run

On Google Cloud Run, scale-from-zero is great for cost efficiency and bad for first-request feel.

If you care about responsiveness, set minimum instances.

gcloud run services update SERVICE --min-instances=3

That one change is often worth more than another round of prompt cleanup.

If your endpoint needs to feel alive, warm instances matter.

AWS Lambda

On AWS Lambda, same story, different knobs:

• Provisioned Concurrency
• SnapStart

If your traffic is bursty and user-facing, cold starts can dominate perceived latency.

I would rather pay for warm capacity than keep pretending scale-from-zero is free.

Not always.
But often.

The fastest ingress I used was Cloudflare Workers

The biggest surprise for me was Cloudflare Workers.

Not for heavy agent execution.
For the front door.

Cloudflare Workers use isolates, not the usual container-or-VM startup model. That's exactly why they feel snappy for webhook ingress.

What worked well:

• accept request at the edge
• validate it
• write a job to a queue or backend
• return immediately
• let slower work happen elsewhere

That split changed perceived speed more than prompt rewriting did.

I would not run every heavy agent task inside a Worker.

I absolutely would use Workers to make the first interaction feel instant.

What I'd actually pick

Option	What it's good at
AWS Lambda Provisioned Concurrency	Keeps execution environments initialized for low startup latency; good when you're already on AWS and care about strict latency SLOs
Google Cloud Run Min Instances	Keeps containers warm to reduce scale-from-zero delays; great for HTTP agent backends and webhook handlers
Cloudflare Workers	Very fast webhook ingress and lightweight edge logic; ideal for immediate acknowledgment before handing work to slower systems

If I had to pick winners:

• Cloudflare Workers win for fast ingress and immediate acknowledgment
• Cloud Run min instances win for normal container ergonomics with better first-request latency
• Lambda Provisioned Concurrency wins when AWS is already home and latency matters enough to pay for it

The playbook I use now

This is the practical version.

1. Acknowledge first, think second

If a user or another system is waiting on a webhook, return something fast.

In n8n, a clean pattern is to use the Respond to Webhook node early so the HTTP response is decoupled from the full agent run.

That changes the experience immediately.

Request accepted now.
Heavy reasoning later.

2. Prewarm anything container-shaped

If you're on Cloud Run:

gcloud run services update SERVICE --min-instances=3

If you're on Lambda:

• enable Provisioned Concurrency
• evaluate SnapStart where supported

If you're on your own VM:

• keep workers hot
• stop restarting the world per request

3. Trim startup dependencies before touching prompts

A lot of cold start pain is self-inflicted.

If your worker starts by importing half your stack before doing useful work, that's part of the latency budget.

Things worth checking:

• large SDK imports
• database clients initialized too early
• observability setup on request path
• loading model metadata or configs on every request
• Python or Node modules that can be lazy-loaded instead

Example pattern in Node:

let client;

async function getClient() {
  if (!client) {
    const { SomeHeavyClient } = await import('./heavy-client.js');
    client = new SomeHeavyClient();
  }
  return client;
}

export async function handler(req, res) {
  const c = await getClient();
  const result = await c.run(req.body);
  res.json(result);
}

Lazy-loading won't fix everything, but it's often a better first move than shaving 200 prompt tokens.

4. Log the boundaries, not just total duration

Don't stop at:

request took 4.2s

That number is almost useless for debugging.

Log each stage:

• webhook received timestamp
• queue publish timestamp
• worker start timestamp
• model request start timestamp
• first token timestamp
• final response timestamp

Example shape:

{
  "request_id": "req_123",
  "webhook_received_at": "2026-09-12T10:00:00.100Z",
  "queue_published_at": "2026-09-12T10:00:00.180Z",
  "worker_started_at": "2026-09-12T10:00:01.020Z",
  "model_request_started_at": "2026-09-12T10:00:01.250Z",
  "first_token_at": "2026-09-12T10:00:02.000Z",
  "response_completed_at": "2026-09-12T10:00:03.900Z"
}

Now you can actually see whether your problem is:

• queue delay
• cold start
• provider latency
• long output generation

Without that, you're guessing.

5. Only optimize prompts when prompts are the bottleneck

Prompt optimization still matters.

If your agent writes long structured output, model generation time can absolutely dominate.

That's where output control helps:

• ask for shorter answers
• reduce unnecessary verbosity
• tighten schemas
• avoid giant markdown reports unless users really need them

Example:

Bad for latency:
"Write a comprehensive step-by-step analysis with detailed explanations for every decision."

Better for latency:
"Return the top 3 likely causes and the next best action for each in under 150 words total."

That can make a real difference.

But don't confuse that with fixing a sleeping worker or a queued webhook.

Cold starts are not always the bottleneck

Worth saying clearly: cold starts are not the answer to every latency problem.

If you're asking GPT-5, Claude Opus 4.6, or Grok 4.20 for a long structured response, token generation may still dominate.

And prewarming costs money.

• Cloud Run minimum instances are billed
• Lambda Provisioned Concurrency costs extra
• warm capacity is useful, not magical

You should make that trade consciously.

Still, I'd rather pay for warm capacity on the workflows that matter than spend another week rewriting prompts for a 3% gain while queueing and startup steal the first second.

Where Standard Compute fits into this

Once I fixed startup and orchestration issues, another problem became more obvious: I was still thinking too hard about per-call model cost.

That's a bad habit when you're building agents.

If you're tuning workflows across GPT-5.4, Claude Opus 4.6, and Grok 4.20, the last thing you want is to hesitate every time an automation gets chatty or runs 24/7.

That's why I like what Standard Compute is doing.

It's a drop-in OpenAI-compatible API with flat monthly pricing instead of per-token billing. You can plug it into existing SDKs and agent workflows, and it uses dynamic routing across major models.

For teams running automations in n8n, Make, Zapier, OpenClaw, or custom backends, that changes the optimization mindset:

• fix real latency first
• stop obsessing over token anxiety
• let agents run continuously without surprise bills

If your current setup has you balancing cold starts, queue delays, and token costs at the same time, predictable pricing is one less thing to fight.

The main lesson

The fastest workflows don't always think faster.

They start faster.

So before you spend another afternoon rewriting prompts, check:

• is the webhook being queued?
• is the worker cold?
• is the container scaling from zero?
• are imports and startup code eating the first second?
• are you measuring first-token time separately from trigger time?

Because a lot of “AI latency” isn't model latency at all.

It's infrastructure latency wearing an LLM costume.