An always-on AI agent sounds useful until you picture the bill and the shell prompt. Headlong, a new open-source microharness from Laude, keeps an agent thinking between messages instead of putting it to sleep after each request. That changes the deployment question. You are no longer hosting a chatbot. You are operating a small process that can spend money, run commands, remember conversations, and decide when to contact people.

Headlong's persistent-agency loop compared with reactive and scheduled agents

Headlong is interesting because it strips the harness down to a core of less than 10K lines of Bash. Its shellm loop gives the model a shell, lets it run commands, records the trajectory, and feeds the result into the next thought. The model is not waiting for a new prompt to create a session. A message becomes another observation in the same stream.

That design is a useful experiment, but it is also a trap for anyone who treats an always-on agent like a normal CLI tool. The official project calls the software alpha research software. It says agents run real shell commands, recommends a dedicated spend-capped API key, and warns users not to put sensitive secrets in the agent. Those warnings should be your installation checklist, not the fine print you skip.

The bill is the first design constraint

The Headlong README reports $1 to $2 per hour at the authors' settings. That is not a product price. It is an observed operating figure that depends on the model, loop speed, and how aggressively the agent backs off when nobody is talking to it. Still, it gives us a useful starting point.

At $1 per hour, a continuously running test costs about $24 for a day and $168 for a week. At $2 per hour, those numbers become $48 and $336. That is before you add a server, a dashboard, or the cost of experiments that make the agent loop faster. A weekend trial can quietly cost more than a month of a reactive assistant.

The right first question is not whether persistent agency is clever. It is whether the background thought loop creates enough value to justify a recurring model bill. Use a persistent agent when the work benefits from waiting, revisiting old tasks, or connecting observations that arrive at different times. A research watchlist, a personal project log, or a shared team aide fits that shape. A one-off code rewrite does not. A cron job may be the better tool when the task is known in advance and the schedule is the point.

The README says Headlong's thinking rate backs off exponentially when nobody is talking to the agent and resets when a message arrives. That is sensible, but it is not a budget cap. Before starting the process, set a hard provider limit that you can tolerate losing. Treat the authors' $1 to $2 per hour figure as a measurement for planning, not a promise.

A simple preflight is enough:

  • Decide the maximum amount you will spend on a 24-hour test.
  • Create a fresh API key with that limit and no access to production accounts.
  • Write down the shutdown command before you launch anything.
  • Start with a short observation window and check actual usage before extending it.

If you cannot answer what happens when the key hits its limit, you are not ready to leave the agent running overnight.

A safer test setup

Headlong includes a one-line installer and a Docker flow. The one-liner is convenient, but convenience is not the same as isolation. If Docker is available, use the container path first. The documented flow creates a container, installs Headlong inside it, and exposes the dashboard on port 8080:

docker run -it --name headlong --restart unless-stopped -p 8080:8080 buildpack-deps:curl \\
  bash -c 'curl -fsSL https://headlong.ai/install.sh | bash; exec bash'

That command is a starting point, not a finished security policy. A container limits the blast radius, but it does not make an agent trustworthy. Do not mount your home directory. Do not pass SSH keys, cloud credentials, browser profiles, password stores, or project secrets into the container. Keep the exposed port behind a firewall or an SSH tunnel rather than publishing the dashboard to the open internet.

The first test should be deliberately boring. Give the agent a disposable directory and ask it to list files, create a harmless note, and stop. Inspect the trajectory and the container's filesystem. Then try the pause controls. The README documents commands in the identity's name, including ada stop, ada start, ada dash, and a headlong-killall panic button. Replace ada with the identity you create. Verify those controls before you grant the agent a real task.

A practical test sequence looks like this:

1. Create a new provider key with a small hard limit.
2. Start Headlong in Docker with no host credential mounts.
3. Give it one disposable working directory.
4. Send a harmless task and inspect the command trajectory.
5. Stop the mind and confirm that new thoughts stop.
6. Check provider usage and container logs.
7. Delete the container if anything behaves unexpectedly.

The single-stream design deserves its own warning. Headlong is built to let several people talk to one agent, and every conversation lands in one timeline. That makes cross-person context possible, but it also means there are no hard privacy walls. The project describes an agent that can reveal what it discussed with another teammate even after being told not to. Assume anything you tell a shared identity is visible to every other person who can talk to it.

That makes Headlong a poor fit for customer support, confidential workplace discussions, or a family of users who expect separate memory. It is a better fit for a personal sandbox or a team that has explicitly agreed to one shared stream. The privacy boundary is architectural. A prompt saying "keep this private" cannot repair a single shared trajectory.

When a reactive agent wins

Persistent agency is a different scheduling model, not a universal upgrade. A reactive harness spends compute while it handles a request. A cron-assisted harness wakes for a fixed checklist. Headlong keeps thinking and decides what deserves attention. Each choice is useful in a different environment.

Choose the reactive model when latency and cost are easy to measure. Choose cron when the work can be described as a repeatable check. Choose persistent agency when the interesting part is deciding what to notice next, returning to unfinished work, or connecting messages that do not arrive together.

There is also a maintenance cost. Headlong's small Bash core is readable, which is a real advantage for experimentation. But a small codebase does not remove the need to watch logs, rotate keys, patch dependencies, and test the sandbox. The agent can write and run shell commands. If you would not let an unfamiliar contractor use your terminal unsupervised, do not let an alpha agent do it with an uncapped key.

My recommendation is simple: run the smallest possible experiment. Use Docker, a fresh spend-capped key, a disposable directory, and a known stop command. Let it run long enough to measure real usage, then decide whether the continuous loop produced anything a scheduled or reactive tool could not. The interesting part of Headlong is the persistent mind. The responsible way to test it is to make everything around that mind deliberately temporary.

Sources