Why Your AI Feels Slow: The “Baggage Claim” Theory of Latency
When Houston Airport first opened, executives faced a big problem. Passengers were upset about how long they had to wait for their bags…
Why Your AI Feels Slow: The “Baggage Claim” Theory of Latency
Dulles not Houston 😊
When Houston Airport first opened, executives faced a big problem. Passengers were upset about how long they had to wait for their bags, and complaints kept coming in.
To fix this, the airport brought in operations researchers. They improved the baggage handlers’ routes, adjusted the conveyor belt speeds, and invested in better logistics. Soon, the wait time dropped to eight minutes.
But even after these changes, people still complained.
The executives were confused. They had fixed the technical issue, but passengers were still unhappy. So they tried something unexpected: instead of speeding up the bags, they moved the arrival gates farther from baggage claim.
Now, passengers had to walk much farther to reach the carousel. By the time they got there, their bags were waiting for them.
The “wait” dropped to zero. The complaints vanished.
The total time from “plane wheels down” to “bag in hand” hadn’t changed a second. But the perception of that speed had changed entirely.
The Psychology of the “Spinning Wheel”
This brings us to the single biggest hurdle in User Experience today: Latency.
When you ask an AI a tough question, the model needs time to process it. In Large Language Models (LLMs), this is called the “Time to First Token” (TTFT). For a big model working through a hard prompt, that pause can last 3, 5, or even 10 seconds.
In web design, waiting 10 seconds feels like forever. It’s what we call a “dead” interaction.
If you saw a spinning loading icon for 10 seconds, you’d probably think the app was broken. You might refresh the page, close the tab, or blame your Wi-Fi.
But if the answer starts appearing right away, word by word, you’ll likely watch for 30 seconds without complaining.
Why?
The Law of Occupied Time
There is a fundamental rule in the psychology of service, coined by David Maister: Occupied time feels shorter than unoccupied time.
When you are watching a spinner, you are in “unoccupied time.” You are waiting for something. Your brain is hyper-aware of every second passing.
When you read text as it appears on the screen, you’re occupied. You’re taking in information and processing it. The wait is over, and the experience has started.
That’s why “showing your thinking”, the typewriter effect we see, is more than a technical feature. It’s a psychological trick.
- The Loading Spinner: “The system is thinking.” (Passive, anxious wait).
- The Stream: “The system is speaking.” (Active, engaged consumption).
In a way, we’re making you walk to baggage claim so you don’t notice how long unloading the plane takes.
The Technical Reality: The “Generator” Effect
Now, let’s see how this “stream” of thought works in practice.
With traditional REST APIs, which are how websites usually talk to servers, communication is like sending a letter. You send a request, the server does all the work, writes a full response, and sends it back. You don’t get anything until the whole job is finished.
To show our thinking, we need a different approach: Server-Sent Events (SSE).
Think of SSE like a phone call where the other person speaks slowly, instead of a letter.
The Implementation
Instead of waiting for the AI to finish the whole essay, we tell the server, “Don’t wait until you’re done. As soon as you have a word or token, send it to me right away.”
Here is what that looks like in a simplified Python implementation:
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import time
app = FastAPI()
# A fake generator that mimics an AI "thinking"
def fake_ai_brain():
response = "The... concept... of... speed... is... relative."
tokens = response.split(" ")
for token in tokens:
\# Simulate the "thinking" time for each word
time.sleep(0.3)
\# YIELD the data immediately, don't return it!
yield f"data: {token} \\n\\n"
@app.get("/stream-chat")
async def stream_chat():
# We return a StreamingResponse, not a standard JSON
return StreamingResponse(fake_ai_brain(), media_type="text/event-stream")
The magic word here is yield.
In standard coding, a function returns data when it’s finished. Yield is different. It hands over a piece of data right now, but keeps the function alive so it can keep working.
- The User asks a question.
- The Server accepts it and keeps the connection open.
- The AI generates Token #1. The server
yieldsit to the browser immediately. - The Browser displays Token #1. The user reads “The…”
It might take 3 seconds to generate the full sentence, but the user feels like it’s working after just 300 milliseconds.
Conclusion: Design Time, Not Just Software
As we build apps that interact with machines, we need to remember our users are people, not computers. Their sense of time is shaped by feelings, not by digital clocks.
We can’t always make the AI think faster. Sometimes, the math just takes time. But by understanding the perception of speed, by keeping the user occupied with the process rather than the result, we can make the slow feel instantaneous.
We aren’t just engineers optimizing for latency. We are architects of the user’s patience. As a practical challenge, consider auditing your own products for instances of unoccupied time. Identify areas where users are left waiting, and brainstorm creative ways to transform those moments into more engaging experiences. This proactive approach will not only enhance user satisfaction but also inspire immediate action to improve your product's user experience.
By Joshua McDonald on January 17, 2026.
Exported from Medium on August 26, 2026.
Reader discussion