How to Prepare a CometAPI Pricing Dispute Intake

Last reviewed: 2026-07-18

Direct answer

A reliable pricing dispute intake separates three things: what was requested, what the account or request record shows, and what the current pricing and support documentation says. Begin with the date range, the relevant model or service category if known, a sanitized request identifier, the public pricing page consulted, and the exact difference that requires explanation. Keep credentials, full user prompts, private payloads, and unrelated account data out of the packet.

The first comparison should identify the billing unit that appears to apply. The CometAPI pricing documentation describes token billing for models with unified official pricing and call-based billing for models without official APIs. The same documentation says that applicable pricing information should be checked for the specific model or service rather than inferred from a general example. The help center adds that multipliers can be model-specific and that pricing adjustments may change with market conditions or published notices. These statements support a verification process, not a guessed invoice calculation.

A useful intake packet therefore contains evidence in a fixed order:

1. Request context: date, time zone, environment, service or model label, request reference, and a short business purpose.
2. Usage evidence: the sanitized request result, usage record, charge record, or dashboard export that shows what was observed.
3. Pricing reference: the exact public page reviewed, its access date, and the relevant wording or section.
4. Account context: the account, project, team, or cost center responsible for the disputed usage, without exposing private identifiers that are not needed for support.
5. Difference statement: one concise sentence describing the expected treatment, observed treatment, and unresolved amount or classification.
6. Verification status: confirmed, partially confirmed, or unresolved, with the missing evidence named explicitly.

Do not treat a smoke test as proof of the final invoice. A controlled request can show that the documented request path works and that evidence can be collected. It cannot establish an account-specific discount, invoice adjustment, commercial exception, or undocumented billing rule by itself.

Who this is for

This guide is for engineers, finance partners, procurement teams, and support operators who need to explain a pricing difference without relying on an old screenshot or an unsafe credential dump. It is also useful for teams that share one access path across several projects and need to assign usage to an accountable owner before escalating a case.

The method works best when the team can access a sanitized request record, a current public pricing reference, and whatever account-level evidence is permitted for the case. If one of those inputs is unavailable, record the gap instead of filling it with an assumption.

Key takeaways

• Capture request context and pricing evidence together so the dispute can be reproduced.
• Distinguish token-billed services from services described as call-billed in the current pricing guide.
• Treat model-specific multipliers, adjustments, and account details as items to verify.
• Use the current documentation page and access date, not an undated screenshot.
• Assign the disputed usage to a project, team, or cost category before asking finance to approve an adjustment.
• Remove credentials, full prompts, private payloads, and unnecessary identifiers before sharing a support packet.
• Keep the final record explicit about what was observed, what was confirmed, and what remains unresolved.

For related operational context, see Trace CometAPI Cost and Usage for Token Budgets and Build a Finance-Ready Token Spend Exception Packet .

Smoke-test workflow

Setup assumptions: use a non-production account or an approved test environment, a current public source URL, and a model or service value taken from current documentation. Store any credential reference as <API_KEY_PLACEHOLDER> in notes. Never place a live key in a ticket, shared document, shell history, or article.

Happy-path request plan: submit one minimal representative request through the currently documented interface. Record the sanitized request reference, the service or model label, the outcome, the available usage or charge evidence, and the pricing rule used for comparison. Avoid changing multiple variables in the same test because that makes the result harder to explain.

Error-path check: in a non-production environment, use an intentionally incomplete or invalid test input that does not expose a credential or private payload. Record only the observed error category, whether a response was returned, and whether the client handled the failure without leaking sensitive values. Do not assign an undocumented status code or cause to the result.

Minimum assertions: the request outcome is recorded; the public source URL and access date are recorded; the comparison basis is named; the service or model label is copied accurately; the evidence is associated with an owner or project; and the redaction check passes.

Pass/fail logging fields: case_id, checked_at, source_url, request_ref, service_label, environment, outcome, comparison_basis, owner_or_project, redaction_check, unresolved_fields, operator_note.

Pass: the request evidence, pricing reference, account record, and ownership mapping agree closely enough for the case to be explained. Fail: a material difference remains, a required record is missing, or the available evidence does not identify the applicable billing treatment. A failed case should be escalated with the sanitized packet rather than repaired through an unsupported assumption.

Sanitized log template:

case_id=<CASE_ID>
checked_at=<UTC_TIMESTAMP>
source_url=<PUBLIC_SOURCE_URL>
request_ref=<SANITIZED_REFERENCE>
service_label=<DOCUMENTED_LABEL>
environment=<TEST_OR_NONPRODUCTION>
outcome=<PASS_OR_FAIL>
comparison_basis=<DOCUMENTED_RULE_OR_UNRESOLVED>
owner_or_project=<SANITIZED_OWNER>
redaction_check=<PASS_OR_FAIL>
unresolved_fields=<NONE_OR_LIST>
operator_note=<SHORT_SANITIZED_NOTE>

Failure modes

Using an outdated price reference. A screenshot or copied table may no longer describe the applicable model or service. Keep the clean public URL and access date in the intake record, then verify the current page before making a conclusion.

Confusing billing units. Token billing and call-based billing require different comparison inputs. If the service category is unclear, mark the billing unit unresolved and ask for the specific documentation or account evidence needed to classify it.

Treating a general ratio as an invoice promise. A general pricing explanation does not prove that every model, account, or adjustment follows the same treatment. Use model-specific and account-specific evidence where available.

Ignoring multipliers or published adjustments. The help center describes independent model multipliers and possible market-related adjustments. Record the multiplier or adjustment information that applies, but do not calculate a final amount from an incomplete record.

Sharing too much data. Full prompts, private responses, credentials, and raw logs can create a security or privacy problem. Share only the fields needed to identify the request, compare the charge, and route the case.

Missing ownership. A disputed amount that has no project, team, or cost-center mapping is difficult to review. Use available tags, labels, account structures, or other metadata to assign accountability. FinOps allocation guidance treats this mapping as a way to create transparency around technology usage and cost.

Calling an unresolved result a failure of the provider. The evidence may show only that the local record and public documentation do not yet align. Describe the discrepancy precisely and leave the cause open until the missing record is supplied.

Reader next step

Create one sanitized intake record for the most recent disputed charge. Attach the public pricing page, record its access date, identify the billing unit that appears to apply, and map the usage to an owner or project. Then run the minimum comparison: request reference, service label, observed usage or charge evidence, documented pricing basis, and unresolved fields. If the records agree, retain the packet as an audit trail. If they do not, send the redacted packet to the appropriate support or finance contact and ask a specific question about the missing evidence.

Before closing the case, compare the result with your broader CometAPI Cost Control Packet for AI API Token Budgets . The goal is a traceable explanation, not a confident number unsupported by the available records.

Use Change Control Evidence for AI API Token Budgets as the next comparison point. Keep Trace CometAPI Cost and Usage for Token Budgets nearby for setup and permission checks.

Sources checked

• CometAPI documentation - accessed 2026-07-18; purpose: verify current CometAPI documentation navigation.

• CometAPI pricing documentation - accessed 2026-07-18; purpose: verify pricing documentation boundaries.

• CometAPI help center - accessed 2026-07-18; purpose: verify support and escalation documentation areas.

• FinOps Allocation - accessed 2026-07-18; purpose: support general cost ownership, tagging, shared-cost, and accountability guidance without implying CometAPI-specific billing behavior.

Contract details to verify

FAQ

What should a pricing dispute packet contain?

Include the date range, sanitized request reference, service or model label, relevant usage or charge evidence, the public pricing source reviewed, access date, ownership mapping, and a short description of the difference. Keep credentials and full request content out of the packet.

Should I rely on a general discount statement?

No. Use the current pricing documentation for the applicable service and check for model-specific, account-specific, multiplier, or published adjustment information before concluding that a charge is incorrect.

What if the request record and pricing page do not explain the difference?

Record the unresolved fields, preserve the clean source links and access date, and send the redacted evidence to support or the responsible finance owner. Avoid filling gaps with guessed prices, limits, billing fields, or account behavior.

Can a smoke test prove the final bill?

No. A smoke test can confirm that a documented request path works and that the evidence can be recorded. It cannot by itself establish an account-specific invoice, commercial adjustment, or undocumented billing rule.

How should shared usage be assigned?

Use the strongest available ownership metadata, such as an account, project, team, cost center, tag, label, or documented shared-cost rule. If the usage cannot be assigned reliably, mark ownership unresolved and make that limitation part of the support question.

What should be redacted before escalation?

Redact live credentials, full prompts, private responses, unnecessary personal data, and unrelated account identifiers. Retain only the sanitized request reference, service label, date range, outcome, comparison basis, and evidence needed to investigate the discrepancy.