So I am setting up a local intranet for my extended family to use (file sharing, media server, etc) and I figured I'd set them all up with a free locally-hosted AI chat model for them to use as well. I'm a big fan of open-source local AI, and I like promoting it for others when I can.

I recently got my hands on a DGX Spark and have been having fun putting it through its paces. Currently I'm running Qwen 3.8 Flash Next on it, and I gotta' say... I'm really impressed at this model.

I was testing OpenWebUI and trying to set it up for tool-calling by default (web browsing, Kagi search, code execution, etc) and as a test of tool calling, asked it to tell me what it thought of this random Github URL (CollectorVision).

I was impressed at the quality of its response -- this is all a 100% locally-hosted model generating this answer. Hard to believe this is available for just anyone to run on consumer-grade hardware nowadays:

Prompt

Are you able to browse the web? I’m curious what you think of this repository: https://github.com/HanClinto/CollectorVision/

Response

Yes — I can fetch public web pages and run searches. Let me take a look at that repo.

Let me dig a bit deeper before giving an opinion.

Yes — I can fetch public URLs and run web searches, so I pulled the README, CHANGELOG, and commercial license terms.

What it is

CollectorVision is an open-source, open-weight card identification library for collectible card games. You feed it a photo and it returns a card identity [1]. The pipeline is: neural corner detection → dewarp to a canonical 448×448 crop → produce a compact 128-d embedding → nearest-neighbour search against a catalog of ~108k reference embeddings, end-to-end in under 100ms on laptop CPU [1].

What I think is genuinely well done

The API design is unusually clean. Four calls get you from image to answer (Catalog.load, NeuralCornerDetector.detect, detection.dewarp, catalog.search) [1]. That's a real accomplishment for a CV library — most of these make you wire up preprocessing yourself.

Hardware acceleration is handled pragmatically. Rather than bespoke CUDA code, it exposes ONNX Runtime providers with a simple provider="auto"|"cpu"|"gpu" abstraction that covers CoreML, CUDA, DirectML, and ROCm [1]. The explicit warning about onnxruntime and onnxruntime-gpu colliding in the same environment is the kind of thing only someone who's debugged this at 1am writes down.

The catalog story is mature. Catalog v2 with float16 packed embeddings, exact-predecessor incremental updates, and atomic local snapshots is proper engineering for a dataset that changes constantly [2]. Retaining Catalog v1 for custom NPZ files, and making Catalog.load() dispatch on path extension without touching the network, is considerate [1].

Known weaknesses are documented rather than hidden. The README admits embeddings are sensitive to 180° rotation and ships a rotation-invariant workaround that embeds upright + rotated and keeps the stronger score [1]. The changelog is similarly candid — the Cornelius 2.12 switch is explicitly tracked to issue #24, where soft-argmax averaging could place corners between competing peaks [2]. That's a healthy project culture.

Multi-frame evidence aggregation is shown, not left as an exercise. The examples/web_scanner is deployed as a live JS port demo, and IndexedDB caching for browser snapshots is a nice touch [1][2].

Where I'd have questions

• Licensing is the big one. It's AGPL-3.0 plus a dual-license scheme offering free noncommercial and commercial tiers, split into "site/app" vs "embedded/OEM" pricing [3]. This is a reasonable way to fund a solo-maintainer project, and the perpetual-license language (ongoing payments buy update eligibility, not continued permission to run versions you already licensed) is unusually fair [3]. But it means the free noncommercial license exists mainly as a funnel, and it's a soft ask for downstream projects to announce themselves [3]. If you're evaluating this for anything proprietary, you'll be in a commercial conversation, and note that "formal alternative license texts may be published separately after review" — i.e., the alternative license texts aren't written yet [3].
• Only MTG is really supported. Twelve v2 catalogs are published (pokemon, yugioh, fab, lorcana, swu, etc.), but the README is blunt that the rest are "highly experimental previews" [1]. Also worth knowing: non-MTG catalogs come from TCGplayer and return TCGplayer product IDs, not Scryfall UUIDs — a real integration gotcha [1].
• Project maturity signals are mixed. 356 commits and an active issue tracker is substantial, but 56 stars / 6 forks is small, there are no tagged releases visible, and it isn't on PyPI — you're installing from git [1]. Bus factor is effectively one.
• The experiments/webgpu-android-arm directory suggests some exploration-level code lives in the main tree, which is fine but signals an evolving rather than settled architecture.

Bottom line

For Magic card scanning specifically, this looks like the best open option I've seen — it's the rare CV project where the developer experience matches the model quality, and the changelog shows someone fixing root causes rather than patching symptoms [1][2]. For other TCGs, treat it as a preview and validate against your own images before committing. For commercial embedded use, budget for the license conversation [3].

If you tell me what you're building, I can dig into the relevant parts — e.g. the catalog format, the ONNX model internals, or how the web scanner port differs from the Python path.