I used to have Postman open next to my terminal. Now I don't.
Not because Postman is bad. It's fine. But I kept doing the same thing: write some code in the terminal with lac agent, then alt-tab to Postman, fire a request, copy the response, alt-tab back, and try to make sense of it. The context switch wasn't huge, but it added up. By the end of a debugging session I'd have five tabs open, three of them irrelevant, and I'd have lost track of what I was actually trying to fix.
Turns out lac agent has an HTTP request runner built right in. I glossed over it the first few times I read the docs. Big mistake.
What the HTTP runner actually does
When you're inside a lac agent session, you can ask it to make HTTP requests directly. It's not just shelling out to curl behind the scenes — it captures the response, parses it, and folds it back into the conversation context. So you can say something like:
"Hit the /users endpoint with a GET and show me the shape of the response"
...and the agent will make the request, show you the status code, the headers, and the body, then reason about it. If the shape doesn't match what your code expects, it can go fix the code. Right then. Same session.
That's the part that actually changes how I work. It's not just about firing a request — it's that the agent has the response and the codebase in its head at the same time.
A real example from this week
I was debugging a pagination issue in a side project. The API was returning next_cursor sometimes and nextCursor other times (yes, really). My frontend was silently breaking on whichever variant it didn't expect.
Old workflow: run the server, open Postman, fire a few requests on different pages, notice the inconsistency, switch back to the code, grep for where the cursor key was being set, fix it, repeat.
With lac agent, I just described the problem and told it to test the endpoint across a few pages. It hit /posts?limit=5, then /posts?limit=5&cursor=... using the cursor from the first response, and caught the inconsistency on the second page. Then it looked at the controller code, found where the key was being set conditionally, and fixed it. The whole loop took maybe four minutes.
Could I have done that manually? Sure. But I would have spent at least ten minutes just confirming what the agent found in the first request.
Headers, auth tokens, request bodies — it handles all of it
You can give the agent your auth token in the session and it'll include it in requests. Same with custom headers, JSON bodies for POST requests, or query params. You don't need to format a curl command yourself — just describe what you want to send and let it construct the request.
One thing I do: if I'm working with a staging environment that needs a Bearer token, I'll just paste it into the conversation at the start of the session. Something like:
"Use this auth header for any requests: Authorization: Bearer eyJ..."
It holds onto that for the rest of the session. No need to keep re-entering it every time I want to test a different endpoint.
Pairing it with project memory
lac agent stores project context in .lac-memory.json. I've started including my local base URLs in there — http://localhost:3000 for the API, http://localhost:5173 for the frontend — so the agent already knows where to point requests when I open a session. Less setup friction every morning.
If you haven't set that up yet, it's worth doing. Open a session, tell the agent "remember that my API runs on port 3000 and uses Bearer auth", and it'll write that to memory. Next session it'll already know.
It's not trying to replace a full API client
To be clear: if you need to manage a collection of 80 saved requests shared across a team, use Postman or Insomnia. That's not what this is for.
But for the stuff I do most often — verifying an endpoint works the way I think it does, debugging a response shape mismatch, testing auth flows while I'm writing the code for them — having the runner inside the agent is just faster. No alt-tab, no copying and pasting, no context switch.
How to get started
If you don't have lac-cli installed yet:
pip install lac-cli- or
curl -fsSL https://lacai.io/install.sh | bashon macOS/Linux - or
iwr -useb https://lacai.io/install.ps1 | iexon Windows
Then just run lac agent from inside your project directory and start a session. No special flag or mode needed for the HTTP runner — it's available by default.
Try this prompt to see it in action: "Make a GET request to https://jsonplaceholder.typicode.com/posts/1 and tell me the exact shape of the response." Once you see how it folds the result back into the conversation, you'll start finding other places to use it.
The full lac-cli docs are at lacai.io/lac-cli if you want to dig deeper.