Off the Rack Does Not Fit: How a Plaintiff-Side Patent Litigator: Why a Patent Litigator Builds His Own AI

By Erick S. Robinson

SEPTEMBER 26, 2026

NOTE: All references are hyperlinked within the text of the article.

I. Bottom Line Up Front

I build my own AI tools for my plaintiff-side patent litigation practice. For a specialized practice like mine, I think that is usually the most accurate, most efficient, and most cost-effective way to use AI right now, even with some good off-the-shelf legal and patent tools on the market. Over the past several months I have designed and built six tools that chart infringement, find infringers from a patent alone, test patent eligibility against the case law, calculate reasonable-royalty damages, and assemble a filing-ready case. They pull their facts from the record through APIs and MCP, and much of the work runs as local AI on a Mac Studio on my desk, so a client's confidential material never leaves the room.

The case for building rests on three structural problems with off-the-shelf ("OTS") legal AI. The first is opacity: most platforms do not tell the lawyer which model answered, at what reasoning effort, or what the retrieval layer left out. The second is margin: a vendor must sell compute for more than it pays, so it has every reason to ration it. The third is one-size-fits-all intelligence: a platform that runs every task on one model at one setting overpays for easy work and underpowers hard work.

This matters most to firms like mine. AI is the great equalizer in the practice of law, because it lets a mid-sized firm match the output of opponents with far more lawyers and far more money. OpenAI launched Astra for Law on September 17, 2026, and offered it first to selected firms through a program reportedly aimed at the AmLaw 200, a reminder that the best tools do not always reach everyone at once. I address that rollout in a companion article, The Great Equalizer, Reserved for the Already Equal. This article is about what a small or mid-sized firm can do in the meantime.

Bottom line: for a specialized practice, building beats buying on accuracy, cost, and control, as long as a human starts the work and a human finishes it. And using local AI is a plus.

This article proceeds in seven parts. Part II explains why I build and describes the tools, the data layer behind them, and the local hardware they run on. Parts III through V set out the three structural problems with OTS legal AI: opacity about the model and its reasoning effort, vendor margin, and one-size-fits-all intelligence. Part VI applies all of it to patent litigation, where attrition is often the other side's strategy. Part VII pulls the threads together.

II. Why a Patent Litigator Builds His Own AI

I should be clear about where I stand. I am a fan of AI, including in the practice of law. I want lawyers using it creatively and efficiently, and I want them using it safely. I write about it on my blog and talk about it on my podcast, and I design, build, and run my own AI workflows, applications, and strategies for my patent litigation practice. My firm is not in the AmLaw 200. We have, however, used AI strategically and broadly for longer than some of the largest firms with far bigger names in AI, including Latham, Cooley, and Cleary.

My build stack is ordinary by the standards of software engineering and unusual by the standards of law firms. I use Claude Code and OpenAI's Codex as agentic coding environments for the heavier engineering, and Cursor, Base44, Lovable, and Replit for rapid application development -- always planned and tweaked with my programming background and knowledge. I describe the tools themselves below. None of it required a software engineering team. It required knowing the practice, knowing how the models behave, and a willingness to iterate. Although in a prior life, I was a programmer (what they used to call a "coder"), the AI coding tools are getting so good even that is not necessary, even if it may take a few more tries and tests.

Experience has pushed me to one conclusion. For a specialized practice, it is usually more effective, more efficient, and cheaper to build my own AI tools than to buy OTS tools like Harvey, CoCounsel, or the many patent-specific platforms that are nonetheless one-size-fits-all.

The reason is control. An OTS platform is built to serve thousands of firms across dozens of practice areas. Its prompts are engineered for the average user and tuned to avoid errors across a mass market. Its codebase carries every feature any customer ever asked for, including the ones I will never use. Its release cycle belongs to its product team.

When I build, I design for one workflow: mine. If I want an application that pulls a set of patents and their file histories, extracts the claim limitations and the prosecution statements that bear on each one, and formats the result into the exact chart structure my team uses, I build that application and nothing else. When the workflow changes, or a better model ships, I change the tool that afternoon. I do not file a feature request and wait.

Building also puts the engineering levers in the lawyer's hands, and those levers are where the quality and the cost live. A tool that calls the model APIs directly can set the model and the reasoning effort for every call. It can cache a long patent specification once and reuse it across dozens of queries instead of paying to resend it. It can push bulk, non-urgent work through a batch interface at half the standard token price. It can require structured output, so the model returns a claim chart as data a program can check, not prose a lawyer has to parse. It can add a verification pass that confirms every quotation against the source text before a human ever sees the draft. None of those choices is exotic. All of them are invisible, or unavailable, inside most OTS platforms.

The development tools have also changed the economics of building. A production application used to mean hiring engineers. Today, an AI-first code editor or a command-line coding agent can write a lightweight application around a single workflow, and a platform like Base44 can generate the database structure, user authentication, and API connections from plain-language instructions. Building my own tool means paying for the development environment and for direct API usage from providers like Anthropic and OpenAI. It does not mean paying for premium enterprise seats, for features I will never touch, or for an enterprise markup.

Table 1. Off-the-shelf platform vs. direct build

Dimension	OTS platform	Direct build
Model choice	Vendor selects; often hidden or a short menu	Any model the firm can reach through an API
Reasoning effort	Set by the vendor and not shown	Set per task by the user
Retrieval and context	Vendor-controlled chunking, ranking, and truncation	Designed around the firm's documents and workflow
Update speed	Vendor release cycle	Same day
Cost basis	Per-seat fee, seat minimums, vendor margin	Published API rates, paid per use
Transparency	Closed system	Prompts, models, and settings visible and versioned
Security certifications and support	Provided by the vendor	The firm's responsibility
Up-front effort	Low	Requires time and in-house skill

What I Built: Six Tools and One Rule

Over the past several months I designed and built a suite of patent litigation tools, and I run them on my own hardware. They draft infringement claim charts, find infringers from a patent alone, test patent eligibility under § 101, calculate reasonable-royalty damages under the governing case law, and assemble a filing-ready case for the Eastern District of Texas. Each one automates a piece of patent litigation that used to consume associate hours, and each one runs on a discipline the work already demands: cite the source, show the math, and never invent a fact. And, of course, have a human review everything multiple times before it is ready for prime time.

Figure 1. How the tools fit together. A lawyer starts every matter and finishes it, and the data layer sits under every tool.

That discipline is built into the software, not added as a disclaimer. Every factual assertion is grounded in a fetched source. Every citation links to the URL or filing it came from. Every dollar figure ties back to a public document. Where the model cannot ground a claim, the tool says so instead of papering over the gap. The commercial products I evaluated worked the other way around: they hid their reasoning behind a friendly box and asked me to trust the output. A tool that drafts a claim chart in ninety seconds is worthless if it invents a limitation, and a damages number no one can trace is a liability. I will create a later post that includes some of my favorite tools that I use via API or MCP because AI cannot be fully leveraged without some of these "old school" tools such as financial databases, patent databases, web searching/scrubbing, and many others.

ClaimCharter. Point it at up to 30 patents and a defendant's website, or up to five websites when the defendant's products span several domains, and it returns litigation-quality infringement claim charts with detailed citations. It pulls the claims from the USPTO, detects every independent claim of every patent, breaks each one into its limitations verbatim, searches the defendant's site(s) and the open web for evidence of each limitation, and assembles the chart element by element, with every citation linked to its source. If I leave the accused product blank, it discovers the defendant's products itself, scores every product-and-claim pair, and charts every plausible read of 5 out of 10 or better. Each limitation carries a proposed 1-to-10 infringement rating, covering literal infringement and the doctrine of equivalents, with a plain-English explanation of why it is met or where it falls short, and the rows are color-coded so a partner can read the strength of a chart at a glance. A Master Chart rolls every claim and accused product into one view, with low, mean, and high ratings per product.

It also works from what I already have. It can read a project folder in a local document vault directly, with nothing uploaded, and it accepts up to 100 existing claim charts, verifies each one element by element against live sources, discards anything inaccurate or unverifiable, and uses what survives first. It downloads each patent's prosecution history through the USPTO's Open Data Portal API and feeds it into claim construction. Four tiers set how much work each chart gets, from Budget (20 KB of evidence per claim element, up to 8 charts per run, and one deep retry for weak elements) to Maximum (90 KB, up to 30 charts, and three retries). A separate table sets the model and reasoning effort for every step of the pipeline, from claim parsing through chart analysis, weak-element retries, and prior-chart verification, with models from Anthropic, OpenAI, Moonshot, xAI, Google, DeepSeek, Qwen, MiniMax, Zhipu, and Meta.

Below I have includedscreenshots from the claim charting tool.

Figure 2. ClaimCharter's four charting tiers, from the app's settings screen.

Target Finder. Target Finder runs the process in reverse. The input is patents alone, with no defendant named, and the output is a ranked matrix of candidate infringers: the company, the accused product, and the URLs that prove it, each grounded in a real fetched page and a verbatim snippet. An optional setting limits the search to the 528 companies sued as patent defendants in the Eastern and Western Districts of Texas since January 1, 2020, drawn from 13,067 cases and starting with the most frequently sued, such as Samsung, Google, and Apple. Like the charting tool, it lets me set the model and reasoning effort for each step. It sorts the field into large companies and small and mid-size enterprises, because the large ones are usually where the case is, and it hands any candidate to ClaimChart with one click. ClaimChart charts the defendant I know about. Target Finder finds the defendants I do not.

Here are a couple of screenshots from the Target Finder (not at the top left that "Target Finder" is highlighted in royal blue.

Claim Charter + Damages. Claim Charter + Damages does everything ClaimChart does and then writes the damages memo. It performs a reasonable-royalty analysis under 35 U.S.C. § 284 through the Georgia-Pacific hypothetical negotiation, walking all fifteen factors for every patent-by-product pair. For each pair it also addresses nexus and the smallest salable patent-practicing unit and apportions value to the patented feature. It computes the six-year § 286 damages window separately for each patent and treats § 287 marking as a stated caveat, not something folded silently into the number. The memo also covers future damages through patent expiration and a non-infringing-alternative scenario. There is no 25 percent rule and no 50/50 Nash split in the code. The Federal Circuit rejected the 25 percent rule of thumb as a fundamentally flawed tool for setting a baseline royalty rate, and it rejected a Nash-based 50 percent starting point that was not tied to the facts of the case. Revenue comes from SEC filings on EDGAR, including XBRL data, investor-relations pages, and a private database I subscribe to, down to the segment level where the filings allow, with a fallback data waterfall and a currency conversion step for foreign issuers. A model extracts the figures, but the arithmetic stays in code, every source is verified live, every figure is either verified or expressly labeled an assumption, and the totals reconcile before they print. The memo exports to Word, PDF, or HTML with a privilege legend on every page.

Damages Analyzer. Not every damages question arrives with a chart attached, so I split the damages engine into its own tool. It models a matter the way I think about one: a defendant with its SEC identifiers, its patents with dates filled in from the USPTO, its accused products, and a grid of patent-by-product cells. Each cell holds its infringement evidence in three labeled tiers of confidence, from an imported claim chart down to a preliminary technical read, so the memo is candid about what is proven and what is still a contention. An automated test suite runs before anything ships.

CaseFiler. CaseFiler assembles the package. Given the patents, the accused products, and the case facts, it produces what a filing requires in the Eastern District of Texas: internal claim charts, public exhibit charts, a complaint, five supporting filing documents, renamed patent exhibits, and a QA report that scans the package for defects before I open it. The deterministic work, such as formatting, exhibit assembly, and citation and quality scans, is code, so every chart in the package comes out consistent. The judgment work, meaning which limitations to assert, which evidence to cite, and how to frame the complaint, stays with me, written into structured data files the generators consume. The machine guarantees the form. I own the substance.

Section 101. Patent eligibility turns on how courts have applied the two-step framework of Alice, so the law lives in the cases. I downloaded every decision citing Alice Corp. v. CLS Bank Int’l, 573 U.S. 208 (2014), and I built an app that runs a detailed § 101 analysis on any group of patents I feed it. The analysis is grounded in those real decisions, and it draws comparisons to the closest cases, both legally and factually. It runs automatically. And yes, I read the cases. That is how AI in the law works: it has to start with a human and end with a human. In between, AI makes the work easier, and in some cases, makes the work possible for the first time -- leading to a practice where I can spend more of my time on strategy and on playing offense rather than defense.

Behind these sit two builds that never touch a client file. The first is an independent instance of the damages tool wired to a different frontier model and run side by side with the first, so that no output rests on a single model's word. The second is adversarial citation checking, in which one process tries to break the reads another process produced, because a claim chart is only as strong as the weakest citation an opponent can falsify. The rest is plumbing I stood up myself: a web stack, a separate database for each tool, a retrieval layer that grounds the models in real documents, and a scheduler that keeps every tool running and reachable from my devices over a private network. Nothing runs on a third-party legal platform.

The Data Layer: APIs and MCP

The tools are only as good as the data they reason over. AI is usually smart, but a model working from memory will guess at a revenue figure, a local rule, or a statement in a prosecution history, and a guess is not evidence. Accurate determinations and calculations need reliable, actual data, so every tool I build pulls its facts from the source.

Two standards make that possible. An API, or application programming interface, is a published doorway that lets one program request data from another in a structured form: a patent's full text and file history, a company's revenue by segment, a docket entry, a court opinion. MCP, the Model Context Protocol, is an open standard that lets an AI model connect to those data sources and tools directly and decide when to call them; Anthropic released it in November 2024 and has since donated it to the Linux Foundation's Agentic AI Foundation, where OpenAI and Block are co-founders. ChatGPT, Gemini, Microsoft Copilot, Cursor, and Claude all support it. Through API calls and MCP servers, my tools search and scrape websites; find and download public corporate financial data, including data on foreign companies; and pull patent data, case law, court dockets, local rules, and a good deal more. The model does the reasoning. The facts come from the record.

The Studio on My Desk: Local AI and Confidentiality

Much of this work never leaves my office. I run it as local AI on a Mac Studio with an M3 Ultra chip and 512 gigabytes of unified memory.

The memory figure is the reason it works. Running a large language model is mostly a memory problem: either the model's weights fit in fast memory or they do not. On a typical workstation, the graphics card has its own small, fixed pool of memory, and a model that does not fit spills into system memory across a narrow bus, which slows everything to a crawl. Even a top consumer graphics card cannot hold a 70-billion-parameter model in its own memory. Apple Silicon has no separate graphics memory. The CPU, the GPU, and the Neural Engine draw from one shared pool, so nearly all 512 gigabytes can serve the model.

Think of an associate at a small desk who has to keep walking down a narrow hallway to the file room, compared with a team at one very large conference table with every file already spread out. On the Mac, the files are already on the table.

What that buys is concrete. Apple says the M3 Ultra Mac Studio can run large language models with more than 600 billion parameters entirely in memory. That covers open-weight models in the DeepSeek and GLM class, in the range of 670 to 750 billion parameters, running on a desktop. The comparable data-center machine, an eight-GPU NVIDIA DGX H100, is rated at up to 10.2 kilowatts and reportedly costs roughly $300,000 to $450,000. Mixture-of-experts models suit the Mac especially well: the entire model sits in memory, but only the active experts are read for each token, so a 743-billion-parameter model runs at close to eighteen words per second on this machine while a dense model of similar size crawls.

The next step is already announced. Apple's M5 Ultra Mac Studio offers up to 512 gigabytes of unified memory and 1.2 terabytes per second of memory bandwidth, about 50 percent more than the M3 Ultra, with the 512-gigabyte configuration expected in late October. When it ships, I may add one to the bench. On these models, bandwidth is the difference between reading and waiting.

The hardware is not the point. Confidentiality is. When I run a model locally, the prompt, the client's documents, and the model's answer never leave the machine. There is no outside server, no vendor log of what I asked, and no terms of service to parse about retention or training. ABA Formal Opinion 512 warns that a generative AI tool may disclose information relating to a representation to people outside the firm, and it ties that risk to the duty of confidentiality. For the sensitive early work, such as reading a client's confidential technical materials or testing a theory against documents under a protective order, local inference is the cleanest way I know to meet that duty. The frontier cloud models are extraordinary, and I use them where the material is already public: a patent, a defendant's website, an SEC filing. Where the material is not public, the work stays on my desk.

Figure 3. Where the work runs. Confidential material stays on local models; public material can go to frontier cloud models.

The models make this practical. Many of the strongest models outside the closed frontier are released with open weights, meaning anyone with the right hardware can download them and run them with no internet connection at all. Google's Gemma and Meta's Llama families are open-weight, and the leading Chinese labs, including DeepSeek, Zhipu's GLM, Alibaba's Qwen, and Moonshot's Kimi, have released near-frontier models the same way. By one mid-2026 measure, the gap between the best open-weight models and the proprietary frontier had narrowed to six points on Artificial Analysis's intelligence index, down from thirteen a year earlier. That also answers the question I hear most about the Chinese models. When the model runs on my machine and nothing leaves my office, China is not a concern: nothing I type, and nothing the model reads, goes anywhere. Two caveats remain. License terms vary from model to model, and some releases have no independent audit of their weights, so a new model should be tested before it is trusted.

Figure 4. The gap between the best open-weight models and the proprietary frontier on Artificial Analysis's intelligence index. Source: Digiwit (July 13, 2026).

This is the equalizer argument in hardware form. A mid-sized firm can now run a data center's worth of AI on a desk, on terms that keep a client's secrets inside the firm. That capability does not depend on anyone's Trusted Access program.

Building has real costs, and I do not pretend otherwise. It takes time, and someone at the firm has to understand the tools well enough to know when they are wrong. The firm owns its security review, its vendor terms, and its mistakes. OTS platforms have real advantages in return: immediate usability, vendor-managed security certifications, training, and support staff. For a firm with no one willing to learn the development tools, an OTS platform may be the only realistic option. "The only realistic option for firms that will not build" is a very different claim from "the best option," however, and the OTS vendors market themselves as the second.

Bottom line: in a specialized practice, a lawyer who knows the work and can build the tool will usually beat a product built for everyone.

III. The Black Box: Which Model, at What Effort, Behind What Layers

The first structural problem with OTS legal AI is opacity about the variable that drives output quality more than any other: the model, and how hard it is allowed to think.

In many OTS tools, the user cannot determine which large language model is answering the question. Some platforms route queries among several models behind the scenes. Some use a cheaper model for one step of a workflow and a frontier model for another. Some change the underlying model without telling users. A lawyer who does not know which model produced a piece of work cannot know what quality to expect from it, cannot compare it to alternatives, and cannot explain it to a client or a court if asked.

Between the lawyer and the model in an OTS platform sit at least five layers the lawyer never sees: the vendor's system prompt and templates, a routing layer that picks the model, a retrieval layer that decides which chunks of which documents the model receives, a context manager that decides what gets truncated when the input is long, and a reasoning-effort setting. Every one of those layers is a place where quality can be lost.

Context is the layer most likely to bite a patent litigator. Current frontier models accept context windows of up to one million tokens, enough for a patent family, its file histories, and the key prior art in a single request. A platform does not have to use all of it. Long inputs cost more, so a vendor can chunk the file history, retrieve the passages its search layer scores highest, and send the model a fraction of the record. When the passage that matters is an applicant's argument buried in a response to a final office action, and the retrieval layer scores a different passage higher, the model never sees it. The answer will still read as confident.

Figure 5. What sits between a lawyer and the model in a typical OTS legal AI platform, compared with a direct build.

The effort setting deserves particular attention, because most lawyers do not know it exists. Anthropic's API exposes an effort parameter with five levels: low, medium, high, xhigh, and max. Claude Opus 5 supports all five and defaults to high; Claude Opus 5.5 defaults to medium. Anthropic's documentation describes effort as a behavioral signal, not a strict token budget: at lower levels the model still reasons on hard problems, but it reasons less than it would at higher levels on the same problem. OpenAI exposes a comparable reasoning-effort control for its reasoning models, and it published its Astra for Law benchmark at the highest setting.

Table 2. Anthropic's five effort levels (documented guidance, paraphrased)

Level	Guidance
low	High-volume or latency-sensitive work where speed matters most
medium	Balance of speed, cost, and performance; the default on Claude Opus 5.5
high	Complex reasoning where quality outweighs speed or cost; the default on most models, including Claude Opus 5
xhigh	A step above high for demanding coding and agentic work
max	Highest capability, with no constraint on token spending

The practical consequence is concrete. A platform that sends a query to Claude Opus 5.5 without setting the effort parameter gets medium effort by default. A lawyer who picks "Opus 5.5" from a vendor's model menu learns nothing about which of five configurations answered the question.

Even where a platform lets the user pick a model, it does not let the user pick the effort level. The vendors know the setting drives both quality and cost. Harvey's own July 24, 2026 announcement of Claude Opus 5 reported that Opus 5 matched Opus 4.8's max-reasoning performance at lower reasoning levels while generating 26% fewer tokens on average, and that Opus 5 scored 11.7% all-pass on Harvey's Legal Agent Benchmark. The vendor measures effort. The vendor chooses effort. The user does not see the choice.

I have seen the consequence firsthand. In Harvey, selecting Claude Opus 5 as the model delivers work that is noticeably worse, and less accurate, than running the same Opus 5 through a Claude subscription or directly through the Anthropic API. Less accurate here means more hallucinations: fabricated citations, pin cites that drift, and prosecution history statements that do not survive a check against the file. The name on the model picker was the same. The results were not. Something between the model and the lawyer degraded the output, whether the system prompt, the retrieval layer, a context limit, a lower effort setting, or all of them, and the user has no way to see which.

Retrieval-augmented generation does not make those questions go away. In the first preregistered empirical evaluation of commercial legal research AI, researchers at Stanford's RegLab and Human-Centered AI institute found that Lexis+ AI and Thomson Reuters's AI research tools each hallucinated between 17% and 33% of the time, even though their vendors had marketed retrieval as eliminating or avoiding hallucinations. GPT-4 without legal retrieval hallucinated 43% of the time on the same questions. Lexis+ AI gave accurate answers to 65% of queries; Westlaw's AI-Assisted Research gave accurate answers to 41%. The authors' conclusion was blunt: "the providers' claims are overstated." They also said the closed nature of these systems made the claims hard to test in the first place, which is the black-box problem in one sentence.

Figure 6. Hallucination rates of legal research AI tools in the Stanford RegLab/HAI preregistered study (tools tested in 2024). Source: Magesh et al., Journal of Empirical Legal Studies (2025).

Those tools have improved since the Stanford team tested them, and so have the models underneath. The lesson survives the upgrades: retrieval narrows hallucination risk without eliminating it, vendor claims about closed systems need independent testing, and a lawyer who cannot see the configuration cannot run that test.

OTS platforms also lag the frontier. As of this writing, Harvey does not offer Claude Fable 5 or Fable 5.1, or Claude Opus 5.5. A lawyer with a Claude subscription or an API key can use every one of them today.

This is more than an annoyance. It creates unclear standards and unclear expectations for quality. When a partner reviews work product generated in an OTS tool, the partner does not know whether it came from a frontier model at maximum effort or a smaller model at minimal effort, and the vendor's marketing is no help, because marketing describes the best case. The duty of technological competence requires lawyers to keep abreast of the benefits and risks associated with relevant technology. The ABA's Formal Opinion 512 applies that duty to generative AI and makes clear that the lawyer, not the tool, remains responsible for the accuracy of the work. That duty is hard to meet with a tool that will not tell you what it is.

The tools I build have no such ambiguity. The model string is in the code. The effort level is a parameter the user sets. When a model changes, I know, because I changed it.

Bottom line: a lawyer cannot vouch for work product generated by a model he cannot identify, running at an effort level he cannot see, behind layers he cannot inspect.

IV. The Margin Problem: OTS Arithmetic Always Favors the Vendor

The second structural problem is arithmetic, and no vendor can escape it.

An OTS vendor is a business. Its revenue has to cover the compute it buys from model providers, plus engineering, sales, marketing, customer support, security certifications, office space, investor returns, and profit. The investor returns are not trivial: Harvey was reportedly valued at $11 billion in March 2026. By definition, then, the tokens and compute an OTS vendor lets a customer use must cost the vendor less than the price the customer pays. If they did not, the vendor would lose money on every seat it sold.

That has a direct consequence for quality. Every time a vendor lets a user run a frontier model at maximum reasoning effort across a long file history, the vendor's margin shrinks. The incentive is to route to cheaper models, cap context, and set effort lower, and those are the same choices that degrade legal work product. The vendor's interest in margin and the lawyer's interest in accuracy point in opposite directions.

Effort sharpens the conflict. Reasoning is paid for in output tokens, and Anthropic's documentation confirms that the effort parameter affects every output token in the response, including the model's thinking. On Claude Opus 5, output tokens list at five times the price of input tokens. Running every query at maximum effort is therefore the most expensive choice a vendor can make, and lowering effort is the least visible way to protect a margin. The lawyer sees a shorter wait. He does not see the thinner reasoning.

The strongest answer to this is scale. A large vendor negotiates volume pricing, caches repeated content, and spreads its engineering across thousands of customers, so its per-token cost may well be lower than the published rate I pay. That is true, and it does not change the conclusion. Whatever the vendor's cost, the vendor still has to charge more than it spends, and it still decides how much compute each user gets. A volume discount improves the vendor's margin. It does not hand the customer more intelligence.

Tools I build carry no such conflict. I pay the model provider's published rate. Claude Opus 5 lists at $5 per million input tokens and $25 per million output tokens; Claude Fable 5 lists at $10 and $50; batch processing cuts both in half. Table 3 shows what that means for a heavy task, such as a request that reads one million tokens of patents, file histories, and briefing and writes 200,000 tokens of analysis.

Table 3. Compute cost of one heavy task at published rates (1 million input tokens, 200,000 output tokens)

Model and mode	Input, per 1M tokens	Output, per 1M tokens	Cost of the task
Claude Opus 5, standard	$5.00	$25.00	$10.00
Claude Opus 5, batch	$2.50	$12.50	$5.00
Claude Fable 5, standard	$10.00	$50.00	$20.00
Claude Fable 5, batch	$5.00	$25.00	$10.00

At list price, that heavy task costs $10 on Opus 5 and $5 through the batch interface. A reported $1,200 monthly Harvey seat, the commonly cited base rate, would buy 120 of those heavy Opus 5 runs at list, or 240 through batch, every month, for one lawyer. The comparison is not perfect. A seat also buys an interface, support, integrations, and security certifications, and a builder pays for development time. The point is narrower: the customer of an OTS platform buys compute at retail, and the vendor decides the ration. The builder buys it at wholesale and decides for himself.

Figure 7. Heavy tasks (1 million tokens in, 200,000 out) that a reported $1,200 monthly seat would buy at Anthropic's published API rates. Sources: eesel AI (2026); Spellbook (2026).

Figure 8. Reported Harvey per-seat pricing by firm segment (not published by Harvey; figures are industry-reported ranges). Sources: The Legal Prompts (2026); Spellbook (2026).

OpenAI's Astra for Law rollout threatens to make this worse. OpenAI has named Harvey and Legora as API customers that will be able to build on Astra for Law once API access arrives. If the API does not open to firms directly on the same terms, the most practical path to Astra for Law for a firm outside Trusted Access will run through a vendor that adds its own margin on top. The firms with the least capital would pay the most per unit of the newest model.

Bottom line: an OTS vendor must give you less compute than you pay for. A tool you build gives you all of it.

V. Right-Sizing Intelligence: One Model at One Setting Is the Wrong Answer to Every Task

The third structural problem is flexibility. Different legal tasks require different amounts of intelligence and different amounts of reasoning, and treating them all the same wastes either money or quality.

Patent litigation makes the point concrete. Sorting and renaming a document production by Bates range and custodian does not need a frontier model at maximum effort; a fast, inexpensive model at low effort does it well for pennies. Summarizing a deposition transcript with page-and-line citations needs more. Mapping every use of a disputed claim term across the specification and prosecution history needs a frontier model at high effort. Deciding whether a statement in the prosecution history amounts to a disclaimer or an estoppel that forecloses a doctrine of equivalents theory, or testing an obviousness combination against the full text of the references, needs the strongest model available at its highest effort. The cost of that run is trivial compared with the cost of getting it wrong.

Table 4. Matching model and effort to patent litigation tasks (illustrative)

Task	Model tier	Effort	Why
Sorting and indexing a production by Bates range and custodian	Small, fast	Low	Mechanical; errors are easy to spot
First-pass extraction of claim limitations into a chart template	Mid-tier	Medium	Structured, repetitive, checkable
Deposition summary with page-and-line citations	Mid-tier or frontier	Medium to high	High volume; citations must be right
Mapping a disputed term across the specification and file history	Frontier	High	Long, subtle intrinsic record
Disclaimer and prosecution history estoppel analysis	Frontier	xhigh or max	Case-dispositive; one missed statement can decide it
Testing an obviousness combination against full reference text	Frontier	max	Careful reasoning across several long documents
Final citation and quotation verification	Frontier plus a deterministic check	High	Every cite confirmed against the source before filing

The applications I build let the user choose, for each task, from a large number of models across price and intelligence tiers, and from every effort level each model supports. A simple task goes to an inexpensive model at low effort. A hard one goes to the strongest frontier model available at maximum effort. The user sees the choice and owns it.

Choosing well requires measurement, and measurement is a skill any firm can build. The method is not complicated. Assemble a set of non-privileged tasks drawn from real matters, with answers the firm already knows are right: a claim term with a settled construction, a file history with a known disclaimer, a prior art combination that a court has already addressed. Run each task across several models and effort levels. Score the outputs for accuracy, completeness, and citation fidelity, and record the cost of each run. After one round, the firm knows which configuration to use for which kind of work, and it knows it from its own data instead of a vendor's slide. OTS platforms do not let a customer run that experiment, because the customer cannot change the variables.

OTS tools do not offer this. They pick one model and one effort setting, or a hidden routing scheme, for each workflow, and every user gets the same configuration regardless of how hard the task is. That is inefficient in both directions. On easy tasks, the customer pays, through the seat price, for more intelligence than the task needs. On hard tasks, the customer gets less intelligence than the task needs, because the vendor cannot afford to run every request at maximum effort for a flat fee. Either way, measured as compute per dollar, the OTS tool is effectively more expensive.

Bottom line: matching the model and the effort level to each task is the largest efficiency gain available in legal AI, and OTS tools do not give it to you.

VI. Patent Litigation: Where Attrition Meets AI

Patent litigation is the clearest example I know of the asymmetry between the largest firms and everyone else, and it is getting busier. Plaintiffs filed 4,547 patent cases in federal district courts in 2025, a nearly 20% increase over 2024 and the highest level in a decade. The Eastern District of Texas received 1,069 new patent cases in 2024, about one in five nationwide, and Judge Rodney Gilstrap was assigned 795 of them. At the same time, PTAB activity has fallen sharply: only about 200 petitions were filed in the first half of 2026, fewer than in any half-year in at least a decade. More of the fight is in district court, which is where cost and endurance decide the most.

The costs are large, and they fall on both sides. AIPLA's 2023 economic survey put the median cost of litigating a patent case through trial and appeal at roughly $600,000 when less than $1 million is at stake and $3.625 million when more than $25 million is at stake. AIPLA's 2025 survey, as quoted in a recent Supreme Court amicus brief, reported a median of about $355,000 for an inter partes review through hearing, and district court fees of more than $3.5 million when significant value is at risk and $4 million when the patent holder is a non-practicing entity.

Figure 9. Median patent litigation and IPR costs reported in AIPLA's economic surveys. Sources: AIPLA Report of the Economic Survey 2023 and 2025, as quoted in public filings.

Much of my practice puts me across the table from some of the largest technology companies in the world, represented by AmLaw firms with teams several times the size of mine. Those defendants can afford to file IPR petitions, move to transfer, serve sweeping discovery, and litigate every claim construction dispute to the end. Their strategy is often to make the case too expensive for the patent owner to finish.

AI changes the math of that strategy. A lawyer with the right tools can review a prior art production against the asserted claims, map the intrinsic record for claim construction, draft infringement contentions from technical documentation, and prepare for the deposition of a defendant's technical expert at a speed that used to require a team. The quality depends on the tool, and the tool depends on the model, the effort, and the design. That is why Parts III through V matter so much to a firm like mine. An OTS tool that silently runs a weaker model at lower effort on the one invalidity analysis that decides a case is not an efficiency. It is a risk.

There is a second reason patent work resists one-size-fits-all tooling. Much of the analysis in a patent case is not legal research at all. It is technical evidence: product documentation, source code, standards specifications, datasheets, teardown reports, and the defendant's own engineering documents, read against claim language element by element. Astra for Law's advantage is a legal search index. That index does nothing for a claim chart built from a chipset datasheet or a networking standard. The tools that move the needle on that work are pipelines designed around the evidence, the claim language, and the chart format a particular court and a particular client expect. No general legal platform will build that pipeline for a mid-sized firm. The firm has to build it.

Verification is the other half of the equation, and the stakes are rising fast. Damien Charlotin's AI Hallucination Cases database, which lists only decisions in which a court found or clearly implied that a party relied on hallucinated material, had 87 entries in May 2025. It now lists 2,077. The first widely reported sanction, Mata v. Avianca, came in June 2023. Courts have since moved from four-figure fines to five-figure sanctions and bar suspensions.

Figure 10. Cumulative court decisions in Damien Charlotin's AI Hallucination Cases database. Sources: Charlotin database; counts as reported by Volokh Conspiracy, Voibe, PlatinumIDS, HAQQ, and LegalAI Space on the dates shown.

The rule that follows is simple. Every AI output is a draft until a lawyer has checked every citation and every quotation against the source. A tool built for a specific practice can enforce part of that rule in code. An OTS tool leaves all of it to the lawyer, and, as Part III showed, it does so without telling the lawyer how the draft was made.

That is also why the Astra for Law rollout matters to me personally. The large firms on the other side of my cases are the firms most likely to have Astra for Law first, through Trusted Access today and, once the API opens, through the OTS vendors they already use. My firm, at least for now, does not have it. OpenAI has handed the side with the most resources one more resource.

For small and mid-sized firms generally, three lessons follow.

First, do not wait for a vendor or a frontier lab to decide you are important enough. The tools to build your own AI workflows exist today, and they cost a fraction of an enterprise license.

Second, demand transparency. For any AI tool you use, know which model produced the work, at what effort, what retrieval it relied on, and what happens to your client's data. If a vendor will not tell you, that is your answer.

Third, match intelligence to the task. Pay for frontier-level reasoning where it counts, which in patent litigation is often, and stop paying for it where it does not.

Bottom line: for a mid-sized patent litigator, building my own AI is how I stay even with opponents who have far more lawyers and far more money.

VII. The Through-Line

The through-line is simple. The software does the labor that is mechanical and repeatable. The data layer keeps it grounded in the record. The hardware keeps confidential work confidential. I do the judgment. None of those pieces pretends to be any of the others, and that is the point.

AI in the law has to start with a human and end with a human. What happens in between is where these tools earn their place: charts that would have taken a team a week, damages analysis with every figure traced to its source, and a practice that can spend its time on strategy and on offense. A mid-sized firm does not need anyone's permission to build that.

The machine guarantees the form. I own the substance.

About the Author

Erick S. Robinson is a patent litigator and helps lead AI issues at his firm. He writes and hosts a podcast on patent enforcement, litigation funding, and the use of frontier AI models in specialized legal practice, and he builds his own practice tools. He is on LinkedIn at https://www.linkedin.com/in/erickrobinson/.

Sources

• Erick S. Robinson, The Great Equalizer, Reserved for the Already Equal, AI Law Blog (2026)

• OpenAI, Introducing Astra for Law (Sept. 17, 2026)

• OpenAI Releases Astra for Law, a GPT-6 Model Tailored for Legal Work, Targeting Large Firms and Tech Vendors, LawSites (Sept. 2026)

• Rama Adi Nugraha, Claude Opus 5 vs Fable 5: Which Should You Actually Run?, eesel AI (July 27, 2026) (reproducing Anthropic's published model specifications and pricing)

• Georgia-Pacific Corp. v. U.S. Plywood Corp., 318 F. Supp. 1116 (S.D.N.Y. 1970)

• Uniloc USA, Inc. v. Microsoft Corp., 632 F.3d 1292 (Fed. Cir. 2011)

• VirnetX, Inc. v. Cisco Systems, Inc., 767 F.3d 1308 (Fed. Cir. 2014)

• Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014)

• Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.md, Linux Found. (Dec. 9, 2025)

• Anthropic, Donating the Model Context Protocol and Establishing the Agentic AI Foundation (Dec. 9, 2025)

• Apple, Apple Reveals M3 Ultra, Taking Apple Silicon to a New Extreme (Mar. 5, 2025)

• NVIDIA DGX H100 specifications, Hydra Host (last visited Sept. 26, 2026)

• DGX H100 Price 2025: Complete Guide to NVIDIA's Flagship AI GPU, Cyfuture Cloud

• Apple, Apple Introduces New Mac Studio with M5 Max and M5 Ultra (Aug. 25, 2026)

• Mac Studio M5 Ultra: 512GB Memory and Thunderbolt 5, Fstoppers (Aug. 26, 2026)

• ABA Comm. on Ethics & Pro. Resp., Formal Op. 512, Generative Artificial Intelligence Tools (July 29, 2024)

• The Best Open-Weight Models in 2026, Ranked, Digiwit (July 13, 2026)

• Best Open-Weights AI Models for Business (2026), Layer3 Labs (2026)

• Anthropic, Effort, Claude Platform Docs (last visited Sept. 25, 2026)

• Harvey, Claude Opus 5, Now Live in Harvey (July 24, 2026)

• Varun Magesh et al., Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools, J. Empirical Legal Stud. (2025)

• What the Science Says About Hallucinations in Legal Research, AI Law Librarians (Feb. 19, 2026) (summarizing Magesh et al.)

• Varun Magesh et al., Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools (preprint, updated), arXiv:2405.20362

• Am. Bar Ass'n, Model Rules of Pro. Conduct r. 1.1 cmt. 8

• Harvey AI Pricing 2026: Per-Seat Cost and the Renewal Increase, Vaquill (June 20, 2026) (citing CNBC, Mar. 25, 2026)

• Harvey AI Pricing: Complete Breakdown for 2026, Spellbook (2026) (reporting a base rate of approximately $1,200 per seat per month and a minimum of approximately 20 seats)

• Lex Machina, Patent Litigation Trends (discussing the Lex Machina 2026 Patent Litigation Report), LexisNexis (2026)

• Report: Judge Gilstrap Again the King of Patent Litigation, Texas Lawbook (2025) (reporting Lex Machina data)

• Am. Intell. Prop. L. Ass'n, Report of the Economic Survey 2023, at I-148, I-152, as quoted in Jeff Hardin, Comments in Response to FR Doc. 2025-19580 (Nov. 4, 2025)

• Am. Intell. Prop. L. Ass'n, Report of the Economic Survey 2025, at 33, 36, 40 (2026), as quoted in Brief of Amicus Curiae, No. 25-1230 (U.S. filed May 29, 2026)

• Eugene Volokh, "AI Hallucination Cases," from Courts All Over the World, Volokh Conspiracy (May 18, 2025)

• Damien Charlotin, AI Hallucination Cases Database (2,077 cases listed as of Sept. 2026)

• Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023) (opinion and order on sanctions)

• AI Hallucination Legal Cases: A Sanctions Tracker (2026), GC AI (Aug. 12, 2026)

• AI Hallucinations in Law Firms: What Lawyers Must Know (2026), Voibe (Apr. 24, 2026)

• 1,227 Fabricated Citations and Counting: Inside the AI Hallucination Crisis Hitting Courts Worldwide, PlatinumIDS (Apr. 2, 2026)

• AI Hallucination Cases: The 1,598-Case Sanctions Tracker, HAQQ (June 11, 2026)