Agent · Available now

Persistent Agent

Stops your coding agent from calling a job done at the first plausible answer.

Persistent Agent runs one task through a coding agent and then refuses to let it stop. After the first answer comes back, it sends the task back with your original wording preserved exactly and asks the agent to keep going: look for what it missed, test what it claimed, and tighten what it rushed. You choose how hard it pushes with a strength tier from 1 to 6, which adds 6, 8, 20, 40, 70, or 100 further turns after the first one. Every turn resumes the same session, so the agent is continuing its own work rather than restarting with amnesia.

What you get back is the state of the work after the last pass, not after the first. The edits are real changes in your working tree, made along the way, rather than a plan describing changes someone still has to make. Progress lines go to one stream and only the final answer goes to another, so the result drops into a script without you parsing around the commentary. Because the same task at the same tier runs the same number of turns, a second run behaves like the first.

It does not choose between approaches and it does not break a job into pieces. It takes the one task you wrote and pushes that task all the way to done, which is why the wording of the task matters more here than anywhere else. The run is a foreground loop that ends when its turns are spent, so closing the terminal or pressing Ctrl+C stops it, and completed work stays on disk. It never keeps running in the background after you have moved on.

runtime
local
one-time
persistence
continuation-turns
task-completion
effort-tiers
drift-resistance
long-horizon
iteration
refactor
migration
test-coverage
bug-sweep
self-verification
unattended
single-session

Use cases

01
You ask a coding agent to fix a bug, it makes one change, and it tells you the job is done. Ten minutes later you find the same bug in three other places, because the pattern that caused it was copied around the codebase long before you noticed. The agent was not wrong about the one instance it fixed; it just stopped looking the moment it had something to report. Now you are hunting the rest by hand, which is the part of the job you wanted to hand off.
How the agent solves it
Describe the class of bug rather than the one line you found, so the extra turns have something to search for. Run it at a low tier first, because a repeated pattern is usually found within a handful of passes. Each continuation turn re-sends your exact task and asks the agent to look for what it missed, which is precisely where the other instances live. Read the final response for the list of places it changed. If it still reports new instances on its last turn, run it again one tier higher.
What to run
1. Command
```
vidbyte-cli runtime persistence "Every call to parseAmount() that passes user input without trimming it first is a bug. Find and fix all of them, then run the tests." --strength 2
```
What you get
Every instance of the pattern fixed in one run instead of one instance fixed per prompt.
- The first pass fixes the instance you pointed at.
- Later passes find the copies in other modules and fix them the same way.
- The final response lists every file changed, so you can review the sweep in one place.
- The test run on the last pass confirms nothing broke along the way.
02
A refactor is too large for one agent turn, so you end up babysitting it. You approve a step, re-prompt, and remind the agent what the original goal was every time it drifts toward something easier. By the fourth reminder the requirement has been paraphrased into a weaker version of itself. You are doing the job of the loop, and doing it worse than a loop would.
How the agent solves it
State the whole refactor once, including the finished state and anything that must keep working. Run it at a middle tier so there are enough turns for a change that spans many files. Every continuation turn re-sends your wording exactly, so the goal at turn thirty is the goal you wrote at turn one. You can leave the keyboard while it runs and read the final response when it ends. The babysitting becomes a single command.
What to run
1. Prompt
  Paste this page's copy prompt into your coding agent and answer its questions about the refactor, so the task text states a finished state and a definition of done.
2. Command
```
vidbyte-cli runtime persistence "<task text from the prompt>" --strength 4
```
What you get
A finished refactor that never drifted, run without you supervising it.
- Forty continuation turns against the same unedited requirement.
- Changes across every affected module, not just the first few.
- A final response that states what was changed and what was verified.
03
You ask for tests and the agent writes three happy-path cases, declares the code covered, and stops. The error paths, the empty inputs, and the edge cases you actually worry about are all untested. You only find out when you read the suite, which means reviewing tests you asked someone else to write. The coverage report looks fine because it counts lines, not the behavior you care about.
How the agent solves it
Ask for the test suite and spell out what done means: every branch, every error path, and the specific edge cases you care about. Give it enough turns for the agent to keep finding uncovered paths after the obvious ones are gone. Each pass re-reads the code with your definition of done in front of it and adds what is still missing. Tell it to run the suite on every pass so a test that fails gets fixed rather than deleted. Read the final response for the list of cases it added.
What to run
1. Command
```
vidbyte-cli runtime persistence "Write tests for src/billing/refunds.ts covering every branch, every thrown error, empty and negative amounts, and currency mismatches. Run the suite each pass." --strength 3
```
What you get
A test suite that covers the cases you named, not just the three obvious ones.
- Tests for every branch and thrown error in the module.
- Explicit cases for empty, negative, and mismatched inputs.
- A green suite on the final pass, run by the agent rather than claimed by it.
04
The agent says it verified the change, and you have no evidence it ran anything at all. The summary reads as confident as if the build had passed, but there is no output, no test count, and no sign of a command. You either take the claim on trust or rerun everything yourself. A verification you cannot see is just a sentence.
How the agent solves it
Put the verification inside the task text: run the build, run the tests, and fix whatever fails. The agent can actually execute those commands in your working directory, and the continuation turns give it room to fix a failure and check again. A single pass tends to report a failure and stop, so the later passes are where the fix happens. Ask for the command output in the final response so the verification is visible. You then read evidence instead of a claim.
What to run
1. Command
```
vidbyte-cli runtime persistence "Make npm run build and npm test both pass. Fix whatever fails, rerun both after each fix, and end with the output of the last run." --strength 3
```
What you get
A change that was actually built and tested, with the output to prove it.
- Build and test failures fixed across passes instead of reported once.
- The final build and test output included in the response.
- No verification step that exists only as a sentence.
05
You have a long, boring, mechanical migration, like renaming a pattern across a hundred files. It is exactly the kind of job an agent quits halfway through, announcing success after sixty files because sixty felt like enough. Nothing about the remaining forty is hard; they just never get reached. You end up finishing the tail yourself, one file at a time.
How the agent solves it
Describe the migration and the finished state, including how to tell a file is done. Run it at a high tier, because mechanical breadth is exactly what a large turn count is for. Each continuation turn asks the agent to find what is still unmigrated, so the tail keeps shrinking instead of being declared finished. Include a check in the task, such as a search that must return nothing, so the agent can prove the migration is complete. Read the final response to confirm the check came back empty.
What to run
1. Command
```
vidbyte-cli runtime persistence "Replace every import from lib/legacy-date with lib/date and update call sites. Done means grep -r legacy-date src returns nothing and the tests pass." --strength 5
```
What you get
The whole migration finished, with a check that proves nothing was left behind.
- All call sites moved, including the ones deep in rarely touched modules.
- An empty search result as the proof of completion.
- Passing tests after the last file changed.
06
You are not sure whether a task will take one pass or twenty. Picking a high tier up front feels wasteful if the task turns out to be small, and picking a low tier risks the same early stop you are trying to avoid. With a general agent there is no way to decide this ahead of time, because the effort you get depends on how it read your tone. You need a way to start small and scale up only when the work proves it needs more.
How the agent solves it
Start at the lowest tier, which adds six turns, and read the final response. If the last turns were still finding real work, the task needs more effort, so run it again one or two tiers higher. The same task at a higher tier resumes nothing from the earlier run, but the working tree already holds the earlier edits, so the new run starts from further along. Strength is the one dial that matters, and it is a number you choose rather than something you negotiate. After a few tasks you will know which tier fits which kind of work.
What to run
1. Command
```
vidbyte-cli runtime persistence "<your task>" --strength 1
```
2. Command
```
vidbyte-cli runtime persistence "<the same task>" --strength 3
```
What you get
The right amount of effort, found by starting small and stepping up.
- Small tasks finish at the lowest tier without extra turns.
- Larger tasks show they need more by still finding work on their last pass.
- A rough map of which tier suits which kind of job in your codebase.
07
You want an agent's work folded into a script, a Makefile target, or a scheduled job, but chat agents are built around a person reading along. Their output mixes progress chatter with the answer, and they stop to ask whether the result helped. Parsing the real answer out of that is fragile, and the stop means nothing finishes unattended. The work you want automated still needs someone watching it.
How the agent solves it
Run the task as a single command and redirect its standard output, which carries only the final answer. Progress lines go to standard error, so your script gets a clean result without any parsing. The run never pauses to ask you anything, and it ends on its own when its turns are spent. Use a tier that matches the job, and write the task text so the final answer has the shape your script expects. The agent becomes one more step in a pipeline.
What to run
1. Command
```
vidbyte-cli runtime persistence "Update CHANGELOG.md for every commit since the last tag, then print only the new section." --strength 2 > changelog-section.md
```
What you get
An agent step that runs unattended and hands a script clean output.
- Only the final answer on standard output, ready to redirect into a file.
- Progress on standard error, visible when you want it and ignorable when you do not.
- A run that ends on its own instead of waiting for someone to reply.
08
Your coding agent's context is full of the conversation you have been having with it. The task you actually care about now competes with an hour of discussion, dead ends, and pasted logs. Answers get slower and vaguer, and the agent keeps referring back to ideas you already rejected. Starting a new chat means re-explaining everything by hand.
How the agent solves it
Hand the task to a fresh persistent run instead of continuing the cluttered session. The run starts a clean session scoped to that one task in that one directory, so the whole context is the work rather than the discussion about the work. Write the task text as a complete instruction, since the new session has none of your earlier conversation. Pick a tier for the size of the job and let it run. Go back to your original session for discussion, and let the persistent run do the execution.
What to run
1. Prompt
  Ask your current agent: "Summarize what we decided about this task as one self-contained instruction, with no reference to our conversation."
2. Command
```
vidbyte-cli runtime persistence "<the self-contained instruction>" --strength 3
```
What you get
The task executed in a clean context, with the discussion left behind.
- A session whose entire context is the task.
- No drift back toward ideas you already rejected.
- Your original conversation kept free for thinking rather than execution.

Why use this agent

A general coding agent is tuned to stop. It answers, asks whether that helped, and hands control back, which is correct behavior in a conversation and wrong behavior for a task you wanted finished. The result is a familiar pattern: the first plausible change, presented as a completed job, with most of the remaining work invisible until you go looking. You then become the loop, re-prompting four or five times with some version of keep going. That costs your attention and gradually loses the original requirement, and this agent is that loop run for you, with the requirement re-sent word for word every time.

The second thing a general agent cannot give you is a chosen amount of effort. Whether you get one pass or ten depends on how it read your tone, and you find out afterwards. Here the effort is a number you set before it starts: six extra turns, or a hundred, from one flag. That makes the trade explicit and repeatable, so a small fix gets a small tier and a migration gets a large one. Effort stops being a negotiation and becomes a parameter.

The third is continuity. When you restart a stalled agent by hand, the new session re-derives the situation from whatever you paste into it, and something always gets lost. Every turn here resumes the same session, so the agent at turn forty knows exactly what it did at turn three. The final answer is separated from the progress along the way, which is what lets the result feed straight into whatever comes next. You get one agent that kept working, not a string of agents that each started over.

Stopping at the first answer
The continuation turns exist to spend effort after the point a chat agent would hand control back. What you receive is the work after the last pass, not after the first. The easy eighty percent stops being presented as the whole job.
Becoming the retry loop
Re-prompting an agent five times with keep going is real attention spent on nothing. That is exactly the work this automates. You set a tier once instead of typing an escalation five times.
Requirements drifting mid-task
Every follow-up turn re-sends your original wording exactly. What the agent is working toward at turn seventy is what you asked for at turn one. Nothing gets paraphrased into something easier along the way.
Unpredictable effort per task
Strength tiers 1 through 6 map to 6, 8, 20, 40, 70, and 100 extra turns. The amount of work is a number you choose before it starts rather than something you discover afterwards. A small fix and a large migration become two different commands instead of two different arguments with the agent.
Amnesia between passes
All turns resume the same session, so each pass builds on the last instead of re-deriving the situation. It is one agent continuing, not twenty agents starting. Nothing learned early gets lost to a restart.
Unfinished mechanical work
Wide, boring migrations are where an agent's willingness to declare completion hurts most. A high turn count is the direct answer to breadth. The job either finishes or you can see exactly where it stopped.
Claims without any verification
The agent can run the build and the tests in your working directory, not just describe them. The extra turns give it room to fix a failure and check again instead of reporting one and stopping. You get command output, not a sentence saying it passed.
Unbounded autonomous runs
Edits are confined to the repository you aimed the run at, with no sandbox bypass. A long unattended run can change that project and nothing else on the machine. Running for a long time does not have to mean running without limits.
Losing control mid-run
Ctrl+C cancels the active turn and closes the session, and completed work stays on disk. Stopping early is a normal action, not a crash. You can read what it did so far and decide whether to rerun it.
Context buried in conversation
Each run opens a clean session scoped to one task in one directory. The whole context window is the task rather than your conversation about it. That matters more on a long run than on a short one, because clutter compounds with every turn.
Answers tangled with commentary
Progress goes to standard error and only the final answer goes to standard output. A script can capture the result without parsing around status lines. The agent becomes a step you can compose rather than a chat you have to read.

When to use it

When the task is bigger than one agent turn and you do not want to supervise it.
When a general agent has already told you it was done and you did not believe it.
When the same bug almost certainly appears in more places than the one you found.
When the work is mechanical and wide, such as a rename or a pattern applied across many files.
When you want tests that cover the branches, not the three obvious cases.
When you want the agent to run the build and the suite and fix what breaks, not report it.
When you are going to walk away from the keyboard and want progress to continue without you.
When drift is the risk, because the requirement is specific and easy to soften.
When you want to decide up front how much effort this task is worth.
When your current agent session is cluttered and the task deserves a clean context.
When the first pass usually gets most of the way and the rest is found by looking again.
When you need the changes on disk rather than a description of the changes.
When you want the same task to behave the same way the second time you run it.
When you want to rerun a task at a higher tier after reading what a lower tier produced.
When a script or a scheduled job needs the agent's final answer as clean output.
When a migration needs a completion check the agent can run itself.
When the approach is already decided and what is missing is thoroughness.

Agent environment

Pricing

$0.02 per launch

runtime
local
one-time

Persistent Agent is a runtime: it runs on your machine, in your current working directory, through the Codex CLI you already installed, against your own OpenAI account. Codex runs with workspace-write sandboxing and no sandbox bypass, so the agent can edit the repository you pointed it at and nothing outside it. Vidbyte charges a one-time flat $0.02 per launch, taken only after the CLI has confirmed your task, the SDK, and that Codex is actually installed, so a missing Codex costs you nothing. The model usage is yours and separate: a strength-6 run is 100 extra turns on your own OpenAI subscription, which is the number to think about before raising the tier. Your task text, environment values, and provider credentials never reach Vidbyte with the admission.

Setup is four things: install vidbyte-cli, log in with your Vidbyte key, add balance at the usage page, and store an OpenAI key with `vidbyte-cli provider login openai` for Codex to run on. The install prompt below makes your own coding agent check each of those in order and only asks you about the ones that are missing. This agent is live today. If you would rather settle the launch charge from an x402 wallet than from your balance, the `--with-x402-payment` flag does that without changing anything else about the run.

Run it from the command line

Every agent starts with the same two setup commands: install vidbyte-cli, then log in with your Vidbyte key. Persistent Agent also needs an OpenAI key stored for Codex, and then it is one command with a strength dial. Two read-only checks confirm your machine is ready before you launch anything.

```
git clone https://github.com/cerredz/Vidbyte-cli
cd Vidbyte-cli
python -m venv .venv && source .venv/bin/activate
python -m pip install -e ".[dev,codex]"
```
Installs vidbyte-cli, the command line every Vidbyte agent is started and tracked from. It is at version 0.1.0 and is not published to PyPI yet, so it installs from source into a virtual environment rather than with a bare pip install. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked and the command is on your PATH.
Subcommands
-e
Installs the package in editable mode, pointing at the folder you cloned instead of copying it somewhere else. A later `git pull` in that folder updates the CLI without a reinstall. This is the install mode the CLI's own README documents.
".[dev,codex]"
Adds the optional extras on top of the base package. The codex extra carries the Vidbyte SDK's Codex integration, which every agent that drives Codex needs, and dev carries the build and lint tools from the README's development install. Git has to be installed, because the SDK revision is fetched from source.
```
vidbyte-cli login
```
Stores your Vidbyte API key, which is what identifies you and what every agent's charge is billed against. It reads the key at a hidden prompt, checks it against Vidbyte before saving anything, and then keeps it in your operating system's keyring. Run `vidbyte-cli whoami` afterwards to confirm which account the stored key belongs to.
Subcommands
--with-token
Reads the key from standard input instead of a hidden prompt, which is how you log in from a script or a CI job. Pipe it in from your secret store rather than typing it into the command. There is deliberately no --api-key flag, because anything in the command line leaks into process listings, shell history, and CI logs.
--allow-file-fallback
Approves storing the key in a permission-restricted file when the machine has no operating-system keyring, such as a bare Linux server. Without it, login asks before falling back, or refuses when there is no terminal to ask on. Anything running as your user can read that file, so use it only where a keyring genuinely is not available.
```
vidbyte-cli provider login openai
```
Stores the OpenAI key that Codex will actually run against, separately from your Vidbyte key. This is the account your model usage lands on, so choose it deliberately. The CLI resolves the key from OPENAI_API_KEY first, then from this stored profile.
Subcommands
--with-token
Reads the OpenAI key from standard input instead of a hidden prompt. Use it in scripts and CI, piping the key from your secret store. The key never has to appear in the command line or your shell history.
--allow-file-fallback
Approves storing the key in a permission-restricted file when no operating-system keyring is available. Without it, the command asks first or refuses when it cannot ask. Anything running as your user can read that file.
```
vidbyte-cli runtime persistence "<your task>"
```
Launches one persistent session on the task exactly as you wrote it, in the current working directory. It confirms your setup, admits the run, and then drives Codex through the first turn and every continuation turn. Only the final response goes to standard output, so it drops into a script cleanly.
Subcommands
--strength
Sets how hard the agent pushes past its first answer, from 1 to 6, defaulting to 1. The tiers add 6, 8, 20, 40, 70, and 100 continuation turns, each resuming the same session. Raise it for wide or mechanical work and keep it low for a focused fix.
--idempotency-key
Recovers a launch whose outcome you never saw, such as after a dropped connection. Re-running with the same key recovers the original admission instead of charging you again. It does not resume local work, so never reuse a key to rerun a task that already finished.
--with-x402-payment
Settles the launch charge from an x402 wallet instead of your Vidbyte balance, using VIDBYTE_X402_PRIVATE_KEY from your environment. The wallet must already hold USDC, because the CLI never funds it. Your Vidbyte API key still establishes who owns the run.
--host
Names the coding agent that runs the session, and accepts auto or codex. Codex is the only host this agent runs on, so the flag exists to make the host explicit in scripts. Leaving it out is the same as passing codex.
```
vidbyte-cli runtime doctor
```
Checks which supported coding-agent hosts this machine has, before you spend anything. Run it first on a new machine, so a missing Codex shows up as a diagnostic rather than a failed launch. It is a read-only check and costs nothing.
```
vidbyte-cli runtime list
```
Lists the runtimes Vidbyte will admit, with the charge for each read from Vidbyte's catalog rather than hard-coded in the CLI. The persistence line is the price you will actually pay. Use it to compare this agent against the others before choosing one.

Run it from your own agent

Copy prompt

Paste this into the agent you already use and it will ask you what you need, then write the exact Persistent Agent invocation for your job.

You are helping me write the task text for Vidbyte's Persistent Agent, which runs one Codex session on my machine and then pushes it through 6 to 100 additional improvement turns depending on the strength tier I pick. Ask me these one at a time and wait for each answer: (1) what outcome I want in the repository when it finishes, stated as a finished state rather than as steps, (2) how I will know it is actually done — the command that must pass, the file that must exist, the behavior that must change, (3) anything it must not touch, and (4) roughly how wide the work is, so we can choose a tier. Then give me the exact command to run, including the task text in quotes and a `--strength` value with one sentence on why that tier and not the one above it. Keep my wording specific, because every continuation turn re-sends this text verbatim and vagueness compounds across a hundred turns.

Copy install prompt

Paste this into your own agent and it will check what is already installed and logged in, then walk you through only what is missing.

Set me up to use Vidbyte's Persistent Agent. Run the checks below yourself, in order, before you ask me anything, and let each result decide the next thing you say. Never ask me to paste an API key into this conversation.

1. Run `vidbyte-cli --version`.
   - If it prints a version, say so in one line and go to step 2.
   - If the command is not found, say: "It looks like vidbyte-cli isn't installed yet. Do you want me to install it for you?"
     - Yes: it is at 0.1.0 and not on PyPI, so install from source: clone https://github.com/cerredz/Vidbyte-cli, create a virtualenv, run `python -m pip install -e ".[dev,codex]"`, then re-run `vidbyte-cli --version`.
     - No: tell me the install is the one thing every agent needs, and stop.

2. Run `vidbyte-cli whoami`.
   - If it prints "Authenticated as", I am logged in. Go to step 3.
   - If it prints "Authentication is required.", ask: "You're not logged in yet. Do you already have a Vidbyte API key?"
     - Yes: ask me to run `vidbyte-cli login` in my own terminal. It takes the key at a hidden prompt and checks it before storing it in my keyring. Re-run `vidbyte-cli whoami` when I say it is done.
     - No: these two steps are browser-only, so give me one link at a time and wait. First https://vidbyte.pro/login, where Google sign-in creates the account. Then https://vidbyte.pro/settings/api, where I create a key that is shown once. Then have me run `vidbyte-cli login` myself.

3. Ask: "Have you already added balance to your Vidbyte account?" The CLI cannot read a balance, so ask rather than guess.
   - No or not sure: send me to https://vidbyte.pro/usage to add balance, and wait for me to confirm.

4. Run `vidbyte-cli runtime doctor`.
   - If the codex line says "not found", say: "Persistent Agent runs through the Codex CLI and this machine does not have it. Do you want me to install Codex?" Install it only if I say yes.
   - Then run `vidbyte-cli provider whoami openai`. If it fails, say: "Codex needs an OpenAI key and none is stored. Please run `vidbyte-cli provider login openai` in your own terminal, so the key never passes through this conversation." Wait for me, then re-run it.

When every check passes, tell me what each one returned in one short list, then give me this command to start: `vidbyte-cli runtime persistence "<your task>" --strength 1`.

Similar agents

Ensemble Agent
Pick this one instead when the hard part is deciding how to do the work, not doing it thoroughly once decided.
Open agent page →
Task Board
Pick this one instead when the job is already broken into ordered tasks and you want them worked through in sequence.
Open agent page →
Adversarial Team
Pick this one instead when the work is finished and what you need is for it to be attacked.
Open agent page →

Agents

One job, one workflow, one deliverable. See how Persistent Agent compares to the rest of the lineup.

Browse all agents →