Harvey Context Window Token Limits

Generative AI models work with context windows which restrict the number of tokens which can be entered in a single query.

So when you're setting up a workflow in Harvey AI, which may use multiple prompts to generate a legal document, each 'block' is limited to 240 pages of text, which might be 100,000 to 200,000 tokens.

This post on harvey.ai , lists the following context range limits:

A review table in Harvey is kind of like a spreadsheet in which entries are provided in a cell for categories separated by columns. There can only be 60 pages of text in each cell.

So you can see here in this demonstration that it is identifying which agreements uploaded as PDFs have a particular type of provision, how this provision is defined, and the basis for the provision to become activated:

A Harvey thread, which is limited to 240 pages of text that consists of a prompt, a series of questions and answers, and uploaded documents. Threads are used to get information about a subset of documents quickly. It's possible to stay under the limit by structuring queries so that the system only analyzes relevant materials. Threads are used to get information about a subset of documents quickly.

So, in a thread the user can interact with Harvey to get results by entering commands in the pane on the left that modifies the work product on the right.

Harvey allows for groups of documents to be collected in big sets of up to 100,000. Queries or commands can then be entered to make Harvey generate content based on just the documents in a vault. So, a user could upload thousands of contracts a business is party to, and get Harvey to generate a table indicating how each agreement meets the requirements of a particular regulation.

A database of court decisions discussing AI Hallucinations

Damien Charlotin, a lecturer in legal data analysis at Sciences Po in Paris, has created an online database listing decisions by courts from around the world in which caselaw, legal norms, and even exhibits were identified as AI hallucinations. See: https://www.damiencharlotin.com/hallucinations/?q=&sort_by=-date&states=USA&period_idx=0

A high percentage of the parties identified as using AI were individuals representing themselves pro se. The database links to PDFs of the decisions, and sometimes provides short summaries of the holding faulting parties for the improper use of AI.

A recent decision by the Supreme Court of North Dakota, Volker v. Nygaard, No. 20250309, 2026 WL 533638 (N.D. Feb. 26, 2026), upheld a district court decision which dismissed a plaintiff's claims under Fed. R. Civ. P. 11 because he repeatedly used non-existent case citations which were created by an AI tool. "During the hearing on the motion, the court warned Volker that his filings contained fictitious legal citations. Despite this warning, Volker filed additional briefs containing fictitious citations . . . At the Order to Show Cause hearing, the district court found that Volker had willfully defied the court and dismissed the action with prejudice as a Rule 11 sanction." Id. at 1.

Charlotin has also developed a system, Pelaikan, which checks the accuracy of citations used in legal briefs. The database of court decisions related to AI hallucinated content includes Pelaikan reports on the briefs criticized by the decisions . These reports explain why the citations are incorrect:

In a decision this January, NYSCEF Doc. No. 45, Decision, Order and Judgment After Sanctions Hearing, Cassata v. Michael Macrina Architect, P.C., Index No. 617183/2025, 2026 WL 263521 (N.Y. Sup. Ct. Jan. 27, 2026), the New York Supreme Court for Suffolk County fined an attorney who, "did not conduct a reasonable, human-based verification of every cited authority before filing her opposition.", and failed to correct her filing when the mistakes were identified. This decision by Justice Linda Kevins includes an exhibit which lists other cases reviewing similar conduct by attorneys, which she considered before imposing sanctions against the defendants' attorneys.

Searching for Bates numbers in Everlaw

Everlaw provides you a great deal of flexibility when you need to look up documents by a Bates number. For too many years, when being asked to locate documents that use a Bates number that is neither the PRODBEG or PRODEND number, I have had to set a search to cover a range of documents with a Bates number 100 - 1000 numbers less than and greater than the number cited in a report or other document. Everlaw's 'Page search' check box configures the search so that the document within which the number is used will be returned.

As is shown in this example, there's a helpful list of Bates prefixes to select from. (Why have I worked in so many Relativity databases lately which have split the production numbers across multiple metadata fields??). It's not necessary to use the correct number of leading zeroes. So here when we search for page 100 from the PRODTRAIN production, it returns the document with the beginning Bates number PRODTRAIN-000096 and the ending Bates number PRODTRAIN-000103.

If you click on the link for Advanced settings, you'll get a window in which you enter multiple Bates numbers, and here the 'Page Search' checkbox is available as well. Not that much different from running a search for multiple Bates numbers in Relativity, but here you have the option to upload a text file with multiple Bates numbers (each listed on a different line).

Everlaw also makes it possible to run a search through all entries in the email From, To, Cc, and Bcc fields in the Parties field, or all entries in the To, Cc, and Bcc fields in the Recipients field.

Note the lightning bolt icon next to these fields. This is an indication that multiple email metadata fields have been aggregated so that it's only necessary to run one search for each name.

Similarly, the 'All Text Fields' field allows for a search through all text metadata fields, and includes an option to search through document contents at the same time: