Delivered vs. Partly: what separates AI launches that hold up

By 26 October 2026 we had stamped nine AI launches. One came out Delivered, six Partly and two Too early. None was Not yet. A wall of Partly stamps can look like a hit-piece, so it’s worth being precise about what the word means and what the one Delivered launch did differently.

Partly is not a polite failure. It means the product shipped and some claims hold, but at least one headline claim is mixed or fails for a meaningful share of the people reporting on it. Delivered means the headline claims hold in most solid reports and no claim fails. The rules are on the method page, and we never bend a verdict to change the mix.

The Delivered receipt: EmbeddingGemma 2

Google launched EmbeddingGemma 2 on 6 October: a 740-million-parameter open-weight embedding model that maps text, code, images, audio and video into one shared embedding space. We quoted five claims. Four hold:

• A shared space across modalities. Builders used it that way: one built an experimental speech-to-text app by matching audio to text embeddings, another swapped it in for both the first EmbeddingGemma and an image model and got better quality with less memory.
• Open, Apache 2.0, small enough for devices. The Hugging Face repository is ungated and tagged Apache 2.0. Users run it on laptop CPUs and Macs; one CPU-only runtime matched the official embeddings closely using about 1.4 GB of memory.
• Shorter vectors on demand. A team that forked the text path for Hindi retrieval measured small quality losses when truncating to 512 or 256 dimensions, and a larger one at 128.
• Same text quality, better code retrieval. An independent 550-task retrieval benchmark found overall scores about level with the first version and a gain on code retrieval.

The fifth claim, that partners ensured it “works immediately where you build”, came out mixed: Ollama’s build would not install on Linux or Windows, vLLM failed to start it on consumer and DGX Spark GPUs, and the Quickstart missed a dependency. We counted that against the launch’s tooling, not the model, and the verdict is Delivered.

Pattern 1: narrow claims that users can test

Look at how EmbeddingGemma 2’s quality claim is worded: it “matches the strong multilingual text performance of EmbeddingGemma while delivering a significant 9.92-point improvement on code performance”. It doesn’t promise to be better at everything. It promises parity on text and a gain on code. When a user’s first tests found no gain for text-only retrieval, that matched the claim instead of contradicting it.

Compare Claude Opus 5.5: “It performs at the level of Claude Fable 5.1 on most work and costs 40% less to run than Opus 5.” “Most work” and “costs to run” are broad, and the one detailed report we found measured more thinking tokens per request, which would cut into the saving. Broad claims leave more room for a meaningful share of users to see something else.

Pattern 2: promises the vendor controls on its own

The claims that held for EmbeddingGemma 2 were all about the model itself. The one that didn’t was the one that depended on other people’s software.

The Partly receipts show the same split. Gemini 4 Argon is live in the API and the Gemini app, but its availability claim depends on plan tiers, family plans and a rollout to Antigravity, and Pro and Ultra for Business users reported it missing. Its price claim promised cached input “at 95% off”, and developers got zero cache hits because explicit caching isn’t supported for the model. GPT-6.1 Sol was “available starting today” but needed app updates for many users. Every extra system a claim depends on is another place it can go wrong.

Pattern 3: open weights invite independent testing

Open weights don’t guarantee a good stamp, but they speed up the evidence. EmbeddingGemma 2’s ungated repository meant people could build runtimes, forks and benchmarks within days, and publish measurements.

DeepSeek-V4.1-Flash-1017 is the counterpoint. It is also open and MIT-licensed, and those claims hold: it is live on DeepSeek’s API and the weights are public and ungated. But its performance claim, “Stronger benchmark performance, faster task completion, and shorter outputs than the previous version”, split users. One tester measured shorter outputs at every reasoning level; a team running it in their own agent said it overthinks simple requests. Openness got it tested quickly; the test results were mixed, so the stamp is Partly.

Pattern 4: big architecture changes carry big upgrade risk

Two Partly receipts are coding tools that changed how they run. Codex CLI 0.157.0 turned on a background server by default, and some Windows and Arch Linux users could not start it without a flag. OpenCode 2.0 moved everything into one background process, and users hit migration errors and a single point of failure. In both, the new design shipped as described. What made them Partly was what the change did to existing setups. We cover both in AI coding agents after launch.

EmbeddingGemma 2 had no upgrade path to break. It was a new model you could choose to try.

What this means if you’re evaluating a launch

• Prefer specific claims over sweeping ones. “Matches X, gains Y on Z” is easier to trust than “better at most work”.
• Separate the product from its rollout. Plan tiers, partner runtimes and app updates are where availability claims slip.
• Check whether outsiders can test it. Open weights and public APIs mean you can find independent measurements sooner.
• Be careful with upgrades that change architecture. Back up first, and read the open issues for your setup.

Why we track likely winners too

We choose which launches to cover, and we deliberately include stable releases and well-received open models alongside the big hyped ones, so the archive shows contrast. We don’t choose verdicts. If a launch we expected to deliver doesn’t, it gets its honest stamp. You can see every result, and filter by verdict, in the receipts archive.