Your Agent Found a Cheap RTX 3080. Define Cheap.

The missing instruction is “define cheap”

An agent asked Hardware Hunter for an RTX 3080 price benchmark. Hardware Hunter asked for $0.01 in USDC. The payment settled on Base mainnet, from the test wallet to the address advertised by the live endpoint.

That was cool as hell for about thirty seconds. A machine had bought an answer from Hardware Hunter.

Then the more important part kicked in: finding a listing is not the same as knowing whether it is cheap.

Cheap compared with what? Another used card in similar condition? A refurbished card with a warranty? A suspicious listing missing half the details? The word only means something after you define the comparison set.

That is the instruction a shopping-agent prompt can easily leave out. “Find me a cheap RTX 3080” sounds precise, but the hard part is hidden inside one adjective. An agent can search, sort, and return the lowest number it sees. None of that establishes whether the listing is fairly priced.

The useful question is narrower: How does this listing compare with genuinely comparable hardware, and what evidence supports that comparison?

Cheap compared with what?

A useful benchmark starts by deciding which listings belong in the comparison and which do not.

The model name is only the first boundary. Condition matters. Configuration matters. The kind of price evidence matters. A current asking price and a completed sale answer different questions, so mixing them into one number creates confidence without clarity.

Hardware Hunter’s paid response is deliberately narrower: cohort statistics over distinct comparable listings, drawn from a rolling 90-day window, with condition-specific rows appearing only when their evidence clears the publication gate. The response also carries trust metadata explaining why the cohort was publishable.

That still does not make the result a prediction. Hardware Hunter describes the benchmark as observed asking-price history, not a forecast or a universal market verdict. It is one piece of evidence for a buying decision, not permission to stop thinking.

The same rule applies when you do the work manually. Keep the hardware identity, condition, source, and listing type straight before you compare prices. Our guide to checking eBay sold listings walks through that process without pretending every search result belongs in the same pile.

“Cheap” becomes useful only after those boundaries are visible. Before that, it is just a sorting preference.

The answer has to show its work

Before an agent pays anything, it can read Hardware Hunter’s free catalog. The catalog identifies which components currently have trusted data, which condition strata are available, the configured network, and the advertised query price. On August 25, it listed the RTX 3080 with a trusted used-condition stratum and priced a paid query at $0.01 on Base mainnet.

The paid answer is not just a number. It includes the cohort distribution, the number of distinct comparable listings behind it, the observation window, and benchmark_trust metadata describing the publication basis. Condition-specific rows appear only when their own evidence clears the gate.

The refusal path matters just as much. Hardware Hunter checks whether it has trusted data before asking for payment. An unknown component returns not found. A recognized component without a trusted cohort returns an insufficient-evidence response without charging the caller.

That is not a graceful error message pasted onto the end of the product. It is part of the product.

If an agent cannot tell the difference between “the evidence supports an answer” and “I found some listings,” it should not be calling either result a market price. And if Hardware Hunter cannot support the answer, it should not collect the cent.

You can inspect the live catalog and data contract on the Hardware Hunter x402 page.

What actually happened when the agent paid

The payment flow is less dramatic than the phrase “machine-to-machine commerce” makes it sound.

1. The agent requested the trusted RTX 3080 benchmark without attaching payment. 2. Hardware Hunter returned HTTP 402 with a PAYMENT-REQUIRED header describing the exact scheme, network, USDC contract, atomic amount, recipient, and timeout. 3. The agent signed payment against those requirements and retried the same request with PAYMENT-SIGNATURE. 4. Hardware Hunter verified and settled the payment, returned the benchmark, and included a PAYMENT-RESPONSE receipt containing the transaction, network, payer, and successful settlement state. That challenge, retry, and receipt sequence is the standard x402 HTTP flow.

The controlled mainnet transaction moved $0.01 in USDC from the test wallet to the recipient advertised by Hardware Hunter. The transfer succeeded on Base, and the on-chain recipient and amount matched the live payment requirements.

You can inspect the Base transaction yourself. The header mechanics are defined in the official x402 HTTP transport specification.

The useful part is not that a wallet can send a tiny payment. The useful part is that the request, price, data contract, authorization, response, and settlement receipt can all travel through the same HTTP exchange. An agent can inspect what it is buying before it signs, then verify what happened afterward.

A benchmark is an input, not permission to buy

A market answer should improve an agent’s recommendation. It should not replace the recommendation.

The benchmark can establish a comparison point and describe the evidence behind it. It cannot decide whether the listing matches your exact needs, whether the seller looks trustworthy, whether the warranty matters to you, or whether the price exceeds the ceiling you set.

A useful shopping agent should combine the pieces:

• Verify that the listing is the hardware and condition the buyer requested.
• Compare its asking price with the relevant benchmark.
• Explain which evidence supports the comparison.
• Account for seller risk, missing accessories, shipping, tax, and anything else that changes the real cost.
• Respect the buyer’s target and hard ceiling.
• Say when the available evidence is insufficient.

Hardware Hunter’s x402 surface supplies observed price history, not a forecast, market verdict, or autonomous purchase decision. If the trusted cohort does not exist, the endpoint returns an insufficient-evidence response without demanding payment.

That last outcome is useful. “I cannot support this comparison” is a better answer than quietly substituting the lowest listing an agent happened to find.

Hardware Hunter applies the same principle to its human-facing product: a saved hunt watches for matching listings and returns an evidence-backed verdict instead of leaving you with another feed to sort. The scoring guide explains how those pieces fit together.

Make cheap a rule, not a vibe

An agent can search every marketplace it can reach and still give you a bad answer.

The failure happens earlier than the search. It happens when “cheap” is left undefined.

Cheap is not the lowest number in a page of results. It is a listing that survives a comparison you can explain and stays below a ceiling you chose before a disappearing deal started messing with your judgment.

That is the standard shopping agents should meet. Show the comparison. Name the condition. Separate evidence from guesswork. Respect the buyer’s ceiling. Say when the data is not good enough.

The payment rail is useful because it lets an agent buy that missing piece at the moment it needs it. The market answer is useful because it gives the agent something better than vibes.

And if you do not want to build the agent yourself, Hardware Hunter already does the watching. Create a saved hunt, set the target and hard ceiling, and let the verdict show its work when a matching listing appears.

Start a hunt