Bulk scanning is the workload where cost-per-call matters most. A large engineering org with hundreds of repositories and thousands of components can easily produce tens of thousands of findings a day, and using an expensive model on every one of them would be wasteful. Claude Haiku is Anthropic's fastest and cheapest model, and it's the engine Griffin uses for the high-volume, shallow-reasoning pass over incoming scan results.
Because Griffin uses Haiku under the hood for this layer, the comparison here isn't Griffin against Haiku. It's what happens when you call Haiku directly for bulk scanning versus what happens when Griffin's pipeline calls Haiku for you with the surrounding context, routing, and escalation logic.
The Shape Of Bulk Scanning
Bulk scanning is not triage. Triage is the careful, decision-making layer that assigns each finding to a fix path. Bulk scanning is the layer just before that, where raw scanner output gets turned into structured, deduplicated, pre-classified findings that a triage layer can then reason about.
A typical bulk-scanning task looks like this. Your SCA tool has produced a JSON blob with a vulnerable component, its version, its transitive chain, and a CVE reference. The scanner's output is accurate but noisy: it doesn't tell you whether the vulnerable function is actually imported, it doesn't explain the CVE in plain language, it doesn't deduplicate against findings you've already seen, and it doesn't classify severity against your organization's policies.
Bulk scanning turns the raw scanner output into something triage-ready. It's a lot of small, similar tasks. That's exactly the shape of work where a fast, cheap model shines.
Haiku On Its Own
Haiku is genuinely good at this kind of work. Its strengths are speed, low cost, and a remarkable ability to follow structured output instructions. Ask Haiku to produce JSON with specific fields and it reliably does, with far fewer format errors than you'd expect given its speed.
For a single scan result, raw Haiku will produce a clean summary, classify severity, suggest the likely fix, and flag obvious false positives. It handles the shape of the task well.
The limits of raw Haiku are visible in two places. First, Haiku doesn't reason as deeply as Sonnet or Opus. For the small percentage of scan results where the right classification requires genuine analysis — unusual advisory text, complex transitive chains, ambiguous reachability — Haiku will still produce an answer, but the answer will be shallower and sometimes wrong. Second, Haiku has no context beyond what's in the prompt. If you want it to deduplicate against previous findings or apply your organization's policy classifications, you have to supply that context every time.
Haiku Inside Griffin's Bulk Pipeline
Griffin's bulk-scanning pipeline is the layer where the cost-speed calculus matters most, and it's built around two ideas: use Haiku for the easy majority, and escalate to Sonnet or Opus only for the cases that actually need it.
The pipeline starts with Griffin pulling the raw scan results and batching them efficiently. For each finding, Griffin constructs a prompt that includes the finding, the relevant tenant context — prior findings on the same component, policy classifications, reachability data — and a structured output schema.
Haiku processes the batch. For most findings, Haiku produces a clean, structured result: a plain-language summary, a severity classification aligned with the tenant's policy, a deduplication decision, a fix suggestion, and a confidence score.
Griffin then inspects Haiku's output. When Haiku's confidence is high and the structured result passes the grader checks — valid CVE, resolvable package coordinates, plausible fix path — the finding flows straight into the triage queue. When confidence is low or a grader flags a problem, Griffin escalates the finding to Sonnet, and from there potentially to Opus if Sonnet also struggles.
This tiered approach is the real point of Griffin's bulk layer. Raw Haiku alone gives you Haiku-quality reasoning on every finding, which means the hard cases get shallow answers. Griffin uses Haiku when Haiku is enough and quietly upgrades to more capable models when it isn't — so the ninety-plus percent of findings that are routine run at Haiku cost, and the few percent that are genuinely hard get the reasoning they deserve.
The Cost Story
Cost is where the difference shows up most clearly. Running the entire scan firehose through Opus would work but would be prohibitively expensive. Running it through Sonnet would be better but still wasteful on the routine cases. Haiku on everything is cheap but leaves the hard cases poorly handled.
Griffin's tiered routing gets you the best of the three. The average cost per finding is close to Haiku's sticker price, because Haiku handles the overwhelming majority. But the findings that matter — the ones where a shallow classification would lead to a bad triage decision — get quietly upgraded to a more capable model without the user having to think about it.
Teams that try to build this tiered routing themselves on top of the raw APIs can absolutely get there, but it's not trivial. The routing rules, the confidence thresholds, the grader logic that decides when to escalate — those are real engineering, and they're what Griffin is doing under the hood.
Where Raw Haiku Makes More Sense
For small-scale, ad hoc scanning of a single repository or a single package, raw Haiku with a well-crafted prompt is efficient and hard to beat. You don't need a pipeline for ten findings. Haiku via the API will give you a clean classification in a few seconds per finding, at a cost that rounds to zero.
Raw Haiku is also the right choice when you're prototyping a custom scanning workflow that doesn't match any standard shape. Griffin's pipeline assumes you want findings in its data model, routed through its triage queue, and surfaced in its UI. If you're building something different — a custom report, a specific integration, a one-off analysis — using Haiku directly lets you shape the output however you want.
Where Griffin's Haiku Pipeline Wins
For recurring, high-volume, cross-project scanning, Griffin's pipeline is doing a lot of work that isn't visible from the outside. Deduplicating findings across tenant history, aligning severity to your policies, escalating the hard cases, writing durable records to the findings store, notifying the right integration when something crosses a threshold — all of that is machinery that turns raw scan output into an operational signal.
The honest framing is that Griffin's bulk-scanning layer is Haiku applied to a very specific job with a lot of surrounding infrastructure. The model is the same. The reasoning quality on any individual finding is roughly the same. What's different is that Griffin is running that reasoning against context Haiku alone doesn't have, routing it through a tiered escalation you'd otherwise have to build, and landing the results in a system that remembers everything it's seen.
When your volume makes that machinery worthwhile, Griffin earns its keep. When your volume is small or your workflow is truly custom, Haiku on its own is already a genuinely useful tool, and you may not need the scaffolding at all.