A title card reading "ghfind Put MiniCPM-V 4.7 Behind Its GitHub Roasts", subtitled "and its own docs disagree about what that changes", with three pill labels — deterministic score, named model sponsor, two contradicting docs — and a motif of three rounded cards joined by thin lines, each holding a small flat contribution grid.
Engineering & Research

ghfind Put MiniCPM-V 4.7 Behind Its GitHub Roasts — and Its Own Docs Disagree About What That Changes

Author

Magnus Corvin

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

Scroll to the bottom of ghfind.com and there is a small line that did not used to be there: Model sponsor, a MiniCPM mark, and a link out to modelbest.cn. The model behind that mark is MiniCPM-V 4.7, OpenBMB's vision-language release from October 12, 2026. For a product whose entire pitch is a reproducible 0–100 "value and trust" score for any GitHub account, a model sponsorship is not a cosmetic detail — it is a question about what the model is allowed to touch. And ghfind's own documentation gives two different answers to that question. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

That is the story worth writing, because the surface version — "a GitHub roasting site switched models" — is a press release. The version underneath is about a scoring product that has to convince people its number is not vibes, adopting a language model at the same time.

What the page actually shows, and what it does not

The sponsorship strip is real and visible on the public English homepage. It sits beside two other controls: a Use your own model / API key option, and empty logo slots marked Your logo here. So the structure ghfind is advertising is not "our model, mandatory" — it is a default sponsor plus a bring-your-own-key escape hatch, which is a reasonable design for a product that spends model credit on every roast.

Three things that get repeated about this change are not on the page. First, ghfind publishes no traffic figure anywhere on the site, so any number describing its daily visits is coming from somewhere other than ghfind. Second, the phrase "main model" is not ghfind's — the page says Model sponsor. Third, and most usefully, the open-source repository still ships a different default entirely: its .env.example configures the roast LLM against StepFun's step-3.7-flash, with a D​eepSeek fallback for the case where the primary provider drops or rate-limits before any text streams. Anyone self-hosting ghfind from source gets that configuration, not a MiniCPM endpoint.

So the accurate statement is narrow and more interesting than the broad one: on the hosted product, MiniCPM is the named model sponsor. In the open code, it is not the default. Those are different claims and only the first is supported by what a reader can see.

The product, before the model

ghfind is a Next.js application, AGPL-3.0, about 260 stars on GitHub, continuously pushed through the week this was written. Its core is not an LLM at all. A deterministic TypeScript engine — ported line by line from an open-source Python skill called github-account-value, with parity tests locking the two implementations together — reads public GitHub data and produces a score across six weighted dimensions: account maturity, original project quality, contribution quality, ecosystem impact, community influence and activity authenticity. Ten red flags for farming behaviour subtract from that, weighted toward signals that are expensive to fake, like pull requests merged into repositories the account does not own, and away from signals that are cheap to buy, like stars and followers.

The whole point of that design is auditability. Given the same GitHub account and the same collection date, the number is supposed to be the same number every time, for everyone. That is what makes a score usable for something like triaging an issue queue, which ghfind also does through a GitHub App that labels incoming issues with the author's band.

Where the model enters is downstream: turning a fixed result into a roast line, a set of tags and a written report. That is the part users screenshot and share, and it is the part a sponsorship would naturally attach to.

The contradiction worth noticing

Here is where the two documents part company.

The repository README describes two separated LLM passes: a factual judge may apply a bounded ±10 calibration, then a writer turns the fixed result into tags, the top roast line, and the report. The writer cannot change the score. Read that sentence twice. The writer is explicitly forbidden from moving the number, and the judge is explicitly permitted to move it by up to ten points — on a hundred-point scale, that is a tenth of the entire range.

The site's own llms.txt, written for agents and machines, says something stronger: a fully deterministic engine … The same inputs always produce the same score; no LLM touches the number.

Both cannot be true at once. Either the judge pass exists in the default path and the ±10 bound is real, in which case the score is deterministic up to a model-dependent calibration — or the judge is not in the default path and the README is describing an optional mode. What is not in dispute is that the repository's own text contemplates a model having bounded influence over the number, while the public-facing machine-readable description says it has none.

This matters more, not less, because a model sponsor is now named on the page. If a model can move a score by ten points, then which model is doing the judging is a question a user is entitled to ask — not because anyone is cheating, but because reproducibility claims are only as strong as their weakest documented exception. A product that publishes a methodology page owes its readers one sentence settling which of its two descriptions is current.

Why a vision model, for a text product

The choice of a multimodal model for a GitHub-scoring site looks odd until you look at what the model is actually handed. MiniCPM-V 4.7 is not being asked to read repositories; it is being asked to read a prompt. Vision-language models are increasingly used as cheap general judges because they are trained on interleaved input and tend to hold structured-output instructions well, and because a single model that can also accept a screenshot is useful the moment a user pastes a profile capture into a support flow.

There is also a cost logic. The 35B-A3B variant activates roughly three billion parameters per token across a 256-expert mixture, and the 1B variant is a dense model small enough to run on a phone. For a product whose roast pass fires on every profile scan, a model you can serve cheaply — or run yourself — is a different economic proposition from a frontier API call per roast. That is the same reason the site offers a bring-your-own-key path: the model bill scales with traffic, and traffic is the thing a scoring site is trying to grow.

If you are building that kind of pipeline yourself — a deterministic core with a model-backed narration layer on top — the operational question is how many providers you want to be holding keys for. OrcaRouter puts 200-plus hosted models behind one OpenAI-compatible endpoint at 0% markup, with each provider's list price passed straight through and automatic failover when a provider degrades; its routing DSL can send the cheap judge pass and the more expensive writer pass to different models within one call. One honest limit: MiniCPM-V 4.7 is not on our catalogue, so if it is the model you want, you go to OpenBMB's own platform for it. The router is the part that keeps a fallback path warm when a single sponsored endpoint is the only thing standing between you and an empty roast box.

What MiniCPM-V 4.7 actually is, as of this week

The model side deserves the same precision. OpenBMB's repository carries a News entry dated 2026-10-12 reading "MiniCPM-V 4.7 released," and the Hugging Face repositories were created in the days before that — October 6 for the 1B and October 7 for the 35B-A3B — which is what a staged weight upload looks like. The model card followed. A second News entry on 2026-10-15 announced DSpark speculative-decoding heads in BF16 and GGUF for both sizes.

• Sizes — 35B-A3B sparse mixture of experts at 35.21 billion total parameters, and a 1B dense variant at 1.55 billion

• Licence — Apache 2.0 on both, weights downloadable, no gate

• Context — 262,144 tokens on both variants

• Architecture — 256 experts with 8 active per token in the 35B; a 3:1 linear-to-full attention pattern across 40 layers; vision tower at 1152 hidden width with 980-pixel input tiles

• Quantisation — GGUF, bitsandbytes, AWQ, GPTQ, FP8 and int4 builds published alongside the BF16 weights

• Serving — SGLang, vLLM, llama.cpp and Ollama listed as supported; Ollama has a first-party entry

• Vendor claims — 13+ tokens per second with about 3 GB of memory on an iPhone 17 Pro Max, and a 5× on-device speedup from Lookahead Expert Scheduling

• Distribution — roughly 95,000 monthly downloads on the 35B-A3B repository and 46,000 on the 1B, with about 1,079 and 398 likes

Everything in that list is checkable from the card and the configuration file. What is not yet available is independent evaluation. The Artificial Analysis model catalogue has no entry for either MiniCPM-V 4.7 variant as of this writing, so the 13-tokens-per-second figure, the 5× speedup and the claim that 35B-A3B "achieves a higher overall score in less inference time than Qwen3.6 35B-A3B" are all vendor-reported and unreproduced. That is normal for a model eight days old, and it is the reason to treat the sponsor placement as a signal about ghfind's cost structure rather than a signal about model quality.

A cropped capture of the Hugging Face model card for MiniCPM-V-4.7-35B-A3B under the OpenBMB organisation, showing the benchmark chart images and the quick-start sections of the card.

The part nobody can verify yet

Which brings the two halves of this story back together. ghfind's credibility rests on a number it says is reproducible. MiniCPM-V 4.7's credibility rests on benchmarks its vendor published a week ago. The sponsorship joins them without any published evidence about how the model behaves as a judge — no agreement rate against human raters, no drift measurement across model versions, no statement of whether swapping the sponsor would change anyone's score.

Those are all cheap things to publish and expensive things to be asked about later. The specific measurement that would settle it is a re-score test: take a fixed sample of accounts, run the pipeline with the judge pass enabled and disabled, and report the distribution of the difference. If it clusters at zero, the ±10 is a safety rail nobody trips and the "no LLM touches the number" line is effectively true. If it spreads, the calibration is doing real work and the methodology page needs to say so.

Until then, the honest reading is this. ghfind is a well-built deterministic scorer with an unusually clear separation between its number and its prose, and it now has a named model sponsor whose role in the pipeline is documented inconsistently across its own files. MiniCPM-V 4.7 is a real, Apache-licensed, genuinely small-on-memory multimodal release that arrived eight days ago with a model card, a DSpark follow-up and no independent benchmarks. Neither of those facts is a scandal. Both are the kind of thing you notice only when you read the repository instead of the homepage — which, for a product that scores other people's work, is the least a reader can do.

A scoreboard titled "MiniCPM-V 4.7 — the scoreboard" listing eight rows: 35B-A3B MoE with a 1B dense sibling, 262,144-token context, Apache 2.0 licence, SGLang, vLLM, llama.cpp and Ollama serving, 13-plus tokens per second at about 3 GB on-device, GGUF, AWQ, GPTQ, FP8 and int4 quantisation, no independent score published, and charts rather than a table for the published evaluation.

How to check your own score, concretely

If you have a profile on the site, the deterministic path is the one to test. ghfind exposes a score endpoint that requires no authentication and no model call, and the underlying scoring skill is open source, so the number you get from the API and the number you get from the site should agree. If they do not, the difference is either collection timing — the site caches for a day — or the calibration pass, and those are distinguishable by asking whether the gap is stable across repeated runs.

For anyone building a similar tool, the architectural lesson from ghfind is worth more than the model news: keep the number in code, keep the prose in a model, and make the boundary between them explicit enough that a reader can inspect it. The failure mode is not using an LLM. The failure mode is documenting the boundary in two places and letting the two descriptions drift.

The ghfind.com English homepage, showing the username entry field, the "value and trust score" pitch, scan counters, the Model sponsor strip naming MiniCPM, and the bring-your-own-key control.

What to watch next is narrow. ghfind has a public changelog and a repository that is pushed most days, so a methodology note reconciling the ±10 calibration with the "no LLM" line would show up quickly. On the model side, the first independent benchmark of MiniCPM-V 4.7 — or the first report of what it costs per roast at volume — is the number that would turn a sponsorship into an argument. Neither exists yet. Both are one publication away.