Agent · Planned

InfiniteMemory Agent

Carries one long task across as many sessions as it takes, with every piece checked before it counts and everything learned kept as files you can read. One focused workflow, with a clear result at the end.

Read docs

How it works

The InfiniteMemory Agent takes one long task, such as a research question, a report, an analysis, an operations job, or an audit of a codebase, and works on it in a workspace folder you choose. A coordinating agent splits the task into pieces and writes a card for each one, naming its goal, what done looks like, and how the result should be checked. Each piece goes to a fresh pair of agents: one does the work, and the other checks it against the card before anything it found is kept. A worker can split its own piece again when it is still too big, while a checker never delegates, so the work spreads into a tree of checked pieces. The coordinator reads back only a short result card from each pair, which keeps its own conversation small however much work happens underneath it.

What builds up is a workspace of plain files that outlasts the session. It holds short memory entries, each one a decision, a fact, a lesson, an open question, or a pointer, along with longer notes, copies of the files you supplied, and a journal of every piece that started and finished. An entry a worker proposes is kept only after its checker gives a verdict, and the checker can drop it with a reason. When the run ends you get a handoff whose nine sections cover the outcome, the work done, the decisions, facts and lessons, the open questions, the files, anything unverified or failed, and how to continue. A later run in the same workspace starts from everything earlier runs learned, and a run that stopped partway resumes without redoing the pieces that already finished.

The agent does not review or undo what its shell commands do, so nothing rolls back a command that changed a file. It has no search by meaning; agents find what earlier pieces saved by searching the workspace text. There is no final review of the whole run beyond each piece's own checker. A piece that was cut off partway runs again from its start when the run resumes, and the memories it had only proposed are lost. It works one task per run, and two runs never use the same workspace at the same time.

  • harness
  • hosted
  • usage
  • long-running
  • durable-memory
  • resumable
  • task-decomposition
  • generator-verifier
  • checked-work
  • memory-entries
  • workspace-notes
  • run-journal
  • handoff
  • context-limits
  • multi-agent
  • research
  • investigation

Agent environment

Pricing

Usage-based

  • harness
  • hosted
  • usage

You start the InfiniteMemory Agent from vidbyte-cli in your project folder, and it needs no Codex install or OpenAI login of its own. Every model call the coordinator, the workers, and the checkers make goes through Vidbyte to the model provider, OpenAI, and your Vidbyte balance pays for it at that model's per-token rate plus 2%. Each call carries the task, your standing instructions, and whatever the agents read from your files and the workspace, so give it only material you are willing to send to OpenAI. If you export OPENAI_API_KEY in your shell, those calls go out on that key instead, so OpenAI bills your own account and Vidbyte charges only its 2% fee. Each run or resume stops once its priced model calls reach the cost cap you set, 5 US dollars unless you choose another, counted before the 2% fee, though pieces still working at that moment can spend past it.

Unless you pass --no-sync, the task, the agent events, the handoff, and the notes are stored in your Vidbyte account for 90 days and shown at /agents/dashboard, while the raw model conversations are never uploaded. The agents' shell commands run in your project folder as you, with the Vidbyte key and other known secrets removed from their environment, but they can still read your files, your keyring where the stored Vidbyte key lives, and an exported OPENAI_API_KEY. To get started, install vidbyte-cli and log in with a Vidbyte API key that carries models:invoke for the model calls and runtime:write for storing runs; an admin or full-access key carries both. Add balance before the first run. This agent is not available yet: the vidbyte-cli commands that start and resume it have not shipped in a released vidbyte-cli. Run `vidbyte-cli agents infinite-memory --help` to check, because it reports no such command until the agent ships and lists run and resume once it has. The install prompt below runs these checks for you.

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 InfiniteMemory Agent invocation for your job.

You are helping me use Vidbyte's InfiniteMemory Agent, which works one long task in a workspace folder through pairs of agents that do and check each piece, keeps what it learns as files, and can resume after a stop. Ask me these one at a t…

Run it from the command line

Install vidbyte-cli and log in with a Vidbyte key that carries the models:invoke and runtime:write permissions. Then start a run on one long task in a workspace folder, and use resume to continue a run that stopped.

  1. 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.
  2. 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.
  3. bash
    vidbyte-cli agents infinite-memory run "<task>"

    Starts a new run on one task in a workspace folder and prints the run's handoff when it ends. The task is the quoted argument, the text of a file, or standard input when you pass a single dash, and it may be at most 20,000 characters long. Every option is checked before your key is read or any model is called, so a mistake costs nothing. Each model call after that goes through Vidbyte and is metered against your balance, up to the cost cap.

    View subcommands
    --prompt-file
    Reads the task from a UTF-8 text file instead of the quoted argument, which suits a task longer than a line. Pass either the argument or this option, never both. A relative path is read from the current folder, and the task may not be blank.
    --workspace
    Names the folder where the agents keep their memory entries, notes, copies of your files, and the run journal, and creates it when it does not exist. It defaults to the infinite-memory folder under the current folder, so running again from the same folder reuses the same memory. Only one run or resume can use a workspace at a time, and a workspace inside a git repository belongs in its .gitignore file.
    --seed
    Copies one of your files into the workspace before the agents start, so every agent can read it as background. Repeat it once per file, up to 200 files, each with a different file name. With sync on, the list of supplied files stored with the run records only each file's name, size, and SHA-256 digest, not its folder or its text.
    --no-sync
    Keeps this run on your computer: nothing is stored in your Vidbyte account, and your agent dashboard does not show it. A run started this way is never uploaded by a later resume, even one without the option. Model calls are still billed through your Vidbyte key either way.
    --max-cost-usd
    Sets the most this run may spend on priced model calls, in US dollars, above zero, defaulting to 5. After each agent event it is compared with the priced cost before the 2% fee, and a call that cannot be priced is not counted. When it is reached the agents are stopped, the result says how much was spent, and the printed resume command continues the run. Pieces still working at that moment can spend past it, so set it below what you can afford.
    --instructions
    Appends the text of a file you trust to the system prompt that every agent in the tree receives, such as your team's standing rules. Repeat it for up to 8 files and 20,000 bytes in total, and the files are read once, when the command starts. The text goes to the model provider with every agent and its tokens are repeated in each one, so keep it short and free of secrets.
    --model
    Names the model that every agent in the tree runs on, as OpenAI's own model identifier, defaulting to gpt-6-sol. Each call is billed at that model's per-token rate plus 2%, so a pricier model raises the cost of the whole run. A model that cannot be run or priced is refused before any call is billed.
    --reasoning-effort
    Is accepted by every vidbyte-cli agent command, but this agent refuses it before anything starts. The InfiniteMemory Agent has no reasoning effort setting, so leave it out.
    --send-to
    Sends the rendered handoff to one more place after the run ends, repeated once per place: slack, slack:NAME, github:OWNER/NAME, linear, or linear:TEAM. Every target and its credential are checked before the agents start, so a missing webhook or token costs nothing. The handoff is sent only when the command returns normally, and if a target fails, the others are still tried and the command exits with status 1.
  4. bash
    vidbyte-cli agents infinite-memory resume --run-id <run-id>

    Continues a run that stopped before it finished, from the journal in its workspace, and prints its handoff when it ends. Pieces that already finished return their recorded results without running again. A run whose agents had already finished is never run again; resume then only uploads what its sync left pending, with no model call. On the computer that started the run, the workspace and the model come from its saved state.

    View subcommands
    --run-id
    Names the run to continue, as printed when it started and as shown on the run's page on your agent dashboard, such as 20261015T150131Z-f4cc56a3. It is the start time in UTC, a dash, and eight lowercase hexadecimal digits, and any other shape is refused before anything is touched.
    --workspace
    Names the run's workspace folder, replacing the one saved for the run, which helps after the folder was moved. It is required on a computer that has no saved state for the run, such as a second machine you copied the workspace to, and there the command runs from your project folder. A relative path is resolved against the current folder.
    --no-sync
    Keeps this resume on your computer, so nothing it does is uploaded. A run started with --no-sync is never uploaded by a resume, with or without this option.
    --max-cost-usd
    Sets the most this resume may spend on priced model calls, in US dollars, defaulting to 5 and counted before the 2% fee. It covers this invocation only, not what the run spent before it stopped. Pieces still working when it is reached can spend past it.
    --instructions
    Appends the text of files you trust to the system prompt of every agent the resumed run starts, up to 8 files and 20,000 bytes in total. The files are read once, when the command starts, and their text goes to the model provider with every agent.
    --model
    Changes the model the resumed agents run on. Left out, the run keeps the model saved for it on this computer, or gpt-6-sol when there is no saved state. Each call is billed at the chosen model's per-token rate plus 2%.
    --reasoning-effort
    Is accepted by every vidbyte-cli agent command, but a resume refuses it before anything starts. The InfiniteMemory Agent has no reasoning effort setting, so leave it out.
    --send-to
    Sends the rendered handoff of the resumed run to one more place, with the same targets as on a run. Every target is checked before the agents start, and the handoff is sent only when the command returns normally.

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 agent works a long task inside one conversation, and that conversation is the only place the work lives. As it grows, the oldest tool output is trimmed or summarized away, so a figure found in the first hour is gone by the fourth, and the agent starts repeating searches and contradicting its own early findings. Asking it to keep notes helps only until the notes themselves crowd the conversation. The InfiniteMemory Agent keeps the coordinating conversation small on purpose: each piece runs in a fresh pair of agents, and only a short result card comes back. Everything worth keeping is written to the workspace as an entry or a note that every agent can search. The task can therefore be far larger than any single conversation, and the hundredth piece can still use what the first one learned.

A general agent also grades its own work, so a piece is done when the agent says it is done. On a long task those small self-approvals add up to a confident summary built on steps nobody checked. Here every piece is checked by a separate agent against done criteria written before the work started, and a finding becomes a lasting memory only after that checker accepts it. A checker can drop a proposed memory and say why, which keeps a wrong guess from becoming a fact every later piece relies on. Work that failed its check is not smoothed over, because the handoff lists it under unverified or failed work. You finish knowing which parts of the result were checked and which were not.

Finally, a general agent's progress ends with its session. If the terminal closes, the laptop sleeps, or the run hits a limit, what remains is whatever you copied out, and the next session starts by re-reading everything. This agent journals every piece as it starts and finishes, so a stopped run resumes where it stopped and reuses the result of every finished piece instead of running it again. The workspace is plain files you can open, read, and correct yourself. A new task in the same workspace starts from all the decisions, facts, and lessons that earlier runs recorded. The handoff closes each run with what was done and how to continue, so the next session, yours or a teammate's, starts from a written state instead of a recollection.

  • Early findings quietly forgotten

    In one long conversation, what the agent learned first is the first thing trimmed away. Here every finding worth keeping is saved as an entry or a note in the workspace. Any agent can search for it later, however long the run has gone on.

  • Starting over each session

    Each new session of a general agent begins by re-reading files and re-deriving decisions it already made. A run here starts from the workspace that earlier runs filled. The decisions, facts, and lessons are already there when the first piece begins.

  • Self-approved work marked done

    When the agent that did the work also decides it is finished, unfinished work gets reported as done. Every piece here has a separate checker that holds it to done criteria written before the work began. A piece the checker does not accept is reported as failed, not as finished.

  • Guesses hardening into facts

    A wrong assumption saved early becomes the base that every later step builds on. Here a memory a worker proposes is kept only after its checker gives a verdict. A checker can drop it and record the reason, so the guess never reaches the rest of the run.

  • Crashes erasing hours of work

    A closed terminal or a dropped connection usually ends a long agent session with nothing saved. Every piece here is journaled as it starts and finishes. Resuming continues from the stop, and finished pieces return their recorded results instead of running again.

  • One overloaded conversation doing everything

    A single agent juggling research, drafting, and checking runs out of room before the task runs out of steps. Here the coordinator only plans and reads short result cards while fresh pairs do the pieces. Its own conversation stays small enough to keep the whole task in view.

  • Summaries that hide failures

    A long run usually ends with a tidy summary that leaves out what went wrong along the way. The handoff here has its own section for unverified or failed work. You see the gaps before someone else finds them.

  • Notes trapped in chat

    When the work lives in a chat transcript, getting it out means copying and reformatting by hand. Here the memory entries, notes, and journal are plain files in a folder you choose. You can read them, correct them, and share the ones worth keeping.

  • Big tasks flattened into one

    Asked for a large job, a general agent tends to work it as one long sequence and lose track of the parts. Here the coordinator breaks it into pieces with their own goals and done criteria, and a worker can split a piece again when it is still too big. Each part of the job gets a clear finish line.

  • No idea where it stands

    With a long unattended run, the usual question is whether it is still working and what it has done so far. With sync on, your agent dashboard shows what every agent did, piece by piece, while the run goes on. The handoff then says what is done and how to continue.

  • Unattended runs running up bills

    An agent left alone on a long job can keep making model calls long after the job stopped being worth it. Every run here takes a cost cap and stops its agents when the priced cost reaches it. The result says what was spent, and the printed resume command picks the work up if you decide to continue.

  • Repeating searches already done

    Without a shared record, separate agents re-run the same searches and re-read the same files. Every agent here sees a map of the workspace at the top of its context and can search the entries and notes before it starts. Work that one piece already did is found instead of done again.

When to use it

  • When the task is bigger than one conversation can hold.

  • When you keep re-explaining the same background at the start of every session.

  • When the work will take days and you will stop and start it many times.

  • When each part of the job should be checked by someone other than the one who did it.

  • When a wrong fact early on would quietly spoil everything built on it.

  • When you need to know which parts of a result were verified and which were not.

  • When a run might be interrupted and starting over would throw away hours of work.

  • When the findings must outlive the session as files you can read and edit.

  • When the next task builds on what the last one learned.

  • When a research question spans more sources than one reading session can keep straight.

  • When an audit has to cover every file, module, or record, not a sample.

  • When you would rather start a long job at night and read its handoff in the morning.

  • When a teammate will pick up the work and needs to know exactly where it stands.

  • When the job splits naturally into pieces that can run side by side.

  • When decisions made in the first week must still hold in the third.

  • When open questions should stay on record until someone answers them.

  • When an agent has declared a long task done that turned out half finished.

Similar agents

More in agent workflows

  • Persistent Agent

    Pick this one instead when the task fits in one session and the risk is your coding agent calling it done too early.

    Open agent page →
  • Persistent Researcher

    Pick this one instead when the job is a web research question and what you need is every source kept and filed.

    Open agent page →
  • Task Board

    Pick this one instead when you already have a task list you trust and want each task run in order, not split up by the agent.

    Open agent page →
  • Suggestion Agent

    Pick this one first when you are not yet sure which long task is worth starting.

    Open agent page →