Agent · Available now

Persistent Agent

Stops your coding agent from calling a job done at the first plausible answer. One focused workflow, with a clear result at the end.

Read docs

How it works

You give it one task, written the way you would explain the finished job to a colleague. It hands that task to the coding assistant you already use and lets it work. When the first answer comes back, it hands the same task over again and asks for another pass, looking for what was missed and tightening what was rushed. Each pass builds on the work of the one before it, so the result keeps improving instead of starting over. You decide up front how much effort the job deserves, and the run keeps going until that effort is spent.

What you get back is the work itself, finished as far as the run could take it. Edits land directly in your project as real changes, not as a plan describing changes someone still has to make. The final response tells you what was changed and what was checked, so you can review the whole sweep in one place. Progress updates stay separate from that final answer, which means the result drops cleanly into whatever comes next. A second run of the same task behaves like the first, because the effort is set before it starts rather than negotiated along the way.

It does not choose between approaches and it does not break a job into pieces for you. It takes the one task you wrote and pushes that task all the way through, which is why the wording of the task matters more here than anywhere else. A vague task stays vague no matter how many passes run against it, so state the finished outcome and how you will recognize it. It also does not run forever or drift onto new goals, because every pass works from your original wording exactly as you wrote it. When the run ends, the completed work stays where it was made and you decide what happens next.

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

Agent environment

Pricing

$0.02 per launch

runtime
local
one-time

Persistent Agent runs Codex in your current working directory. It can edit the repository you point it at, but it cannot write outside that workspace. Each pass works on the same task, so the work improves without the agent switching to a different goal. Your task text and provider credentials stay on your machine.

This agent is live today. Install vidbyte-cli, log in with your Vidbyte key, and connect your OpenAI account for Codex. The install prompt checks your setup and gives you the command to start a run.

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…

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.

bash
pipx install vidbyte-cli
Installs vidbyte-cli from PyPI, the command line every Vidbyte agent is started and tracked from. pipx gives it its own environment and puts the `vidbyte-cli` command on your PATH; without pipx, run `python -m pip install vidbyte-cli` inside an activated virtual environment instead, and read the CLI repository README for the full installation notes. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked.
View subcommands
--python
Picks the Python interpreter pipx builds the CLI's environment with, such as `--python python3.12`. vidbyte-cli needs Python 3.11 or newer, so set it when your default Python is older and the install refuses to resolve.
bash
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.
View 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.
bash
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.
View 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.
bash
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.
View 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.
bash
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.
bash
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.

Use cases

Each example names the problem, the setup, the command to run, and the result you should expect.

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.

Persistent Agent

How it works

Agent environment

Run it from your own agent

Copy prompt

Run it from the command line

Use cases

Why use this agent

When to use it

Similar agents

Ensemble Agent

Task Board

Adversarial Team