CometAPI pricing reconciliation failure checks

Last reviewed: 2026-05-09

Who this is for: FinOps, platform, and API operations teams that already send production traffic through CometAPI and need a repeatable way to find reconciliation errors before cost reports, customer chargebacks, or budget alerts are published.

CometAPI pricing reconciliation should be treated as a failure-analysis workflow, not just a spreadsheet refresh. The goal is to prove that the usage you recorded, the pricing rules you applied, and the totals you reported are all based on the same contract details, time window, model identifiers, and retry behavior.

For broader operating context, keep this checklist connected to your AI cost-control runbook at /sites/ai-cost-controls/ and your publication or change-control process at /sites/ai-cost-controls/editorial/.

Key takeaways

• Reconcile by failure mode: missing requests, duplicated retries, wrong model mapping, stale pricing, token-field drift, timezone mismatch, and unclassified errors.
• Do not hard-code prices from memory. Treat the CometAPI pricing documentation as the source to verify before each billing-period close: CometAPI pricing documentation.
• Do not assume endpoint paths, headers, response fields, or rate-limit behavior from another provider. Verify the active API contract against the CometAPI docs: CometAPI API documentation.
• Keep a dated reconciliation evidence pack: API request logs, response usage fields, pricing snapshot, aggregation query, exceptions list, and reviewer sign-off.
• Treat thresholds in this article as examples to tune for your workload, not universal pass/fail rules.

Concise definition

A CometAPI pricing reconciliation checklist is an operator procedure for comparing CometAPI request records, response usage data, internal token counts, pricing inputs, retry behavior, and invoice-facing totals so that cost reports can be explained and reproduced.

In this article, “failure mode” means a specific way reconciliation can be wrong even when the API calls themselves succeeded.

Failure-mode checklist

1. Pricing snapshot is stale or undocumented

Failure mode: Your cost job applies a price table copied from an earlier billing period, a vendor announcement, or an internal wiki page instead of the current documented CometAPI pricing source.

Validation steps:

1. Open the CometAPI pricing page before the close process: https://apidoc.cometapi.com/about-pricing-873788m0.
2. Save a dated pricing snapshot or reference record in your reconciliation evidence folder.
3. Record the access date, reviewer, and the exact pricing assumptions used.
4. Compare every production model identifier in logs against the pricing source.
5. Mark any unmapped model as “unpriced” rather than assigning a default rate.

Operator note: If your organization stores pricing in a database, require a pricing_source_url, pricing_reviewed_at, and pricing_approved_by field. That makes stale pricing visible during audit.

2. Model names do not map cleanly to pricing rows

Failure mode: Application logs contain aliases, routing labels, or internal names that do not match the model identifiers used in the pricing source.

Examples:

• primary-chat
• cheap-router
• vendor-model-latest
• model_from_env
• A deprecated or renamed model alias

Validation steps:

1. Export distinct model identifiers from production logs for the billing period.
2. Export distinct model identifiers from the cost calculator.
3. Join both lists and flag:
   • models in logs but not in pricing,
   • models in pricing but not in logs,
   • aliases that resolve to more than one billable model,
   • requests where the model is blank or redacted.
4. For every alias, store the resolved upstream model, effective date, and approval ticket.
5. Re-run the join after any routing or model-selection change.

Suggested exception table columns:

3. Successful retries are double-counted

Failure mode: A timeout or network retry creates multiple CometAPI requests, but the user-facing transaction is counted once. Depending on what actually reached the API and what returned usage fields, reconciliation may undercount or overcount.

Validation steps:

1. Add a stable client-side idempotency or request correlation ID to logs where your API contract allows it.
2. Store one record per outbound attempt, not only one record per user action.
3. Separate these counts:
   • user actions,
   • API attempts,
   • successful API responses,
   • failed API responses,
   • responses with usage fields,
   • responses without usage fields.
4. Review retry spikes by endpoint and model.
5. For retry storms, reconcile from API-attempt records rather than user-action records.

Example threshold to tune: alert if api_attempts / user_actions exceeds your normal baseline by more than 10–20% for a model, route, or tenant. This is only an example; tune it to your application’s retry policy and traffic pattern.

4. Failed requests are handled inconsistently

Failure mode: Some failed requests are included in usage exports while others are excluded, or your internal system assumes all non-2xx responses have zero billable impact without verifying the contract.

Validation steps:

1. Pull error counts by HTTP status, endpoint, model, and client application.
2. Identify whether failed responses include usage-like fields.
3. Confirm billing assumptions against the CometAPI documentation and support resources, not against another API provider’s behavior:
   • API docs: https://apidoc.cometapi.com/
   • Help center: https://apidoc.cometapi.com/help-center
4. Create a reconciliation rule for each error class:
   • excluded from cost,
   • included if usage fields are present,
   • manually reviewed,
   • unknown until support confirms.
5. Keep unknowns out of automated chargebacks until resolved.

5. Token fields are missing, renamed, or parsed incorrectly

Failure mode: Your calculator expects fields such as prompt tokens, completion tokens, total tokens, cached tokens, reasoning tokens, or image/audio units, but the response body differs by endpoint, model, or response type.

Validation steps:

1. Save sanitized raw responses for each endpoint and model class used in production.
2. Validate parser behavior when fields are:
   • present and numeric,
   • present but null,
   • absent,
   • nested differently,
   • represented as another unit.
3. Reject silent defaulting to zero unless reviewed.
4. Add parser tests using real sanitized response shapes.
5. Compare application-side token estimates to API-returned usage fields and flag large variance.

Example variance rule to tune: manually review records where internal token estimates differ from response usage by more than a workload-specific tolerance. Do not assume a universal tolerance.

6. Timezone and billing-window boundaries are misaligned

Failure mode: Logs are grouped in UTC, dashboards in local time, and billing exports in another window. Month-end requests near midnight are assigned to the wrong period.

Validation steps:

1. Record all raw event timestamps in UTC.
2. Document the billing-period timezone used by your reconciliation process.
3. Run a boundary report for the first and last 24 hours of the period.
4. Compare request counts by hour across:
   • application logs,
   • API gateway logs,
   • cost calculator inputs,
   • invoice or billing export, if available.
5. Do not backfill late-arriving logs without marking the reconciliation version.

7. Streaming usage is captured differently from non-streaming usage

Failure mode: Streaming responses may be logged before final usage information is available, or a client disconnect can create an incomplete application record.

Validation steps:

1. Separate streaming and non-streaming requests in your reconciliation query.
2. Confirm where final usage data is available for streaming responses in your implementation.
3. Track client disconnects, server timeouts, and partial responses separately.
4. Compare streamed completion counts against user-visible completions.
5. Require manual review for streamed requests that have no final usage record.

8. Multi-tenant attribution loses shared overhead

Failure mode: The total cost reconciles globally, but tenant-level chargebacks do not sum cleanly because shared prompts, system messages, retries, cache behavior, or routing overhead are allocated inconsistently.

Validation steps:

1. Require tenant, workspace, or cost-center identifiers at request time.
2. Track unattributed usage as a separate bucket.
3. Allocate shared overhead using a documented method.
4. Verify that tenant totals plus unattributed totals equal the reconciled global total.
5. Publish allocation rules next to the monthly cost report.

Useful internal reference: collect recurring exceptions in the operations archive at /sites/ai-cost-controls/posts/.

Contract details to verify

Before you finalize reconciliation logic, verify these contract details against the active CometAPI documentation and your own account configuration.

Sanitized pricing-check request example

Use a small, controlled request to confirm that your logging and parser capture the fields needed for reconciliation. Replace the endpoint path with the exact path from the CometAPI API documentation before use.

curl -sS “$COMETAPI_CHAT_COMPLETIONS_URL”
-H “Authorization: Bearer $COMETAPI_API_KEY”
-H “Content-Type: application/json”
-H “X-Request-Source: cost-reconciliation-check”
-d ‘{ “model”: “REPLACE_WITH_VERIFIED_MODEL_ID”, “messages”: [ { “role”: “system”, “content”: “You are validating cost logging. Keep the response short.” }, { “role”: “user”, “content”: “Reply with one short sentence.” } ], “stream”: false, “metadata”: { “cost_check_id”: “recon-YYYYMMDD-001”, “tenant”: “internal-finops-test” } }’

Expected validation, not guaranteed field names:

1. The outbound request is logged with timestamp, model, endpoint, tenant, and correlation ID.
2. The response is logged with status code, request ID if returned, model if returned, and usage fields if returned.
3. The pricing calculator either maps the model to a verified pricing row or rejects it as unmapped.
4. The reconciliation job records the pricing source URL and review date.
5. The test record is excluded from customer chargebacks or assigned to an internal test cost center.

Practical reconciliation workflow

Step 1: Build the evidence pack

For each billing period, store:

• Pricing source URL and access date.
• Export of production request logs.
• Export of response usage fields.
• Distinct model list.
• Distinct endpoint list.
• Retry and error summary.
• Parser version or cost-calculator commit hash.
• Manual exception list.
• Reviewer sign-off.

Step 2: Run count reconciliation first

Before applying prices, reconcile counts.

Minimum count checks:

Step 3: Run unit reconciliation

After counts pass, reconcile usage units.

Recommended checks:

• Sum prompt/input units by model.
• Sum completion/output units by model.
• Sum total units by model.
• Separate multimodal or non-token units if your endpoints use them.
• Separate streaming from non-streaming.
• Separate production, test, and internal validation traffic.

Do not collapse unknown units into token totals. Keep them as a separate exception class until the relevant CometAPI documentation or support answer confirms how they should be priced.

Step 4: Apply pricing only to verified rows

For each row, require:

• model_id
• usage_unit
• quantity
• price_source
• price_reviewed_at
• pricing_rule_version
• cost_center
• reconciliation_period

Rows that fail those requirements should not flow into automated customer chargebacks.

Step 5: Publish with exceptions, not hidden adjustments

A useful monthly cost report includes:

• Reconciled total.
• Total excluded as test/internal traffic.
• Total in manual review.
• Largest model-level changes from prior period.
• Retry-driven cost increase, if measurable.
• Unmapped or newly observed models.
• Known parser or export limitations.

Review queries to add to your runbook

Adapt these checks to your warehouse schema:

FAQ

Should I reconcile from invoice totals or from API logs?

Use both. API logs explain usage behavior; invoice or account billing data, when available, is the financial reference. If they differ, preserve the difference as an exception instead of forcing one side to match silently.

Can I hard-code CometAPI pricing into my application?

Avoid hard-coding pricing into application code. Keep pricing in a reviewed configuration or table with source URL, access date, effective date, and approver. Verify current pricing against the CometAPI pricing documentation before closing a period: https://apidoc.cometapi.com/about-pricing-873788m0.

What should I do with requests that have no usage fields?

Classify them. Common buckets are failed request, streaming gap, parser mismatch, endpoint that reports different units, or logging loss. Do not default them to zero cost unless your verified contract and billing evidence support that rule.

How often should the checklist run?

Run a lightweight version daily for anomaly detection and a full version before billing close. Also run it after model-routing changes, pricing updates, endpoint migrations, parser changes, or retry-policy changes.

What is the most common reconciliation mistake?

The most damaging mistake is mixing assumptions from multiple sources: one source for model names, another for prices, another for token units, and another for error behavior. Reconciliation should cite the active CometAPI docs, your own logs, and dated pricing evidence.

Should test requests be included?

They should be logged and reconciled, but assigned to an internal test cost center or excluded from customer chargebacks according to a documented rule. Hidden test traffic makes totals harder to reproduce.

What if the API docs do not answer a billing edge case?

Record the case, link the affected request IDs, estimate the maximum exposure, and ask through the CometAPI help or support channel: https://apidoc.cometapi.com/help-center. Keep the item in manual review until resolved.

Sources checked