Full site context for agents: https://tansohq.com/llms.txt

Methodology

Last reviewed September 4, 2026. The site contains 96 live products and 396 live pricing components. Five retired records remain in the export, for 101 products and 410 components total, so earlier citations continue to resolve.

What we classify

Rows in the comparison are products, not companies. OpenAI's API and ChatGPT are separate products, as are Anthropic's API and Claude, because their commercial models differ.

Each product is decomposed into the components that affect price: a seat, plan fee, included allowance, purchased balance, contracted quantity or post-use meter. Each component has its own payment timing, billing term, Overage, Rollover, Top up and supporting evidence. This preserves hybrid structures instead of forcing the entire product into one label.

These are narrow operational questions, not one-to-one labels for broader pricing-strategy categories. Overage here means excess usage billed after it occurs; Top up means buying more of the priced component during an existing cycle. The priced component may be credits, usage packs, capacity, or seats.

Two flags answer different questions:

• main_metric marks the component expected to drive most customer spending, based on the product's core priced feature and commercial structure.
• answers_row marks the component highlighted in the one-row website comparison. It is selected for the named AI feature instead of defaulting to a general seat or plan fee. Among documented AI-usage components, the order is a standard plan's included allowance, a customer-funded balance, a contracted quantity, then the main post-use meter. A product-specific add-on may be used when it is the only published measurable mechanism governing additional AI use; an unrelated balance never qualifies. The component name and note disclose add-on or companion-product scope.

Overage and Rollover in the product comparison come from answers_row. Top up is broader: it asks whether the customer can buy more of the priced component during the cycle without changing plans. This includes credits, usage packs, capacity, and seats, even if that purchase uses a separate documented balance or add-on. The detail view identifies that mechanism, and the table marks a separate mechanism with Yes°.

The fields

Pricing metric. The unit, balance, quantity or fee that affects price. A product can have several. Seats count, even though they are not usage.

Commitment timing. Before use means a balance, quantity, seat, capacity, fee or other commitment is purchased or committed before the related use. After use means actual use happens first and is measured and billed afterward with no committed quantity underneath. Both means one component combines a purchased or committed quantity with a documented post-use path. This describes the order of commitment and use, not the calendar date on which an invoice is paid.

Commitment timing is independent of the thing being charged. A seat can be a quantity committed in advance or an active-seat meter billed afterward. Tokens, DBUs, minutes and outcomes can likewise use any of these models.

Billing term. The period applying to that component: Daily, Weekly, Monthly, Quarterly, Semiannual, Annual, Multi-year or None. None is a real answer, such as a prepaid API balance with no recurring contract period. An empty field means the term is not established.

Overage. Can the customer exceed a prepaid or committed quantity and be billed for the excess afterward? Yes for a documented, intentional negative-balance or excess-invoice path. No for a hard stop or a buy-more-first path. Buying more first is a top up, not overage. A temporary negative balance caused by delayed cutoff, concurrent work or an in-progress request finishing is an enforcement detail, not overage, unless the vendor intentionally offers and bills for excess usage as a commercial path.

Rollover. Does any unused amount remain usable after the end of its applicable term? Yes if any amount survives the boundary, even if it later expires. No if it resets, is forfeited or expires at the boundary. The test is whether the validity window outlives the term. A later expiry does not make Rollover No. With billing term None, Yes or No requires documented carry behavior relative to a linked plan or another stated cycle. Otherwise Rollover is N/A because there is no term boundary to test.

Top up. Can the customer buy more of the priced component during the current billing cycle without changing plans? This includes credits, usage packs, capacity, and seats. Manual purchases and automatic reloads count. A separate balance or add-on counts only when the vendor documents that it buys usage for the product being scored. Ordinary post-use billing is not a top up.

N/A and not established. N/A applies when the component is metered and billed entirely after use. It also applies to Rollover when a component has no recurring term or linked cycle, so there is no boundary to test. It is never determined by a category such as “seat.” A dash means the available evidence does not establish an answer. Absence of documentation is never treated as No.

Evidence standard

Every Yes or No has quoted source text, a URL, confidence and read date. First-party billing documentation, pricing pages, help centres and legal terms are preferred. Credible third-party evidence is admitted only when first-party material is unavailable and is labeled low confidence. Quotes state what the source says; notes explain how the rule was applied. Confidence is shown only for established values in the downloadable CSV; explicit unknowns leave confidence blank so ? can never appear as “high confidence.” A URL may remain on an unknown to show which source was checked.

The downloadable CSV has one row per pricing component. It includes separate main_metric and answers_row flags, component-level timing and term, all three mechanics, and the quote, URL and confidence behind every established value. The current machine-readable export is available at https://tansohq.com/data/pricing-finder-current.json.

Retired fields

Earlier product-level fields were withdrawn from the comparison on September 1, 2026 because they combined unlike components or asked questions the sources could not reliably answer. They remain in the JSON export for compatibility but do not drive the table or CSV.

How the data stays current

The September 3 review independently re-researched all 101 products, checked every component row and its supporting classifications, and then applied only direct, field-specific corrections. Automated checks enforce the component and evidence invariants. A product that stops being sold is retired only when its retained rows preserve the actual historical offer; records that merely duplicate a successor's current pricing are removed.

See something wrong?

Sources are linked from each product page. Email kat@tansohq.com and we will review it.