Agent · Available now

Persistent Researcher

Every source you research is kept, filed, and still there next week — not thrown away with the session that found it.

Persistent Researcher runs research as a thread instead of a conversation. You give it a question, it goes and reads, and every source it finds is written down with its link, a summary of what it says, and one line on why it bears on your question. That record belongs to your account, not to a chat window, so closing the tab costs you nothing. Come back in a week with a follow-up question and it adds to the same thread rather than starting over. The research accumulates the way a file accumulates, not the way a conversation evaporates.

What you get back is a thread you can read, share, and keep adding to: a set of filed sources, what they agree on, where they contradict each other, and which claims nothing supports yet. Each run inside a thread has its own public ID, so you can check a run's status, follow it until it settles, or resume one that stopped partway. Threads carry rollup counters, so you can see how much has been gathered on a question without opening every run. Nothing has to be reconstructed from scrollback.

It does not write your document and it does not decide for you. It gathers, files, and reports the state of the evidence, and the argument stays yours to make. You can scope a run by source kind, domain, publication date, and language, and that scope is part of what the thread records. The framing you set when you open a thread carries into every later run, so the tenth answer comes back in the same shape as the first.

harness
hosted
usage
research
source-filing
citations
literature-review
research-threads
evidence-trail
long-running-research
follow-up-questions
contradiction-mapping
market-research
competitive-analysis
due-diligence
research-handoff
resumable-runs

Use cases

01
You spent a week researching something across four different chats, and now none of it is anywhere you can find. You remember reading the answer, and you remember roughly where, but you cannot produce the link. Each chat holds a fragment, and none of them knows the others exist. The research happened; it just was never kept anywhere that lasts.
How the agent solves it
Open one thread for the question and keep the thread ID it prints. Every follow-up goes to that thread instead of into a new chat, so every source lands in the same record. The thread lives in your account, not in a browser tab, so it survives closed windows and lost laptops. When you need the evidence again, you list your threads and open the one for this question. Four scattered chats become one place.
What to run
1. Command
```
vidbyte-cli research start "Which open-source vector databases support hybrid search in production?" --size medium
```
2. Command
```
vidbyte-cli research add <thread_id> "Which of these have managed hosting in the EU?" --published-after 2025-01-01
```
3. Command
```
vidbyte-cli research threads --limit 20
```
What you get
One thread that holds every source for the question, findable by ID.
- Every source filed with its link, a summary, and why it matters.
- Follow-ups added to the same record instead of scattered across chats.
- A thread list that answers the question of what you were researching.
02
You try to continue research you started earlier, and your agent is already carrying 400k tokens of unrelated context. It is slow, it keeps re-reading things it already read, and it has started confusing this topic with the last one. Clearing the context means losing the research. Keeping it means working inside a swamp.
How the agent solves it
Add the follow-up to the existing thread rather than continuing the chat. The thread carries the filed sources, not the transcript, so the next run starts from a record of what has been read instead of from a wall of conversation. Your own agent's context window stops being the storage medium for the research. Clear your agent's context whenever you like, because the evidence is safe in the thread. Point your agent at the thread's results when it needs them.
What to run
1. Command
```
vidbyte-cli research add <thread_id> "What changed in the pricing of these vendors this year?" --size small
```
What you get
Research that continues without dragging a giant context along with it.
- A follow-up run that starts from the filed sources, not the old transcript.
- Your own agent's context freed for the work you are actually doing.
- No re-reading of sources the thread already holds.
03
You need to research four separate questions for one decision. Asking them in one session produces a blur, where you cannot tell which source answered which question. The conclusions bleed into each other, and one strong source ends up shaping answers it was never about. When someone asks where a claim came from, you cannot say.
How the agent solves it
Start four threads, one per question, and let each accumulate independently. Each thread keeps its own evidence trail, so a source filed under one question never quietly supports another. List the threads to see all four side by side, and open one to see its rollup. Decompose at the thread level instead of holding the separation in your head. When you write up the decision, each part cites its own thread.
What to run
1. Command
```
vidbyte-cli research start "What do customers pay for comparable tools?" --kind web
```
2. Command
```
vidbyte-cli research start "What does the peer-reviewed evidence say about the core technique?" --kind paper
```
3. Command
```
vidbyte-cli research thread <thread_id>
```
What you get
Four questions with four separate evidence trails.
- Each question's sources kept apart from the others.
- A rollup per thread showing how much has been gathered.
- Every claim in the write-up traceable to the right thread.
04
The research came back correct but formatted nothing like what you needed to hand to someone else. You wanted a comparison table and got five paragraphs of prose. You spend an hour reshaping it by hand, and the next run comes back as prose again. The shape drifts every time you return to the topic.
How the agent solves it
State the output shape in the question when you start the thread: the comparison you need, the columns, and who it is for. The thread keeps that framing across every later run, so run three comes back shaped like run one instead of drifting toward prose. Use this page's copy prompt to turn your need into a question with the shape built in. If the audience changes, open a new thread with the new framing rather than fighting the old one. The formatting hour disappears.
What to run
1. Prompt
  Paste this page's copy prompt into your coding agent and answer its four questions, including the exact output shape you want back.
2. Command
```
vidbyte-cli research start "<question from the prompt, with the table columns stated>" --target-sources 30
```
What you get
Research that comes back in the shape you need, every time.
- A first run that already matches the format you asked for.
- Later runs that keep the same shape without being told again.
- No hour spent reformatting before you can share it.
05
A run dies partway through, and you have no idea how much of the work survived. Maybe it failed, maybe it came back partial, maybe your balance ran dry in the middle. Starting over would redo everything that already finished. Guessing would leave holes you might not notice.
How the agent solves it
Check the run's status to see where it stopped, then resume that exact run rather than starting a new one. Resume picks up from the state Vidbyte already holds, so everything already filed stays filed. It covers runs that failed, came back partial, or stopped for lack of balance. If you are not sure whether an earlier resume went through, reuse its idempotency key to recover the result instead of creating a second one. The run finishes from where it stopped.
What to run
1. Command
```
vidbyte-cli research status <run_id>
```
2. Command
```
vidbyte-cli research resume <run_id> --idempotency-key <key-from-the-first-attempt>
```
What you get
A stopped run finished from where it stopped, with nothing redone.
- The run's phase and continuation count, so you know what survived.
- Filed sources kept rather than re-gathered.
- A resume that is safe to retry if the first attempt's result was lost.
06
You need to hand your research to a teammate, and the only artifact you have is a chat log. They would have to read it from the top to understand what you found and why. Half of it is you thinking out loud, and the sources are buried inside the answers. The handoff turns into a meeting.
How the agent solves it
Give them the thread instead of the chat. The filed sources, summaries, and relevance notes are readable without replaying your prompts, so they start from the evidence rather than from your reasoning about it. They can add their own follow-ups to the same thread and keep it growing. If they want the full text of a source, the website's deep dive has it. The handoff becomes a link.
What to run
1. Command
```
vidbyte-cli research threads --limit 50
```
2. Command
```
vidbyte-cli research add <thread_id> "Summarize the strongest and weakest evidence for a new reader." --size small
```
What you get
Research a teammate can pick up without a meeting.
- A thread they can read as evidence rather than as your conversation.
- A short summary run written for someone new to the topic.
- A shared record both of you can keep adding to.
07
You keep re-asking the same question every few weeks to find out whether anything has changed. Each time, the answer comes back mixed with sources you already read, and you cannot tell new from old. Monitoring a topic ends up costing as much effort as researching it did the first time. So you stop checking, and you miss the change that mattered.
How the agent solves it
Add a dated follow-up to the same thread instead of starting a fresh question. Ask what is new since a specific date, and restrict the run to sources published after it. The thread already knows what has been filed, so the new run's job is the difference, not the full sweep. Repeat it on whatever schedule the topic moves at. Each check is short, so you actually keep doing it.
What to run
1. Command
```
vidbyte-cli research add <thread_id> "What is new on this since March?" --published-after 2026-03-01 --size small
```
What you get
A topic you can monitor cheaply because each check asks only for the change.
- New sources separated from the ones already filed.
- A dated trail of what changed and when you learned it.
- Checks small enough that you keep running them.
08
You are about to make an expensive call, and you need to know not just what the sources say but where they disagree. A summary flattens exactly that part into one confident paragraph. The disagreement is usually where the risk is. If you only see the consensus, you are deciding with the most important information removed.
How the agent solves it
Ask the thread explicitly for the conflicts: which claims are contested, which side each source is on, and what nothing supports yet. Conflicts are only visible when sources are filed separately, which is what the thread is for. Widen the run with more target sources when the stakes justify it, so both sides are well represented. Restrict to papers when you need peer-reviewed evidence rather than commentary. You then decide with the disagreement in view.
What to run
1. Command
```
vidbyte-cli research add <thread_id> "Where do sources disagree about this, which side is each on, and which claims have no support?" --target-sources 60 --kind paper
```
What you get
The disagreements laid out, so the decision accounts for them.
- Each contested claim listed with the sources on each side.
- The claims nothing currently supports, named explicitly.
- A decision made with the risk visible instead of averaged away.
09
You fired off a long research run, and now you are sitting there refreshing. You cannot tell whether to wait or go do something else. Checking by hand every minute burns attention. Checking too rarely means the result sits unread for an hour.
How the agent solves it
Watch the run until it settles, with a timeout if you only want to wait so long. Watch prints changes as they happen and stops when the run reaches a final state. It polls on a backoff on purpose, because API keys are metered on a per-minute request budget and polling harder eats the budget you need to start the next run. If the timeout expires, the run keeps going and you can check it later. Either way you stop refreshing.
What to run
1. Command
```
vidbyte-cli research watch <run_id> --timeout 1800
```
What you get
A long run you can follow without babysitting it.
- Changes printed as the run moves through its phases.
- A clean stop when the run settles or the timeout expires.
- Your request budget left intact for the next run.

Why use this agent

A general agent researches inside a session, and the session is the storage. That is fine for a question you will answer and forget, and it quietly fails for every question that outlives one sitting. The sources go into the transcript, the transcript goes into the context window, and the context window is both finite and disposable. When you come back three days later, the agent has no idea what it read, so it reads it again and gives you a different answer the second time. Persistent Researcher moves the storage out of the session and into a thread that belongs to your account, so returning to a question is repeatable rather than a restart.

The second difference is auditability. A general agent hands you prose, and prose is exactly the format in which you cannot check anything: the claim and its source have been merged into one sentence, and the only way back is to search again yourself. This agent files each source separately with its link and a note on why it matters, and only then reports what the set adds up to. That gives you two things prose does not: a citation you can hand to someone skeptical, and a visible gap where the evidence is thin. When a decision is important enough to be questioned, being able to point at the source is the whole difference between research and an opinion.

The third is that research is rarely one question. It is a question that turns into four, spread over a week, revisited when something changes. A general agent has no unit for that, so you either hold it all in one bloated session or scatter it across sessions that cannot see each other. Threads are that unit. Each question gets its own accumulating record, and each run inside it can be tracked and resumed on its own. You stop managing conversations and start managing questions.

Research vanishing with sessions
Everything a run reads is filed under a thread you own. Closing the terminal, losing the laptop, or coming back in a month costs you nothing. The evidence is not stored in a transcript you have to keep alive.
Re-reading the same sources
Because the thread knows what has already been filed, a follow-up works from that record instead of reading the web from scratch. The second question on a topic starts ahead of the first. A chat session behaves the opposite way.
Context windows filling up
The sources live outside the model's context, so a long-running question never reaches the point where continuing means forgetting the beginning. Your own agent's window stays free for the work you are doing. Research stops competing with everything else in the session.
Claims with no traceable source
Every filed source carries its link, a summary, and the reason it bears on your question. Any sentence in the output can be walked back to a page someone else can open. That is what makes the research usable in a document that will be reviewed.
Summaries hiding disagreement
Filing sources separately keeps contradictions visible instead of averaging them into a confident paragraph. You are told where the sources conflict and which claims nothing supports. That is usually the most decision-relevant part.
Runs lost to failures
Runs are durable and addressed by their own ID, so a stopped run can be resumed where it stopped. Work already done stays done. A crash or a timeout stops being a restart.
Not knowing run progress
Status and watch report the real state of a run, including its phase and how many continuations it has had. You can decide to wait or leave without guessing. Watch backs off on purpose so following a run does not use up the request budget you need for the next one.
Research that cannot transfer
A thread reads as evidence rather than as your conversation. A teammate can pick it up without replaying your prompts or asking what you meant in message eleven. Handoff stops requiring a meeting.
Questions blurring together
One thread per question keeps each line of inquiry's sources separate. You can tell which evidence supports which conclusion. Decomposition happens in the threads instead of in your head.
Output shape drifting
The framing you set when you open a thread persists across later runs. The tenth answer comes back in the same form as the first. You stop re-specifying the format every time you return.
Monitoring costs full effort
A dated follow-up on an existing thread asks only for what changed. The thread already knows what has been filed. Keeping up with a topic stops taking the same effort as researching it.
No proof work happened
A thread is a durable record with a public ID, a run history, and filed sources. You can point at it in a review, a diligence process, or a postmortem. A chat log is not that.

When to use it

When the research will outlive the session you started it in.
When you will come back to the same question more than once.
When someone other than you will need to read the evidence.
When the sources matter as much as the answer, because the conclusion will be challenged.
When you are researching several related questions and need to keep their evidence separate.
When a decision is important enough that "where did that come from" must have an answer.
When you want to know where sources disagree, not just what the consensus paragraph says.
When the topic moves and you will need to ask what changed later.
When your own agent's context window is already full of the work you are doing.
When you are handing the topic to a teammate and do not want the handoff to be a meeting.
When the same question keeps getting re-asked across your team and nobody has a shared record.
When you need the research limited to particular domains, dates, languages, or source kinds.
When a previous run stopped partway and redoing its finished work would be a waste.
When you are gathering background for something that ships weeks from now.
When you want the research to accumulate rather than be re-derived every time.
When you need a durable record for a review, a diligence process, or a postmortem.
When you cannot sit and watch the run finish and need it to survive you walking away.

Agent environment

Pricing

Usage-based

harness
hosted
usage

Persistent Researcher is a hosted harness: it runs on Vidbyte's servers, so nothing depends on your machine staying awake, and you start and track runs from vidbyte-cli or from the research workspace on the Vidbyte website. Deep dives into a single source, full source bodies, and exports live on the website, so the command line is where you start and track work and the site is where you read it in depth. Pricing is usage-based: each run has a $5.00 admission floor and is metered from there against your prepaid Vidbyte balance, so the final cost varies with how much reading the run does. The `--max-cost-cents` option refuses a run that would cost more than the cap you set.

Setup is three things: install vidbyte-cli, log in with your Vidbyte key, and add balance at the usage page. There is no coding agent to install and no provider key to store, because the model calls happen on Vidbyte's side and are included in the metered price. The install prompt below makes your own coding agent check each of those in order and only asks you about what is missing. This agent is live today.

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. After that, Persistent Researcher is a small set of research commands for opening threads, adding to them, and tracking runs. The reading itself happens on Vidbyte's side, so none of these commands needs your machine to stay awake.

```
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 research start "<your question>"
```
Opens a new thread for one question and starts its first run. This is the command that creates the record everything else attaches to, and it prints the thread ID you will use from then on. State the output shape you want here, because the thread keeps that framing for later runs.
Subcommands
--size
Picks a preset breadth for the run: small, medium, or large. Use it when you do not want to size the run by hand. A small run suits a quick follow-up, and a large one suits a first sweep of an unfamiliar topic.
--target-sources
Sets how many sources discovery should aim to collect, from 1 to 1000. Raise it when you need both sides of a contested question well represented. Lower it for a focused check.
--search-calls
Caps how many search calls the run may make, from 1 to 100. It bounds how widely the run looks before it starts reading. Use it to keep a narrow question narrow.
--kind
Restricts discovery to one kind of source, paper or web, and can be repeated. Use paper when you need peer-reviewed evidence rather than commentary. Leave it out to search both.
--include-domain / --exclude-domain
Restricts discovery to, or excludes, a specific hostname, and each can be repeated. Include a domain when you trust a particular source, and exclude one when it keeps crowding out better material. The scope is recorded with the run.
--published-after
Only considers sources published on or after a date, written as YYYY-MM-DD. It is how a follow-up asks for what is new since the last check. Combine it with a dated question for the cleanest result.
--language
Sets a preferred source language, such as en. Use it when the audience reads one language or when a topic is covered best in a particular one. Leave it out to accept any language.
--max-cost-cents
Refuses the run if it would cost more than this many cents, from 1 to 100000. It is a hard ceiling on one run's metered spend. Set it whenever you want a run's cost known before it starts.
--idempotency-key
Lets you retry a start whose result you never saw without being charged twice. Reuse the key the first attempt printed, and the original result is recovered. Leave it out and a fresh key is generated.
```
vidbyte-cli research add <thread_id> "<follow-up>"
```
Adds another run to a thread that already exists, which is how a question grows without starting over. The new run works from what the thread has already filed rather than re-reading everything. Use it instead of opening a second thread whenever the follow-up is about the same question.
Subcommands
--published-after
Limits the follow-up to sources published on or after a date. It is the option that turns a follow-up into a check for what changed. Pair it with a question that names the same date.
--size / --target-sources / --kind
Size and scope the follow-up exactly as they do for start. Add accepts every option start accepts, because both submit the same kind of run. Keep follow-ups small unless they open a genuinely new angle.
--idempotency-key
Lets you retry an add whose result you never saw without being charged twice. Reuse the key the first attempt printed. Leave it out and a fresh one is generated.
```
vidbyte-cli research resume <run_id>
```
Continues a run that stopped partway because it failed, came back partial, or ran out of balance. It picks up from the state Vidbyte already holds rather than redoing finished work. This is the command that makes a stopped run a pause instead of a loss.
Subcommands
--idempotency-key
Lets you retry a resume whose result you never saw without being charged twice. Reuse the key the first attempt printed. The original resume is recovered instead of a second one starting.
```
vidbyte-cli research status <run_id>
```
Reports one run's current state, its phase, how many continuations it has had, and when it last changed. It is a single check that returns immediately. Use it when you just need to know whether to keep waiting.
```
vidbyte-cli research watch <run_id>
```
Follows one run until it reaches a final state, printing changes as they happen. Use it when you want to be told the moment a run settles rather than checking yourself. It backs off deliberately, because API keys are metered on a per-minute request budget.
Subcommands
--timeout
Stops waiting after this many seconds, up to a full day. The run itself keeps going when the timeout expires. Use it in scripts that should not block forever.
```
vidbyte-cli research threads
```
Lists every thread you own, which answers the question of what you were researching. Each row carries the public thread ID the other commands take. It is a read, so it starts no run.
Subcommands
--limit
Sets how many threads to return in one page. Leave it out and the server picks a sensible default. Raise it when you are looking for an old thread.
--cursor
Continues from the cursor a previous page reported. Use it to walk through a long list of threads page by page. Each page prints the cursor for the next one.
```
vidbyte-cli research thread <thread_id>
```
Shows one thread and its rollup counters, so you can see how much has accumulated on a question without opening each run. It is the fastest way to decide whether a line of inquiry is worth pushing further. Pass the public ID that start or threads printed.

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

You are helping me write a research brief for Vidbyte's Persistent Researcher, which files every source it reads into a durable thread I can return to. Ask me these four things one at a time and wait for each answer: (1) the single question I want answered, (2) what decision the answer feeds and who will read it, (3) the exact output shape I want back — comparison table, ranked list, annotated source set — and (4) any sources, dates, domains, or languages that are in or out of scope. Then write me the finished command as `vidbyte-cli research start "<question>"` with the scope turned into the matching options (`--kind`, `--include-domain`, `--exclude-domain`, `--published-after`, `--language`, `--size`), phrased as a single question with the output shape stated explicitly, and tell me which follow-up questions I should file as separate threads instead of folding into this one.

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 Researcher. 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.

When every check passes, tell me what each one returned in one short list, then give me this command to start: `vidbyte-cli research start "<your question>" --size small`.

Similar agents

Persistent Agent
Pick this one instead when the work is a task in your repository that needs to be finished properly, rather than a question that needs sources.
Open agent page →
Ensemble Agent
Pick this one instead when you already know what needs doing and want several genuinely different approaches argued out before anything is written.
Open agent page →
Adversarial Team
Pick this one instead when you have a finished piece of work and need it attacked before someone else attacks it.
Open agent page →

Agents

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

Browse all agents →