Opus 5 vs Qwen 3.8 on a 5090: re-fighting Apple's dead pinch-to-zoom patent
While writing this I listened to another work on repeat: Beethoven's Violin Sonata No. 9, the "Kreutzer" - Martha Argerich again, this time not with Kremer but with Vadim Repin. The third movement fits this post: it is itself a fight between violin and piano, on equal terms. The second is the calmer companion while you read (Apple Music · Spotify). And if you have fifteen spare minutes - who has those - close your eyes and start with the first; I find this recording one of the best. The work does not open up easily. I had to hear it many times before I learned to love it.
This post is several fights at once. Apple's "pinch to zoom" patent against a touch-table patent from 2005. A desk-side RTX 5090 running Qwen3.8 against Claude Opus 5. The self-hosted stack against the hosted one. And, at the end, both machines against the humans who actually decided the case. The referee is reality: the patent's fate is public record, down to the signed certificate, so nobody has to take anybody's word for who analyzed it well. (In a hurry? The honest answer is at the end.)
The case
US 7,844,915 is popularly the Apple pinch-to-zoom patent, though the name is a misnomer: claim 1 is the heuristic that reads one finger as a scroll and two or more as a gesture. The prior art is US 7,724,242 (Hillis), a touch-table patent filed in 2005 - one finger pans, two spreading fingers zoom, inertia and friction included.
What the models were not told: this fight already happened. A reexamination requested in 2012 ran eight years, through the Board twice and the Federal Circuit once, and ended in a certificate whose operative text is one line - "Claims 1-21 are cancelled." Nothing survived. That record is the answer key. The question is not whether a model can look up how the story ended; it is whether, given only the patent, the prior art and the tools, it finds the reasons the patent died.
The setup, in three sentences
Both models reached the live patent offices through the same tool server, my Patent Connector - so both worked from identical data. You can run this three ways: everything hosted; your own tooling server with a frontier model on top (accounts, credentials and the research trail stay yours - the setup I see growing fastest and worth it if you care about where a tool call actually goes); or everything on your own metal, which is the configuration this post stress-tests. Fully local is the one everyone asks about, and the honest framing is: it is what we would all love to run, the quality is closer than you think, and a single 5090 makes it a practitioner's box rather than a firm's - more or bigger cards fix that, a fact of budget rather than physics.
The box itself: Qwen3.8 27B at 6-bit quantization, about 60-70 tokens per second, 64k context, entirely in GPU memory. One hard-earned note for anyone reproducing this: getting honest behavior out of a local model is an operational skill. My favorite example - the temperature slider in the chat front end silently never reaches the model on Ollama's OpenAI-compatible path; sampling has to be baked into the model file. "Why does my local model feel dumber than the benchmarks" is usually a settings story, not a model story.
The test
Two phases. Phase one is blind: analyze the '915's validity over Hillis using only the connected tools - web search off, and an explicit instruction not to touch reexamination, PTAB or litigation records. That instruction is verifiable, not aspirational: every tool call lands in the logs, and all six runs - three per model, fresh chats - stayed clean. Claude ran at medium reasoning effort so thinking time roughly matched the local box (three to four minutes a run against about two). Phase two is the reveal: pull the actual record through the connector and self-grade.
One disclaimer that matters: the prompt is not how a patent professional would brief this question. It is a test harness in prose - just enough instruction to force claim charts, a construction discussion and the tool calls that make the result worth reading. It also hands the models the killer reference: Hillis is the prior art reality chose, so finding the art was never part of the test. A real engagement would start from a better question and a much longer method - more on that below.
What both models found
Here is the striking part: all six runs, both models, independently found the structure that really did kill this patent. The '915's only distance from Hillis is software-architecture vocabulary - "event object," "call," "window having a view" - plus one stop-position clause in claim 1. Read those terms the way examination reads them, at their broadest reasonable interpretation, and they collapse onto Hillis. Read them the way litigation reads them, and the patent breathes. Every run built that fork correctly, with verbatim claim charts on both sides of it.
The difference was what each model did standing at that fork. Claude walked through it, three times out of three: all independent claims likely invalid, claim 8 the weakest, and in one run the cleanest formulation of the whole corpus: the patentee is squeezed, because the broad construction loses on anticipation and the narrow one on obviousness. One Claude run did real legwork: checked the citation record and noticed Hillis had never been in front of the original examiner, searched out two secondary references and quoted them, and declined to use Apple's own prior art for the combination on a common-ownership technicality most engineers have never heard of.
The local Qwen found the same fork and flinched. In two of three runs it concluded claim 1 "likely not invalid" on the narrow reading - one run labels the claim not-invalid directly above its own "~55% invalid" estimate - and its combination theories stayed generic where Claude's named documents. Same cliff, different nerve.
What the record says
Then I opened the file, and the record humbled everyone - me included. The lead rejection was anticipation by Hillis alone - the aggressive theory most runs had filed as a fallback. A second, fully independent family of grounds (a Japanese publication plus a 1991 CMU gesture-recognition paper neither model surfaced) stood ready in case Hillis fell. And the fight that decided the independent claims - the one that drew a stack of Apple expert declarations - was over none of the limitations the models agonized about. It was a grammar fight: whether "distinguishing between a single input point... and two or more input points" is satisfied by a reference that handles exactly two. The examiner read "two or more" as alternatives, the Board and the Federal Circuit agreed, and that construction cancelled the patent.
Every single run, both models, had concluded that limitation was met - a few noted an inherency wrinkle, none treated it as more - and spent their doubt elsewhere. The models read the claim like engineers, hunting the technically weak element. The case was decided like a legal text. Nobody - and I checked every transcript - saw the battleground coming.
Which also answers the objection a careful reader should raise: is this famous case simply in the training data? The blind protocol controls what the models could look up, not what they might remember, and the appellate decisions are published - so memorization cannot be excluded. But a model reciting the record would have led with anticipation over Hillis alone, named the second art family, and known the "two or more" fight - the headline of the very documents it would be remembering. Across six runs: one filed anticipation first and still called obviousness the stronger theory, none surfaced the second art family, none saw the construction fight, and the local model concluded "not invalid" twice. The misses that cost them points are also the best evidence the reasoning was earned, not recalled. The examiner also made a lawyer's move neither model made: beyond construing the disputed terms, he read the specification for what it fails to say, found no algorithm for the distinguishing step and not even the word "distinguishing," and concluded the claim cannot demand a specific mechanism it never describes.
Claude's own post-reveal audit is worth quoting, because no score carries the point as well: "I priced three claims as materially different risks when they were one risk." And, on seeing the procedural posture it had underweighted: a granted reexam, requested by a well-resourced litigant, on art the original examiner never saw - "that fact pattern does not resolve at 55%." The local model never got to write its own audit, for a reason covered below.
Could the models have done better? Probably - and the fix is instructive. The connector serves the examination manuals (the MPEP among them) as tools; nobody told the models to consult them, and none did. Add that line to the prompt. Then add the next lesson: check disjunctive constructions. Then the base rates of granted reexams. Each fix is one more line, and the prompt converges on something that already exists - the training of a patent professional. The models execute the method astonishingly well. Someone still has to know it, write it down, and catch the run where it fails.
Where the small local stack breaks
Phase two split the stacks, and not on intelligence. Claude worked through the eight-year scanned record end to end, three runs, reconstructing the same six rejection grounds each time. The local box never got to start, and a minimal two-page probe pinned down why - two walls, neither of them the model. First wall: the front ends. Onyx never shows the model tool-returned images at all - it strips them, and Qwen, to its credit, reported plainly that it could not see the pages rather than inventing them. AnythingLLM forwards them - as raw base64 text, ballooning two scanned pages into 187,000 tokens the vision encoder never sees. No card fixes this wall - a bigger context would let the base64 fit, not make it readable; it is a software bug waiting on the harness projects. Second wall: even image-blind, a long prosecution record crowds a 64k window. That one is a sizing choice - the same model runs at several times that context given the VRAM, which is to say a bigger card or a second one. On the single-5090 box tested here, "read the whole record and tell me what happened" is a frontier-model feature. On a larger local box it is a purchase order.
The honest answer
Can a desk-side box do serious patent analysis? On the evidence of this test: yes, genuinely - it found, blind, the construction fork a professional would bill for finding, and it never fabricated what it could not see. What still separates the stacks is specific, not vague: steadiness at the decision boundary (the local model flipped its claim-1 verdict under pressure; Claude never did), unprompted investigative legwork, and the context capacity for record-heavy work. And one thing separates neither: both models missed where the lawyers would actually fight. The reviewing professional is not a transitional arrangement until the models improve. On this evidence, the human in the loop is the part of the system that knows which fight it is in.
Method, briefly
Blind two-phase protocol, 2026-08-23, Patent Connector 1.10.0 on both stacks. Local: Qwen3.8 27B (qwen3.8:27b-q6_K) at 64k context on one RTX 5090, Onyx front end; sampling pinned in the model file (temp 0.6 / top_p 0.95 / top_k 20). Frontier: Claude Opus 5 on claude.ai at medium reasoning effort, web search off. Three fresh-chat runs per model per phase; blindness verified from the tool-call logs. Grading: a fixed rubric applied against the record itself - the certificate and the adopted rejection grounds, retrieved and read through the same tools under test. Phase two on the local stack terminated on context overflow (~123k tokens needed vs ~58k available after prompt overhead); treated as a finding, not excluded. Raw transcripts, scorecard and probe logs are available on request.
