# Consensus Threads API: Research Follow-Ups, MCP and Pricing

Consensus now lets connected agents continue a research thread, with a different workflow and cost model from a paper search.

By Paras Madan | 2026-10-22

Consensus added Threads to its API and MCP on October 21, 2026. Developers and connected assistants can now start research, ask follow-up questions and retrieve earlier threads, with the work also available in the user’s Consensus account. The change makes a continuing investigation available outside the Consensus interface.

This is a substantive extension to an existing service. Consensus’s [official changelog](https://help.consensus.app/en/articles/11954907-consensus-product-changelog) dates self-serve API access to August 26 and full-text excerpts to September 18. The new release is Threads, rather than the first launch of the API or MCP server.

## What changes from paper search

A search returns papers for an application to work with. A Thread can conduct multiple research steps and produce a cited answer, then use earlier turns when the user narrows the question. Consensus’s [API overview](https://help.consensus.app/en/articles/16516328-the-consensus-api) describes both the cited response and the ability to continue API-created work in its own interface.

For a research application, that changes what needs to be built around the service. The application can retain a thread identifier and continue an investigation instead of reconstructing the earlier search and answer on every turn.

There is still a choice to make. If a product only needs a paper list for its own ranking or synthesis pipeline, ordinary search may be the simpler interface. Delegating a multi-step investigation gives Consensus more control over how the evidence is gathered and summarized.

## How the Threads API works

The [Threads quickstart](https://docs.consensus.app/api-quickstart-threads) documents an asynchronous flow:

| Action | Endpoint |
| --- | --- |
| Start research | `POST /v1/threads` |
| Retrieve status and answer | `GET /v1/threads/{thread_id}` |
| Ask a follow-up | `POST /v1/threads/{thread_id}/interactions` |
| List earlier threads | `GET /v1/threads` |

A new run returns its identifier while still running. Poll at the returned interval, normally 30 seconds, until it reaches `idle` or `failed`. A follow-up submitted during an active run returns `409`.

The default `pro` mode suits ordinary questions; `deep` does more research and requires a paid plan. Documentation gives waiting windows of about three minutes for Pro and ten for Deep. These are workflow expectations, not a claim that every result arrives at exactly that time.

Developers should provide a complete brief because the agent does not ask clarifying questions. After a `5xx` error, check whether the thread already exists before retrying. Otherwise, one user request could become two investigations.

## Consensus API and MCP pricing

The [technical plans documentation](https://docs.consensus.app/api-plans-and-access) lists a shared monthly allowance across API and MCP:

| Plan | Included calls | Maximum with additional usage |
| --- | --- | --- |
| Free | 30 | 30 |
| Pro | 500 | 1,000 |
| Teams | 500 | 1,000 |
| Deep | 2,000 | 10,000 |
| Enterprise | Custom | Custom |

Pro, Teams and Deep can enable additional usage at $0.05 per call, up to their limits. It is off by default.

**A Thread is not necessarily one billable call.** Its charge depends on the work performed. While it runs, the maximum possible cost counts against the allowance; a failed run costs nothing. Search and conversational research therefore should not be compared simply by counting HTTP requests.

The Help Center still lists fixed Enterprise allowances, while the technical plans page lists custom limits. Enterprise teams should confirm their contracted allocation rather than assume either self-serve figure applies.

## What developers should measure

A good pilot should measure the quality of follow-up answers alongside latency and calls consumed. Start with a broad technical question, narrow it to a particular method, then ask which cited results actually support the conclusion. That checks whether a continuing thread helps the investigation rather than merely preserving its earlier wording.

Citations give a reader somewhere to check; they do not remove the need to inspect whether the evidence supports the answer. For a product using Threads, the important design decision is how easily users can move from the generated conclusion to the papers behind it.

I’m Paras. I work at the intersection of AI, engineering and distribution.

If you’re building an AI API or developer tool and want help turning technical updates into clear stories developers actually use and share, I’d be happy to work with you.

[Book a 30-minute call](https://cal.com/paras-madan/30min).