Last week I caught myself doing the same loop for the fourth time in an hour: write a handler in the editor, alt-tab to the browser, wait for the Postman tab to focus, re-send the request I ran ten minutes ago, read the response, alt-tab back, forget what I was about to type, re-read the last three lines of my own diff.

The request itself took 180 milliseconds. The round trip out of the editor and back took closer to ninety seconds of my attention. The bill wasn't the network. It was the context I had to rebuild after leaving.

The load time is the smallest part

People argue about API clients by comparing features: which one has better mock servers, which one generates types from OpenAPI, which team's sync works offline. I don't buy that the differentiator is feature count. Most teams have already settled on a client that covers the basics. The thing nobody prices is the switching cost.

When you alt-tab to a web client, three things happen at once. You leave the file you were editing. You lose the selection you had active. You give the browser a chance to slide in something else — a notification, a reload prompt, a tab that auto-played a video — before you land back on the request you meant to send.

By the time the response comes back, you're not in the middle of writing code anymore. You're in the middle of debugging a request. Those are two different mental states, and the compiler doesn't care which one you're in.

AI agents make the tax worse

The cost used to be annoying. With AI agents in the loop it becomes a correctness problem.

Picture this: your agent just finished a handler. You want to verify it. You switch to the web client, send the request, see a 500, switch back to tell the agent the fix, switch again to re-test. Every switch is a chance to forget what the agent actually wrote, what the error was, which variable you had on your mind when you asked it to change that line.

Worse: the agent doesn't see the response. It only sees your second-hand description. You type "it returns 500" and it guesses at the cause. It never sees the body, never sees the headers, never gets to correct itself. You are the API client now, and you are a slow one.

What I changed

I moved the API testing into something that lives next to the editor. The request definition stays in a local file. The response shows up in a pane I don't have to switch applications to see. The agent can read the same spec I'm looking at, and when it claims the endpoint works, I can re-run it from the same window where I'm writing the code, without alt-tabbing out of the process.

The details matter less than the principle: the tool shouldn't ask you to leave the context you're already in. A web client that lives in a separate browser tab is, by design, a place you have to travel to.

This is the problem I keep circling back to, which is why I built Powerduck — a local-first OpenAPI studio that sits next to the editor instead of in a browser tab. The spec stays the source of truth, the request runs locally, and I don't have to rebuild my train of thought every time I want to check a response.

Try this tomorrow morning

Before you reach for the browser, time one round trip: write a handler, switch to your API client, send the request, switch back. Stop the clock when you've actually resumed typing. If it's more than five seconds, you're paying a tab tax you can't see on the invoice.

The fix isn't a better client. It's a shorter distance between the code and the call.