The parts of lac agent most people skip
When I first started using lac agent, I treated it as a coding assistant. Read files, write files, fix bugs. That's the obvious use case and it works well. But after a few weeks of daily use I kept bumping into two other things baked into the same tool — an HTTP request runner and a task tracker — and I started using both of them constantly.
Neither of these features gets much attention. They're not in the headline pitch. But if you spend a lot of time in the terminal, they close a gap that used to send me bouncing between windows constantly.
The HTTP request runner
Before this, my workflow for testing an API endpoint mid-session was: stop what I'm doing, switch to Postman or Insomnia, reconstruct the request, look at the result, switch back. That context switch is small individually and annoying in aggregate.
lac agent has a built-in HTTP request runner. You can describe a request in plain English and it fires it, or you can be explicit about the method, URL, headers, and body. The agent runs the request and surfaces the response right there in the session.
Here's what that looks like in practice. Say I'm working on a backend and I want to test the auth endpoint I just wired up:
lac agent
> send a POST to http://localhost:3000/auth/login with body {"email": "test@test.com", "password": "hunter2"} and header Content-Type application/jsonThe agent fires the request, shows me the response status, headers, and body. If something is wrong with the response, I can immediately ask it to look at the relevant route file and fix it — all without leaving the session. The feedback loop gets tight in a way that Postman just doesn't give you when you're already deep in a coding session.
It's particularly useful when I'm working with an API that has chained requests — like needing to hit a login endpoint first to get a token and then use that token on a protected route. The agent holds the token in context and reuses it. I don't have to manually copy and paste anything between requests.
It also works against external APIs. If I'm integrating a third-party service and I want to sanity-check what their endpoint actually returns before I write the integration code, I just ask the agent to hit it. The response is right there, I can ask follow-up questions about the shape of the data, and then start writing the integration with full context already in the session.
Task tracking inside the session
The task tracker is the other one. When lac agent is working through something non-trivial — say, refactoring a module or adding a feature that touches several files — it maintains a live task list for that session. You can see what it's done, what it's doing, and what's left.
This matters more than it sounds. When an agent is making changes across five or six files, it's easy to lose track of where things stand. Did it finish the middleware update? Did it actually write the test it said it would write? The task list answers those questions without me having to scroll back through the output and piece it together.
You can also add tasks manually. If I think of something mid-session that I don't want to forget, I just tell the agent to track it:
> add a task: write migration script for the new users tableIt goes into the list. When I circle back and ask it to continue, it picks up the pending tasks. Combined with the project memory in .lac-memory.json, this means context genuinely carries across sessions. I can close the terminal, come back tomorrow, and the agent knows what was in progress.
The task tracker also helps when something goes sideways. If the agent makes a change I don't like and I use undo to roll it back, the task for that step goes back to pending. It doesn't silently disappear from the list like it never happened. I can see exactly what was rolled back and decide whether to retry it with different instructions or skip it.
Why these two features belong together
HTTP testing and task tracking feel unrelated until you use them together on a real feature. The pattern I fall into is roughly: plan the work (task list fills in), write the code (agent edits files), test the endpoint (HTTP runner fires the request), review the result, move to the next task. All inside one lac agent session.
Compared to the old way — text editor open, terminal open, Postman open, some kind of note-taking thing open — this is just fewer things to manage. The terminal becomes the actual workspace instead of just the place where I run git commands.
Getting started with both
If you haven't installed lac-cli yet, it's a one-liner:
pip install lac-cliOr grab it via the install script from the lac-cli page. Once you're in, just run lac agent and start a session. You don't need to enable anything special for the HTTP runner or task tracker — they're available by default.
One practical tip: if you're working against a local server, start the server in a separate terminal tab and leave lac agent running in its own tab. That way the agent can fire requests without interfering with the server process, and you'll see any server logs in real time in the other tab. Small thing, but it makes the loop noticeably smoother.
Try this on your next feature: open a session, describe the task, let the agent build out the task list, and once the code is written, ask it to hit the endpoint and tell you what comes back. That single loop will probably be enough to make it a default part of how you work.