Prime Agent

Prime Agent: #1 on GitHub — The Free Claude Code Alternative That Learns From Every Session

🎬 Signal Coders 📅 Aug 7, 2026 ⏱ 21:24
Prime Agent open-source coding agent self-improving Python MIT

🧬 What It Is — MIT, Free, Swappable Model

Signal Coders opens with the hook: the most-starred repository on GitHub today is a coding agent that edits its own instructions — not the model's weights, but the harness around it. After a session, it reviews what happened, extracts a lesson, and writes it into durable state that carries forward. "If your first reaction is that this sounds like a genuinely bad idea, you have good instincts." The video is a deep investigation of what they built to stop it going wrong. 0:00

Prime Agent is an open-source coding and research agent, MIT licensed for macOS and Linux. Installed with one command — and the installer verifies a checksum on what it downloads ("small thing, most don't bother"). The copyright tells a story: "2025 an individual developer, then 2026 the company" — it started as one person's project and was adopted by an organization, with upstream attribution preserved. 2:02

The honest definition of "free": the harness is free (MIT, forkable, no account required). The model is not included. On first launch, you run a login command and choose a provider — Claude paid tiers, ChatGPT, GitHub Copilot, or direct API key. "This is a free open-source harness that runs on a model subscription you probably already have. You are not buying another subscription. You're pointing an existing one at better tooling that you own." 2:37

➖ The Subtraction: One Tool

The design decision that defines everything else — and it's a removal. Most coding agents give the model 10–20 named tools (read, write, edit, search, shell, fetch). Prime Agent gives the model one tool: IPython — a persistent Python session that stays alive across the entire conversation. Everything happens inside it. 3:31

Reading a file is Python. Editing is Python. Running tests is a Python cell that shells out. Spawning a sub-agent is a Python function call. "The model doesn't select from a menu of capabilities. It writes code." Why is this better? Three compounding reasons: 4:32

  1. State persists across turns and compaction. In a normal agent, each tool call is isolated. Here, the model assigns a search result to a variable and that variable is still there 20 turns later. "The conversation can be forgotten while the working data survives — a real separation of concerns."
  2. Composition is free. "Find every config file over 10 KB" is a sequence of tool calls in a toolbox agent; here, it's a Python loop. The model has a programming language, not a menu.
  3. The tool surface stops growing. Every new capability in a normal agent is another tool description in the system prompt. Here, it's a new Python package. "The model's decision space stays constant while its actual power grows."

📨 Sub-Agents That Never Answer You

The second design decision "looks like a bug until it clicks." The model can spawn child agents from inside the Python session. The call looks ordinary — you name a task, you get something back — but what you get back is not the answer. "The call returns an admission with a child handle and never returns the child's answer. Read that again. You asked for a code review, you got a receipt." 5:50

Results arrive asynchronously: the child sends them as a message when it has something worth sending, or writes files. The parent's turn can end — the child keeps working. Fire and forget. Three children work at once while the parent moves on. Their documentation shows the pattern: spawn a security review, a test coverage review, and an integration audit in three consecutive lines, then end the turn. 6:36

The plumbing is serious: children inherit the parent's model, provider, tools, skills, and scheduling. The child registry survives compaction and kernel restart. Recursion depth is configurable — children can have children. "Agents can message each other directly without routing through you. This is where it stops resembling a tool and starts resembling an organization." 7:15

🧠 The Self-Improvement System — and the Boundary That Makes It Sane

The headline feature: the continual harness. It stores supplemental prompts, memories, skill descriptions, and reusable sub-agent specs as durable state that outlives the session. A command reviews the trajectory of what just happened and applies small edits — "evidence-backed, lessons drawn from what actually occurred." The agent that struggled with your build system on Monday carries a note about it into Tuesday. 7:52

But the real engineering is in the guardrails. Signal Coders found the answer in one sentence from the runtime docs: 8:39

"Rollback uses recorded before and after snapshots. The base system prompt remains immutable. Refinements are supplemental state." — That's the boundary, and Signal Coders argues it's exactly the right one. There is a floor that cannot be edited. Everything the agent learns sits on top of a fixed foundation. The failure mode everyone fears — an agent gradually rewriting its own constraints — is structurally prevented, not merely discouraged. It cannot reach that file.

Every change is snapshotted and reversible. State lives in files on your disk you can read. "You can read what your agent has decided it believes about your project, and I'd suggest occasionally doing exactly that." There's a second boundary: the refinement system can update notes; it cannot package new executable functionality — that requires a separate deliberate step through the skill creator. "Learning happens in the middle, in files you can read, with an undo button." 9:33

The three questions to measure any self-improving agent against: ① What can't it edit? ② Can you undo it? ③ Can you read what it learned? "If a product can't answer all three, it isn't self-improving. It's just changing." 10:34

🎛️ Autonomy: Four Budgets & Quality Gates

Autonomous mode keeps the agent going without you. It starts disabled — you opt in explicitly. When enabled, four independent budgets apply simultaneously with conservative defaults: 11:00

BudgetDefaultDetail
Continuation prods3How many times the system may prod the agent to continue
Assistant turns12Cap on assistant message turns
Token budget80,000Counts input, output, cache writes; excludes cache reads — "a precise accounting decision, disclosed. Nobody discloses that."
Wall clock30 minHard time limit

Then there are quality gates: shell commands that must pass before the run is allowed to finish — your test suite, linter, build. A failed gate feeds its output back so the agent can repair. The system avoids rerunning an unchanged failed gate. A passing gate lets the run finish even if a budget was exhausted — "verified success outranks resource limits." 11:46

The most honest sentence in agent documentation this year: "A passed gate checks only what that gate verifies. Reaching a limit does not imply task success." Your test going green means your test went green — not that the work is correct. When the agent stops because it ran out of turns, that's exhaustion, not completion. "Every incentive pointed the other way. The marketing version is 'set it going and come back to finished work.' They wrote down that stopping is not the same as finishing." 12:19

🛡️ Security Posture — Honest to a Fault

Given arbitrary code execution as the primary interface, self-spawning sub-agents, and unattended autonomous runs, the obvious question is what protects your machine. The answer is "refreshingly blunt": 13:25

"Prime Agent executes model-generated Python and project commands with your user permissions. Its worker and kernel processes improve lifecycle isolation and recovery. They are not a security sandbox. They are not a security sandbox." — A company shipping an autonomous coding agent, writing in their own getting-started docs that their isolation is for reliability, not security. "Most projects imply safety through vagueness. This one tells you plainly: it runs as you. It can do what you can do. The fences are for crashes rather than attackers." 13:56

Their quick start tells you to point it at a disposable clone or clean work tree. Skills documentation: "Review skill content before use." Signal Coders: "Take their advice literally. Disposable clone, trusted skills only. Make your version control the safety net, because nothing else is." 14:30

📦 Skills: Portable & Python-Backed

Prime Agent implements the same open skill standard that engineers have been publishing their personal instruction folders in, reading from the same shared directory path other coding agents recognize. Your existing skills are portable. Then it extends the format: alongside Markdown skills, it supports Python-backed skills — a skill can install a Python package into the kernel, which the model calls as a function with named arguments. "Instructions can be misread. A function either runs or errors." 15:02

The pattern: "This project consistently adopts other people's standards and then extends them. Same skills format, same instruction files, same subscription providers. They compete on the runtime, not on lock-in. That's the behavior of a project that expects to win on engineering." 15:50

💼 Who's Paying?

"Standing rule: when something this substantial is free, find the invoice." The company behind Prime Agent builds reinforcement learning infrastructure, training tooling, and verification systems. Their docs say the agent is built for long-running work — "especially for evaluations and research." 16:08

The strategic logic: an agent that runs long autonomous tasks with quality gates is structurally an evaluation harness. Bounded autonomy, pass/fail gates, durable session records — the same things that make it useful to you make it useful for measuring model performance at scale. "Their business benefits from this existing and being good." Opt-in trace sharing is genuinely optional and off by default. "None of this is concerning. It's a company open-sourcing infrastructure that serves its own research needs — one of the healthiest reasons open source exists." 17:01

⚠️ Honest Limits

  1. Source-read, not battle-tested. "I read the source and documentation. I have not run this across weeks of real work. How it feels over a month is a different question."
  2. No published benchmarks — and that's fine. "This is a harness. A harness's quality shows up in your model's results, not in a leaderboard. Only your own tasks can tell you it's better."
  3. The code execution model IS the risk. "Everything good about the one-tool design comes from the model writing and running code with your permissions. That's the trade. Accept it deliberately or don't run it."
  4. Young and moving fast. Version numbers, defaults, and commands will drift. The four design ideas won't.

🎯 Who Should Run This

If you already pay for a coding subscription, "this is the easiest recommendation in the video — you're pointing a model you already have at a harness you own." If you run long or repetitive work, "this is the strongest fit: background sessions that survive closing your terminal, persistent goals, bounded autonomy with real gates." Python comfort yields the most value — the interface is Python. If you need a security boundary, run it in a container or VM. And if you just want the ideas: "one powerful tool instead of many narrow ones, delegation that doesn't block, learning above an immutable floor, autonomy bounded by multiple budgets plus verification gates — you can apply all four to whatever you already use." 18:06

✅ Key Takeaways

  1. The subtraction IS the architecture. One tool (IPython) instead of 10–20. The model writes code, not selects from a menu. State persists across turns and compaction. Composition is free. The tool surface stops growing while power increases.
  2. Sub-agents return a receipt, not an answer. Fire-and-forget delegation lets children work in parallel while the parent moves on. Results arrive as messages or files — never blocking. This stops resembling a tool and starts resembling an organization.
  3. Self-improvement with an immutable floor. The base system prompt cannot be edited. Learning writes to a supplemental layer on top. Every change is snapshotted and reversible, stored in readable files on disk. A hard rule: it can update notes, but cannot ship itself new code.
  4. Three questions to measure any self-improving agent: What can't it edit? Can you undo it? Can you read what it learned? If a product can't answer all three, it's not self-improving — it's just changing.
  5. Autonomous mode: four budgets + quality gates. Continuation prods (3), turns (12), tokens (80K), wall clock (30 min). Gates are your test suite/linter/build. A passing gate outranks exhausted budgets. "Verified success outranks resource limits."
  6. The most honest sentence in agent docs this year: "A passed gate checks only what that gate verifies. Reaching a limit does not imply task success." Green tests ≠ correct work. Exhaustion ≠ completion. They tell you not to read one as the other.
  7. "They are not a security sandbox." The isolation is for reliability, not security. It runs as you, with your permissions. Use disposable clones, trusted skills only, and version control as your safety net.
  8. Competes on runtime, not lock-in. Adopts shared skill standards, same AGENTS.md files, same subscription providers. Python-backed skills: functions that either run or error — not instructions that can be misread.
  9. Business model: RL infrastructure company. The agent is structurally an evaluation harness — useful to you and to model researchers. Opt-in trace sharing, genuinely optional, off by default.
  10. The shift: competition is moving from models to harnesses. For 2 years, coding agents competed on model quality. Models are getting less scarce. Memory, delegation, durability, and control are the new battleground. "This project is the clearest statement of that yet."

🔗 Resources & Links

📍 Timestamp Index

0:00 It edits its own instructions — why that should worry you
1:01 Four design decisions — the investigation begins
2:02 What it is — MIT, one-command install, checksum verified
2:37 "Free" means swappable model on your existing subscription
3:31 The Subtraction: one tool (IPython) — state, composition, constant surface
5:50 Sub-agents that never answer you — fire-and-forget delegation
7:52 The continual harness — learning that survives sessions
8:39 The boundary: immutable base prompt, supplemental learning, snapshots
10:34 The three questions — what can't it edit, can you undo, can you read
11:00 Autonomy: four budgets (3, 12, 80K, 30min) + quality gates
12:19 "A passed gate checks only what that gate verifies"
13:25 "They are not a security sandbox" — honest security posture
15:02 Skills: portable + Python-backed — competes on runtime, not lock-in
16:08 Who's paying? RL infrastructure company — healthy open-source incentive
18:06 Who should run this — existing subscribers, Python users, long-task runners
☰ View all