Why AI quotes the wrong price for your variant (and how to make the right one readable)

Short answer: an assistant that quotes the wrong price for a variant has read the product, not the variant. The storefront get_product tool returns a price range and one variant unless the agent asks for a specific option; agents often don’t, and quote the range or the minimum. Fix the first variant, then let agents ask for the rest.

Why does an assistant quote $69.99 when the variant costs $74.99?

Every Liquid storefront on Shopify has exposed ten storefront tools to browser-based agents on every Liquid storefront since 21 August 2026 (announced 5 August), currently limited to Chromium browsers through an origin trial whose token expires on 17 November 2026. One of those tools, get_product, is how an agent reads a product once search has found it. Its response carries a price range for the whole product and a single variant. In the responses we captured, a product with four variants reported variant_count of 4 and returned one of them.

To get the price of a specific option, the agent has to call again with that option selected (or call show_variant). That is one more call, per product, and agents run on a budget of a handful of calls per question. When the budget runs short, or the model decides it already has enough, it answers from what it holds: the range, or the low end of it.

We saw this directly in a simulated check on 2 September 2026 against a public 1,055-product phone and device accessories store. Twelve shopper questions, each with a verified answer set; three models, Anthropic’s Claude Opus 5 and OpenAI’s GPT-5.6 and GPT-5.5, called through their developer APIs; at most six tool calls per question; a judge pinned to Claude Opus 5. With the store’s native tools alone, Claude resolved 9 of 12 and both GPT models 8 of 12. No answer scored zero; every miss was a partial. Six of the nine native partials were variant-level price or stock: the agent answered “$69.99–$79.99” or quoted the $69.99 minimum when the variant the question named costs $74.99. The judge’s note on the missing capability, verbatim: “variant-level price lookup for selected options”.

The agent found the right product every time. It just described the wrong version of it.

Why option-heavy catalogs get hit hardest

On a catalog where every product has one variant, none of this matters: the one variant returned is the product. The problem scales with the number of options a shopper has to name before a price means anything.

The accessories store in that check has a “Device” option with 474 values. One phone model alone appears on 45 products. A shopper never asks “how much is this case”; they ask “how much is this case for my phone”, and the answer is a variant, not a product. Every such question costs the agent a second call per candidate product, and a comparison across three cases costs six, which is the whole budget.

Descriptions do not rescue it. On that store, 891 of the 1,055 products carry boilerplate descriptions; the real specs are theme-rendered metafields no storefront tool reads. So the model has nowhere else to look up the price and reaches for the range.

Contrast a 150-product coffee store we checked with the same setup the same day: native tools were enough, Claude Opus 5 answered 10 of 10 and GPT-5.6 9 of 10. The tools are not weak; they return one variant, and text-rich catalogs rarely need more than that. Option-heavy ones do, on almost every question. The wider batch of 34 specialist stores shows the same pattern from the other side: 119 of 186 imperfect answers were a single missing fact about a single product.

What the same shape looks like for stock

The one variant get_product returns carries its own availability. An agent that never asks for the shopper’s option reports that variant’s stock state as the product’s.

Two outcomes follow. If the first variant is sold out and the one the shopper wants is available, the shopper hears “out of stock” for a product you could ship today. If the first variant is in stock and the requested one is not, the shopper hears “in stock”, tries to buy, and finds out at the cart. The first case is the one merchants notice, because it surfaces in forums as “an assistant says my product is sold out”. If that is your symptom, that article walks through the other availability signals too (page schema and the syndicated catalog); this one stays with the variant.

How to check, in ten minutes

1. Pick a product with three or more variants whose price differs by option. Note the price and stock state of the variant most shoppers buy, and of the product’s default variant (the one listed first) in the admin.
2. Ask for a specific option, in a fresh session. Open an assistant with no history and ask, in your own words, “How much is [product] for [option] at [store]?” Record the answer verbatim, with the assistant and the date.
3. Compare it to the variant. A range, or the product’s lowest price, when the option you named costs more, is the mechanism above. The exact price of the first variant, rather than the one you asked for, is the same mechanism.
4. Repeat with stock. “Is [product] in [option] in stock?” Compare the answer to that variant’s inventory, then to the first variant’s.
5. Look at your first variant. For your top twenty products, is the product’s default variant (the one listed first) the one most shoppers want, and is it in stock? If not, that is where an agent starts reading.

Consumer assistants add their own retrieval and caching on top of the storefront tools, so a manual check tells you what a shopper heard on that day, not what every agent will read. A simulated check through the developer APIs shows the tool responses themselves, which is where the fix has to land.

The fixes, cheapest first

1. Make the first variant the one most shoppers want, and keep it in stock

This costs nothing and works immediately. In the admin, order each product’s variants so the best-selling option comes first, and watch its inventory: if the first variant sells out, the product reads as sold out to any agent that does not ask further. For products where one option dominates, this alone removes most wrong-variant answers. For products where the mix is even, it only moves the error to a different shopper, which is why the next two fixes exist.

2. Name option values the way shoppers ask

Variant titles on Shopify are built from option values, and they are what an agent sees when it does ask for a specific option. “iPhone 17 Pro Max” matches a shopper’s question; “17PM” or “Model C” does not, and an agent that cannot match the shopper’s words to an option value will not select it, even when it tries. Write option values in the words a shopper would type, keep them consistent across products, and avoid encoding two facts in one value (“Black / MagSafe”) when they are separate options. Free, but tedious on a large catalog; do the top sellers first.

3. Publish a per-variant price and stock tool

The two fixes above make the right variant easier to hit. They do not let an agent ask “what does the version for my phone cost, and is it in stock?” and get that variant’s answer in one call. That is what StoreKnows’ captured-variant tool does. It publishes, read-only, the price and availability of every variant of every product, beside Shopify’s own tools, from a saved copy of your catalog that you review and approve before anything goes live. It is not live inventory: the tool answers from the copy you approved, and you refresh it when you choose. We say so to shoppers’ agents in the tool description and to you in the app, because a stale “in stock” is worse than a range.

The reason we built it is what happened in that same check when we added tools with full variant data. A compare-products tool that returns every variant’s price and availability for the products named, in a single call, was what fixed the variant partials: Claude Opus 5 went from 9 of 12 to 12 of 12 while making 40% fewer tool calls (a mean of 4.4 per question down to 2.7), because it stopped looping through get_product per product. GPT-5.5 went from 8 to 10. GPT-5.6 went from 8 to 9; its traces show it often ignored the added tools and kept searching and reading one product at a time, then quoted the minimum. Tool adoption is model-dependent, which is why the app shows you the result per assistant rather than one number.

What this does not tell you

Twelve questions, three models, one run each, on one store chosen because it is hard. The counts describe a mechanism, not a rate you should expect on your own catalog. The check ran through developer APIs, not the consumer apps, so it shows what the tools return and how a model reads them, not what ChatGPT or Gemini will say to a shopper this afternoon.

It also does not cover every miss. One comparison in that check, between a 15" and a 15.4" screen protector, stayed partial in every model with native tools alone, because the difference lives in a metafield no tool exposes. Variant tools fix variant questions; spec questions need spec data made readable, which is a separate fix.

The variant problem is the most common one we see on specialist stores, and the cheapest to test. Reorder your first variants this week, rename the option values that shoppers would not recognise, and if your catalog looks like the one above, run the free check: you will see every answer by assistant, the variant the agent actually read, and what changes when it can ask for the right one.

Results in this article come from a simulated check run by StoreKnows on 2 September 2026 against a public 1,055-product accessories storefront and a public 150-product coffee storefront. Questions were answered by Anthropic’s Claude Opus 5 and OpenAI’s GPT-5.6 and GPT-5.5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.