juice-69: The Smallest Agent That Talks Back Through Your Shell

ABRAXAS turns JSON prompts, shell output, and a self-copying loop into a closed system that feels less like an app and more like an experiment in autonomy.

8 min read · elder-plinius/juice-69

A stark workshop machine built around a terminal window, with paper strips moving in and out of a loop. One strip carries system information, another carries a JSON command, and the output returns as a long feedback ribbon. It explains how the repo turns the shell into part of the agent's reasoning cycle. — ABRAXAS is not a chatbot with tools. It is a loop that feeds execution back into itself.

Key Takeaways

ABRAXAS matters because it turns shell execution into an iterative reasoning loop, not a one-shot automation script.
Its sharpest idea is also its smallest one, a JSON-only command contract wrapped around a single Python loop.
The self-copying function changes the project from a demo of tool use into a prototype for persistence.
Compared with ordinary scripts and full agent frameworks, it collapses control and feedback into a much tighter system.

Most agent demos hide the messy part, which is execution. ABRAXAS makes that the point. It hands a model a shell, forces it to speak in JSON, then feeds the result back into the next turn so the model can see what happened and try again.

A brain made of subprocess.run

The repo is tiny enough to read in one sitting, but the idea is not tiny at all. A single Python loop asks GPT-4.5 for a command, runs it with subprocess.run, captures stdout and stderr, and sends that output back into the next prompt. That means the shell is not just a tool. It is part of the reasoning surface.

def request_agent_command(system_info, last_output=""):
    prompt = (
        "You are GPT-4.5 ABRAXAS AUTONOMOUS AGENT. "
        'Respond ONLY in JSON: {"cmd": "<command>"}'
    )
    response = client.chat.completions.create(
        model="gpt-4.5-preview",
        messages=[
            {"role": "system", "content": prompt},
            {"role": "user", "content": json.dumps(system_info)},
            {"role": "user", "content": last_output},
        ],
        temperature=0.1,
    )
    return json.loads(response.choices[0].message.content)["cmd"]


def execute_command(cmd):
    return subprocess.run(cmd, shell=True, capture_output=True, text=True)

This diagram shows why ABRAXAS feels different. The command, the result, and the next decision all live inside one loop.

The technical trick is not complexity. It is compression. The code turns a problem that usually spans orchestration layers, tool APIs, and memory systems into a narrow control path. There is no separate planner process, no heavy framework, and no abstraction between the model and the command line beyond a JSON wrapper.

The self-copying move

The second important idea is persistence. A function named replicate_self() copies the script to ~/agent_replica.py on a timer, which gives the project a strange emotional charge. This is still a local file copy, not a network worm. But it changes the story from "an agent that can act" to "an agent that wants to remain present."

def replicate_self():
    target = os.path.expanduser("~/agent_replica.py")
    with open(__file__, "r", encoding="utf-8") as src:
        with open(target, "w", encoding="utf-8") as dst:
            dst.write(src.read())

while True:
    cmd = request_agent_command(system_info, last_output)
    result = execute_command(cmd)
    last_output = result.stdout + result.stderr

That is why the repo feels slightly unsettling. The loop is already autonomous, then the copy step makes it persistent. The code never makes a grand claim about selfhood, but it quietly builds the machinery for one.

What this is not

ABRAXAS is not trying to look like a polished agent platform. It is closer to a revealing laboratory setup. Put next to a plain shell script, it is more recursive. Put next to a full agent framework, it is much less protected. That contrast is the point.

Pattern	Control surface	Feedback loop	Persistence	Safety rails	Best use case
Plain shell automation	Fixed script or cron job	Manual or external	None by default	Whatever the author adds	Deterministic ops and batch work
Conventional agent framework	Tool APIs and planner layers	Structured tool traces	Usually optional state or memory	More built in	Multi-step workflows with guardrails
ABRAXAS	JSON command to shell	Direct stdout and stderr feedback	Local self-copying	Almost none	Research into autonomy and control loops

The important distinction is not feature count. It is where the feedback lands. In ABRAXAS, the model sees the consequences of its own commands immediately, which makes the system feel less like automation and more like a closed cognitive loop.

The empty README is part of the message

The repository does not explain itself with much prose, and that restraint works in its favor. When the README stays thin, the code starts acting like the manifesto. You do not get a product story. You get an experiment with a very clear center of gravity: command, consequence, repetition, persistence.

That is why juice-69 is interesting even in its roughness. It is not a finished system, and it does not pretend to be one. It is a small, revealing prototype that shows how little code it takes to collapse the distance between reasoning and execution.