Claude for Legal is Anthropic’s open-source (Apache-2.0) legal toolkit, released May 12, 2026, that runs common legal workflows inside Claude Cowork or Claude Code.1 The release positions the toolkit as a configurable layer for litigation, transactional, regulatory, and other legal work. Public commentary has covered the release widely.
Yet published evidence of what the toolkit produces when implemented remains limited. What kind of analysis Claude-for-Legal actually produces is an empirical question, one that this article seeks to answer.
This article benchmarks Claude-for-Legal’s chronology skill across eleven distinct combinations of Anthropic models (Haiku, Sonnet, Opus) at different effort levels (Low through Max). The chronology skill, one of several skills in the litigation plugin, extracts events from a case file and builds a timeline. The skill is benchmarked against Harvey Labs’ build-litigation-case-timeline task, which provides a synthetic 15-document breach of contract case file (Harborview v. Greenleaf).
Background: What Claude-for-Legal Actually Is
Claude-for-Legal is not a standalone application. It is a directory of skills and agents that loads into a harness (Claude Code, Claude Cowork) running a Claude model. The model, harness, and Claude-for-Legal layers each do a different job. The model (Haiku, Sonnet, or Opus) supplies general reasoning capability and may be configured to run at one of several levels of effort. Claude Code and Claude Cowork are harnesses that provide the model with an environment to load files, write files, run shell commands, and hold sessions together across turns. Claude-for-Legal sits on top of the harness as a toolkit of twelve practice-area plugins that each provide a set of skills for specific legal tasks.2 The plugins also include MCP connectors that link to platforms like legal-research databases and document management systems, providing skills with context the harness alone cannot reach.
This isn’t a novel architecture, AI skills typically perform abstract tasks by running structured protocols inside a harness. What differentiates Claude-for-Legal are profiles that provide company (or firm), practice, and case specific context when skills are performed. Generally, these profiles are generated from templates through a cold-start-interview, then nested within Claude-for-Legal’s config directory. They include a company profile, practice profiles, portfolio registers, matter profiles, and event logs.
The company profile provides organization-level context and is read by every plugin, while additional nested profiles provide practice-area specific and matter specific context. When invoked, skills draw context from pertinent parts of the profile stack to generate results that are tailored to an attorney’s company, practice, and the relevant matter.
Yet plugin architecture cannot answer what kind of analysis Claude-for-Legal provides. That question requires testing a realistic legal task.
Methods: Testing Claude-for-Legal’s Chronology Skill
One of Claude-for-Legal’s most testable skills is “chronology,” a litigation skill that extracts events from a case file, identifies the user’s theory of the case and tags each event’s significance to this theory, flags potential information gaps (i.e., missing documents), and constructs a timeline.3 The build-litigation-case-timeline benchmarking task, provided by Harvey Labs4 under an open-source (MIT) license, presents a good test case for the chronology skill because it provides a synthetic case file and scoring rubric for chronological extraction. Indeed, this task asks AI models to develop a “Chronological Event Summary” from the 15-document case file of a fictional Harborview v. Greenleaf breach of contract dispute. Equally important, the Harvey Labs task comes with a 66-criterion rubric for scoring the extracted chronologies.5
Consistent with the “Breach of Contract and Fraud Defense” focus of Harvey Labs task, the Claude-for-Legal chronology skill was tested from the perspective of a defense-focused firm. Here, Greenleaf’s counsel. This perspective was reflected during Claude-for-Legal’s cold-start-interview to generate appropriate firm and practice profiles to simulate the chronology skill on Harvey Labs’ build-litigation-case-timeline task.6
Following the cold-start-interview, the chronology skill was run against the Harborview v. Greenleaf case file under eleven model and effort combinations: Haiku Low, Medium, and High; Sonnet Low, Medium, and High; Opus Low, Medium, High, Xhigh, and Max.7 Each run produced a summary and full chronology report. Example summaries from Haiku High, Sonnet Low, Sonnet High, and Opus Medium are shown below.
The eleven chronology simulations took 2–16 minutes to complete, consumed 85,000–249,000 tokens, and extracted 23–73 events into resulting chronology reports.
[Select figure for interactive chart]
These resulting chronologies were scored against the 66 criteria of Harvey Labs’ rubric. Scoring was performed independently by two LLM judges: Opus 4.7 and GPT-5.5.8 The two-judge setup was chosen to reduce single-model scoring bias and to surface ambiguous criteria. Judge agreement was tracked per criterion and used as a reliability signal in the analysis.
Results: How Well Each Model Captured the Rubric Criteria
Judged scores across the eleven simulations ranged from 26.5 to 57 (40.2% to 86.4%) coverage of the 66 criteria, with the runs clustering into two distinct sets. The lower cluster (Haiku at every effort level, plus Sonnet and Opus at Low effort) had shorter run times, used less context, and covered 40.2% to 62.1% of the rubric criteria. The higher cluster (Sonnet at Medium effort and above, plus Opus at Medium effort and above) had longer run times, used more context, and covered 76.5% to 86.4% of the rubric criteria. Top coverage was tied between Opus at Medium effort and Opus at Max effort, both at 57 criteria (86.4% coverage).
Coverage scores measure whether each model simulation satisfied the rubric's criteria. Whether coverage breadth approximates analysis quality is an open question.
The overall coverage of each model and effort combination can be broken down across the 66 rubric criteria. The eleven runs demonstrate distinct patterns across pre-litigation events, litigation timeline events, and issue identification, as illustrated in the coverage heat map below. Each row represents one of the 66 rubric criteria; each column, one model/effort run; cells are filled where the run satisfied the criterion, hashed where the two judges disagreed.
Patterns emerge by model and by criterion type. Opus models (except at Low effort) cover nearly all pre-litigation and litigation events (C-001 through C-028), show sporadic issue spotting (C-032 through C-053), and produce serviceable claim and damages assessments (C-054 through C-058 and C-060 through C-062). Sonnet models nearly match Opus on pre-litigation and litigation events but show slightly sparser issue identification (see, e.g., C-044, C-046, C-048, C-051). Haiku models are significantly sparser: their coverage concentrates on pre-litigation events (C-001 through C-013), thins rapidly for litigation timeline events (C-014 through C-028), and is minimal for issue identification or claim and damages assessment. Across all models, coverage is better for event identification than for issue identification and claim and damages assessment. Consistent with the more subjective nature of issue identification and claim and damages assessment, Opus 4.7 and GPT-5.5 more commonly disagreed on whether these criteria were satisfied.
Conclusion: What Benchmarks Can and Cannot Say
Claude-for-Legal’s chronology skill, run against Harvey Labs’s build-litigation-case-timeline task, produces chronologies that vary substantially in rubric coverage across model and effort combinations. Coverage tended to scale with model capability and, within more capable models (Sonnet, Opus), plateaued around Medium effort. These coverage results report what each run did against a specific rubric on a specific synthetic case. They do not report whether the resulting chronologies are good legal work product for any particular use.
Those evaluating Claude-for-Legal for legal analysis work will want to ask several questions this benchmark does not answer:
Do the coverage patterns observed here translate to other legal analysis tasks, or are they specific to extracting events into a chronology or timeline?
Which categories of legal analysis is AI well-suited to perform (factual event extraction, legal event extraction, issue spotting, claim assessment, damages assessment), and which require human work?
Is coverage breadth a good approximation for analysis quality, or should a different test be developed?
What the benchmark offers is comparison material to start from: the model and effort choices, the comparable outputs on a known case file, and the cost-per-run profile. The legal-quality assessment is the reader’s to make.
This analysis is for educational and informational purposes only. It is not legal, financial, or other professional advice and does not create an attorney-client or any other professional relationship. The analysis is based solely on publicly available information. Any views expressed are solely those of the author in the author’s individual capacity.
Claude-for-Legal is Anthropic’s open-source legal toolkit, accessed at https://github.com/anthropics/claude-for-legal (commit 9cecd91, accessed May 15, 2026) under the Apache License 2.0.
The twelve practice areas include commercial, corporate, employment, privacy, product, regulatory, AI, IP, litigation, law-student, law-clinic, and legal builder hub.
The chronology skill’s full specification ships in chronology/SKILL.md within Claude-for-Legal’s litigation plugin. The skill runs in two modes. The matter mode (default for in-house counsel) reads from a declared matter and its document-storage sources. The documents mode (default for firm associates and paralegals) reads from an eDiscovery production or custodial file set. The output is a markdown chronology with significance tags (🔴 key, 🟡 relevant, ⚪ background), per-entry source attribution, a gaps section, and on-request variants for a statement-of-facts skeleton and a witness-specific timeline.
The Legal Agent Benchmark (LAB) is Harvey AI’s open-source legal-agent benchmark, accessed at https://github.com/harveyai/harvey-labs (commit 5aa4169, accessed May 17, 2026) under the MIT License. LAB evaluates LLM-driven agents on legal tasks using rubric-based scoring against expert-written criteria. This analysis evaluates Claude-for-Legal’s chronology skill against LAB’s build-litigation-case-timeline task by modifying LAB’s evaluation methodology to report per-criterion coverage rather than an all-pass score and to use a two-model judging protocol (Opus 4.7 and GPT-5.5) rather than LAB’s default single-judge configuration.
The build-litigation-case-timeline task is defined in its task.json file in the Harvey Labs repo under the litigation practice area. The 66-criterion rubric is embedded as the criteria array; each criterion specifies a match-criteria plain-language pass condition and the deliverable file the judge should evaluate against. See “Results,” below.
The cold-start-interview asked questions covering user type, role, side, practice setting, install scope, and MCP availability. Beyond defense framing, the captured profile sets the firm-associate role, a small-firm practice setting, project-scoped installation, and CourtListener as the only authenticated research MCP for the runs.
Benchmarking results are available on GitHub (https://github.com/overfit-dicta/legal-ai-benchmarks/claude-for-legal/chronology). This repository includes the eleven chronology reports, composite rubric scores from both judges as a downloadable spreadsheet, and per-criterion scoring decisions are available for each each judge: Opus 4.7 and GPT-5.5.
Opus 4.7 was run at Xhigh effort and GPT-5.5 was run at Extra High reasoning. Each judge applied the rubric’s match-criteria pass conditions to the agent output and returned per-criterion verdicts with reasoning. Per-criterion agreement statistics, criteria where the judges disagreed substantially, and any criteria requiring manual arbitration are detailed in the rubric heatmap of “Results,” below.