NV-Reason-CT vs Claude Opus 5: A Category Error Worth Taking Seriously

Putting NV-Reason-CT and Claude Opus 5 in the same sentence is a category error, and it is worth doing anyway, because the error is instructive. NV-Reason-CT is a 4.69-billion-parameter native 3D vision-language model from NVIDIA that takes a chest or abdominal CT volume in Hounsfield units and produces a structured finding-by-finding write-up. It is not a medical device and its own model card says so. Claude Opus 5 is the vendor's general frontier text and vision model, released on 24 July 2026, with a one-million-token context window, a 128,000-token output ceiling, and a published rate of five dollars per million input tokens and twenty-five per million output. One of these reads a CT. The other reads everything else.

The reason the comparison keeps getting made — and it will, every time someone sees a new medical VLM and reaches for a familiar yardstick — is that both produce prose about an image. That surface similarity is doing real damage to how people reason about the two, so it is worth unpicking in detail.

The actual axis they share, and the one they do not

They overlap in exactly one place, and it is narrower than it looks.

• Modality in — NV-Reason-CT takes one-channel NIfTI volumes in Hounsfield units through a dedicated three-dimensional processor; Claude Opus 5 takes text, images and files, which is a second-generation interface for pictures and cannot natively ingest a volumetric CT study

• What comes back — a finding list organised by anatomical region from NV-Reason-CT, against general prose, structured JSON or tool calls from Claude Opus 5

• Units of work — one CT volume, resampled to 2 mm isotropic, cropped to anatomy, cut into 8 x 8 x 8 patches; against whatever you put in a token budget

• Context — NV-Reason-CT has no chat window at all; a single volume becomes 13,824 visual tokens with no downsampling. Claude Opus 5 holds 1,000,000 tokens in and emits up to 128,000

• Licence — OpenMDW-1.1, a downloadable model you run on your own hardware; against a hosted API

• Stated use — research and education only, explicitly not a medical device, for NV-Reason-CT; against general-purpose assistance for Claude Opus 5

• Price — no list price, because there is nothing to buy, only weights to run; against $5 and $25 per million tokens, with cached reads at $0.50

The "modality in" row is where the category error is born. Both accept an image, so both look like image models, and a reader reasonably asks which is better at images. But a CT study is not an image. It is a volumetric array with a physical scale in millimetres, a calibrated density unit, and anatomy that only means anything in three dimensions. Claude Opus 5's vision is genuinely capable and it will discuss a radiograph or a pathology slide sensibly. That is a different task from integrating a 384-millimetre cube of Hounsfield values at 2 mm resolution and reporting on a nodule's lobulation.

What the numbers on each side actually measure

The two models have benchmark records that never touch, and reading them side by side without noticing that is how bad procurement decisions get made.

NV-Reason-CT reports its results on the CT-RATE public chest-CT benchmark, across eighteen labels, using a fixed uniform threshold and a direct yes/no prompt with no classification head and no task-specific adaptation. It posts 0.614 F1 and 0.871 AUROC, ahead of VoxelFM at 0.581 and 0.870, Pillar-0 at 0.544 and 0.861, ClinFusion-8B at 0.442 F1, CT-CLIP at 0.398 and 0.733, Merlin at 0.358 and 0.662, and MedGemma 1.5 at 0.303 F1 when given up to 85 axial slices. There is also a report-derived macro-F1 of 0.592. Every one of those figures comes from NVIDIA's own paper. None has been reproduced by anyone else, and the model has been downloadable for a few weeks.

Claude Opus 5's record is a general-purpose one and largely independent. Artificial Analysis measures it at 50.8 on its Intelligence Index, 78 on its Coding Index, 93.2 on GPQA Diamond and 54.9 on Humanity's Last Exam, with a long-context recall score of 79.33. Those are third-party numbers on general reasoning, code and knowledge tasks. There is no clinical imaging benchmark in that set, and there is no CT-RATE row anywhere in Claude Opus 5's published record.

So the honest statement is not that one is ahead. It is that the two models have never been measured on the same task by anyone. Any sentence of the form "NV-Reason-CT is better than Claude Opus 5 at medical imaging" is unfalsifiable as written, because nobody has run the experiment. NVIDIA's own comparison table contains no general frontier model.

Where people get the interface question wrong

The one genuinely interesting technical overlap is the one nobody argues about: what an interface between a CT model and a text model should look like.

A reasonable instinct is to feed Claude Opus 5 a set of CT images or a downsampled volume and ask it to reason. At 1,000,000 tokens of context that sounds generous, and against a study that is only 13,824 visual tokens it sounds like plenty of room. The room is not the problem. Claude Opus 5's vision pipeline treats an image as a two-dimensional picture with a pixel scale. A chest CT presented that way loses the inter-slice spacing that makes a lesion measurable and the density calibration that makes "ground-glass" a threshold rather than a description. You can hand it a montage of axial slices and get a coherent-sounding paragraph. What you cannot get is a measurement.

That is precisely what NV-Reason-CT's design spends its compute on. The 24 x 24 x 24 grid from a 384-millimetre volume is handed to the language model at full resolution, with no spatial downsampling and no merging layer, which is why the active pathway is 4.35B parameters rather than something much smaller. The architecture is a bet that keeping spatial detail is worth the token cost. It is a bet about representation, not about language ability, and Claude Opus 5 is not a participant in it.

The productive pattern is the boring one: use the CT model for the volumetric read, and use a text model for everything around it. Report generation and normalisation, cohort summaries, evaluation harnesses, converting DICOM archives to NIfTI at scale, triaging which studies a human should look at first. That is long-document and code work, and it is where a 1M-context model earns its rate.

Cost, in two units that do not convert

Claude Opus 5 is metered. Five dollars per million input tokens and twenty-five per million output, cache reads at fifty cents, cache writes at ten dollars. For a pipeline that normalises a corpus of reports or writes and re-writes evaluation code, that produces a forecast you can build: tokens in, tokens out, cached reads, and a much cheaper bill if you get the caching right.

NV-Reason-CT has no price. You download 4.69 billion parameters and pay in electricity, GPU hours and engineering time. There is no published throughput figure for a full 13,824-token study, and no quantised variant on offer, so the per-study cost of running it is a number you would have to measure yourself. That is normal for research weights and it is also the single biggest practical difference between the two: one has a rate card, the other has a bill you cannot see until you have already paid it.

The comparison that actually matters is per study, not per token. A CT read is one unit of work. A report-normalisation pass over the same case is a text job measured in thousands of tokens. Putting a dollar figure on the first means knowing your hardware; putting one on the second is arithmetic.

The trap in the middle of the comparison

There is a specific mistake worth naming, because it is the one that this matchup invites. It is treating NV-Reason-CT as a specialist fine-tune of a general model, and therefore assuming the general model will be close enough on most cases and much more flexible.

It is not a fine-tune. It is a 3D vision transformer called Primus, initialised from COLIPRI, bolted to a Qwen3.5-4B language backbone with 3D multi-axis rotary position embedding, trained on roughly 550,000 structured question-answer examples drawn from 70,111 CT volumes across CT-RATE, CancerVerse and an internal NIH collection, and then tuned with GRPO against a reward that weights abnormality-set F1 at 2.0, a region-specific report-structure score at 0.5 and a soft length penalty at 1.0. The three-dimensional encoder is the point of the model. A two-dimensional or slice-based front end is a different instrument, and the paper's own comparison shows what that difference is worth: MedGemma 1.5 at 0.303 F1 when fed up to 85 axial slices, against 0.614 for the native volumetric model.

The inverse mistake is equally common and just as expensive: assuming that because NV-Reason-CT is specialised, you should use it for everything clinical. It supports chest and abdomen and nothing else, its invocation is a NIfTI file rather than a chat message, and its licence terms say research and education only. It will not read a pathology slide, answer a question about a guideline, or write the code that batches your DICOM conversion. Reaching for a CT model to do text work is the same category error as reaching for a text model to do volumetrics, just pointing the other way.

How the two halves fit in one system

Neither model replaces the other, and the sensible architecture contains both — which raises the practical question of how you call them.

Claude Opus 5 is served through OrcaRouter as anthropic/claude-opus-5 at Anthropic's provider list rate with zero markup, inside a single API covering more than 200 models. That matters less for a single call than it does for the surrounding pipeline: when the text half of a clinical build is one model among several candidates, having them all behind one key means you can compare them on your own corpus without a second contract or a code change, and the routing DSL lets you send individual requests to the model that should handle them while automatic failover covers you when a provider degrades.

NV-Reason-CT is not on our platform, and no NVIDIA model is. It is weights you download and run on your own hardware, which is exactly what the licence lets you do and, given that the input is patient-derived volumetric data, is probably what you want anyway. We are not going to imply we route a model we do not host. The text side of the build is where we are useful; the volumetric side is where you are on your own with a 4.69B model and a GPU.

The verdict that survives scrutiny

If you need a CT volume read into structured findings, there is a model for that, it came out of NVIDIA's research group, and it is a download rather than an API call. If you need a corpus of reports normalised, an evaluation harness written, a DICOM conversion job scripted, or a cohort summarised, there is a model for that too, and it has a rate card.

The line to hold is that neither has been demonstrated to be better than the other at anything, because the experiment has not been run. What has been demonstrated is that a native three-dimensional interface beats a slice-based one on a public chest-CT benchmark by a margin the authors put at about three F1 points, and that a general frontier model is independently measured at the top of the field on reasoning, code and long-context work. Those are two statements about two different jobs. Reading them as a ranking is the category error, and it survives right up until someone publishes the head-to-head that nobody has published yet.