Source pack

Source-pack note: the prompt provides evidence URLs but does not quote exact endpoint paths, auth header names, model IDs, prices, billing fields, or rate limits. This draft therefore treats those values as items to verify from the linked CometAPI sources rather than asserting them.

Intent brief

• Audience: operators, FinOps engineers, platform engineers, and AI product owners who need to reconcile CometAPI usage against current pricing references.
• Primary task: build a repeatable reconciliation pass that compares documented pricing, request-level usage records, and the internal cost ledger.
• Decision supported: whether today’s cost records are accurate enough to approve, investigate, or hold for vendor/source review.
• Not in scope: vendor ranking, guaranteed savings claims, live pricing claims, hard-coded endpoint paths, or undocumented billing assumptions.
• Success criteria: a reconciler can identify the source of truth for prices, map model usage to a verified pricing unit, preserve evidence for changes, and escalate mismatches without relying on guessed API contract details.

CometAPI Pricing Reconciliation Checklist

Last reviewed: 2026-06-02.

Who this is for: This checklist is for teams that already route AI requests through CometAPI or are evaluating CometAPI and need an operator-safe way to reconcile pricing references with internal usage and cost records.

For more AI budget operations material, start at the AI cost controls home or browse the AI cost controls post archive.

Key takeaways

• Treat CometAPI pricing reconciliation as a three-way match: pricing source, request usage record, and internal cost ledger.
• Do not hard-code endpoint paths, auth headers, model IDs, prices, or billing fields unless they are verified from the current CometAPI API documentation and CometAPI pricing documentation.
• Capture a timestamped pricing snapshot before comparing usage, because public pricing references can change.
• Separate “usage extraction” errors from “pricing interpretation” errors; they require different owners.
• Reconciliation is only complete when each variance has an evidence link, owner, and disposition: accepted, corrected, or escalated.

Definition: pricing reconciliation

CometAPI pricing reconciliation is the operational process of matching your internal record of CometAPI requests and model usage to the current CometAPI pricing references, then comparing the calculated amount with your ledger, invoice export, or budget dashboard.

In practice, reconciliation answers four questions:

1. Which pricing source did we use?
2. Which requests or usage records were included?
3. Which model, unit, and rate assumptions were applied?
4. Which differences require correction or escalation?

The operating principle: reconcile evidence, not memory

A reliable reconciliation pass should begin with source capture, not spreadsheet formulas.

Use the CometAPI pricing documentation and the CometAPI public pricing page as the sources to verify current pricing information. Use the CometAPI API documentation home as the entry point for API contract details such as endpoint paths, authentication, supported request fields, response fields, and error behavior.

Because this draft does not include quoted values from those sources, every exact contract value below is framed as a verification task.

Daily reconciliation flow

1. Freeze the pricing source snapshot

Before calculating any costs, capture the pricing source you used.

Minimum evidence to store:

• pricing source URL;
• access timestamp;
• model or SKU identifier as written in the source;
• pricing unit as written in the source;
• currency or billing denomination, if documented;
• any documented multipliers, tiers, discounts, or modality-specific rules;
• reviewer initials or automation job ID.

Avoid copying only the numeric value into a spreadsheet. Store enough context to re-check the value later against the CometAPI pricing documentation and public pricing page.

2. Normalize usage records before applying prices

Do not apply pricing until usage records are normalized.

For each request or aggregated usage row, verify:

• the model identifier is a documented, valid model identifier;
• the usage unit in your log matches the unit required by the pricing source;
• retries, streaming responses, failed calls, and partial responses are classified consistently;
• test traffic and production traffic are separated;
• internal customer, workspace, project, or cost-center labels are present;
• timestamps are in one reporting timezone.

If your platform stores only request counts, but the pricing source requires a different unit, mark that period as not reconcilable until the missing usage dimension is recovered or explicitly estimated and approved.

3. Match model names to pricing rows

Model-name drift is a common reconciliation problem. Operators should maintain a small mapping table that connects internal names to source names.

Do not silently merge two source model IDs into one cost bucket unless finance and engineering both approve the mapping.

4. Calculate expected cost in a reproducible job

The calculation should be rerunnable from stored inputs:

• usage export;
• pricing snapshot;
• model mapping table;
• exclusion list;
• calculation version;
• rounding rule, if one is used;
• output ledger.

Use one calculation version per reconciliation period. If you fix a bug, rerun the period and preserve both the original and corrected outputs.

5. Compare against the ledger

Compare the calculated result to the system of record your team uses for budget reporting.

Use variance buckets rather than one generic “mismatch” state:

Treat numerical thresholds as local policy examples to tune. Do not assume a universal acceptable variance unless your contract or finance policy defines one.

Contract details to verify

Use this table before you automate reconciliation or build a cost dashboard. The “value to verify” column intentionally avoids undocumented specifics.

Sanitized pricing-source capture example

The example below shows the shape of a safe capture job. Replace every placeholder with values verified from CometAPI documentation before running it.

#!/usr/bin/env bash
set -euo pipefail

ACCESS_TS="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"

curl --fail --silent --show-error \
  --request GET \
  "<COMETAPI_BASE_URL_FROM_DOCS><COMETAPI_PRICING_PATH_FROM_DOCS>" \
  --header "<AUTH_HEADER_FROM_DOCS>: <COMETAPI_API_KEY>" \
  --output "cometapi-pricing-snapshot-${ACCESS_TS}.json"

cat > "cometapi-pricing-snapshot-${ACCESS_TS}.meta.json" <<JSON
{
  "source": "<COMETAPI_PRICING_URL_FROM_DOCS>",
  "accessed_at": "${ACCESS_TS}",
  "base_url_verified_from": "https://apidoc.cometapi.com/",
  "pricing_reference_verified_from": "https://apidoc.cometapi.com/pricing/about-pricing",
  "public_pricing_cross_check": "https://www.cometapi.com/pricing/",
  "operator": "<RECONCILIATION_JOB_OR_REVIEWER>",
  "notes": "All endpoint paths, auth headers, pricing units, and model IDs must be verified from current CometAPI sources before use."
}
JSON

If CometAPI documentation does not expose a machine-readable pricing endpoint for your account, replace the curl step with a controlled manual snapshot process: save the source page, record the timestamp, record the reviewer, and attach it to the reconciliation run.

Practical validation steps

Validate the source snapshot

Before using a pricing snapshot:

1. Open the CometAPI pricing documentation.
2. Open the CometAPI public pricing page.
3. Confirm the model names and pricing units you plan to use.
4. Record any difference between the documentation and public page.
5. If the two sources conflict, pause automated reconciliation and assign an owner to resolve the source conflict.

Validate usage completeness

For the reconciliation period:

1. Count total requests by day.
2. Count usage rows by model.
3. Count failed, retried, and timed-out requests separately.
4. Confirm the export window matches the ledger window.
5. Confirm no staging or test keys are mixed into production cost reporting.
6. Sample several request IDs and verify that usage fields came from documented response fields.

Validate model mapping

For every model in the usage export:

1. Check whether the exact model ID appears in the verified source snapshot.
2. If the usage export contains an alias, resolve it through an approved mapping table.
3. If the model is not found, classify the usage as unmapped and exclude it from final approval until reviewed.
4. Record the reviewer and disposition.

Validate the calculated ledger

For each cost-center or project total:

1. Recompute expected cost from the raw usage export and pricing snapshot.
2. Compare the result to the internal ledger.
3. Group mismatches by variance bucket.
4. Attach evidence links for every accepted exception.
5. Require sign-off for any manual adjustment.

Recommended reconciliation artifacts

A mature operating process should leave behind these artifacts for every period:

• pricing_snapshot: source URL, access date, model ID, unit, and verified price value.
• usage_export: request or aggregate usage rows for the period.
• model_mapping: internal aliases to verified source model IDs.
• calculation_manifest: code version, rounding rule, exclusions, and run ID.
• variance_report: grouped mismatches with owner and status.
• approval_record: final reviewer, date, and exceptions.

These artifacts make it easier to refresh dashboards, answer invoice questions, and identify whether a variance came from pricing changes, integration changes, or reporting gaps.

Common failure modes

Using stale pricing values

If a spreadsheet contains copied prices with no source timestamp, the team cannot prove which value was used. Always link each rate to a source snapshot.

Mixing model aliases with source model IDs

Aliases are convenient for application code but risky for finance. Keep aliases out of the final pricing join unless they resolve through an approved mapping table.

Treating failed calls as automatically free or billable

Do not assume failed, retried, or partial calls have a specific billing outcome unless the current CometAPI sources or account terms support that interpretation. Classify them separately until verified.

Reconciling request counts instead of billable units

A request count is rarely enough for AI cost control. Verify the unit required by the pricing source and the unit emitted by your usage logs.

Ignoring time boundaries

Usage export windows, pricing effective times, invoice periods, and ledger close periods can differ. Record the timezone and period boundaries for each reconciliation run.

Operator checklist

Use this as the approval checklist before closing a reconciliation period.

• Pricing source URLs were captured with access timestamp.
• Public pricing and pricing documentation were cross-checked.
• API contract assumptions were verified from the current API docs.
• Usage export covers the full reporting period.
• Test, staging, and production usage are separated.
• Failed, retried, and partial requests are classified separately.
• Every model ID maps to a verified pricing row.
• Unmapped models are excluded or explicitly approved.
• Calculation code version is recorded.
• Rounding and aggregation rules are documented.
• Variances are bucketed by cause.
• Manual adjustments include owner, reason, and evidence.
• Final report links to the pricing snapshot and usage export.

When to escalate

Escalate instead of forcing the numbers to match when:

• CometAPI pricing sources appear to disagree;
• a model appears in usage but not in the verified pricing snapshot;
• usage fields needed for pricing are missing from logs;
• response or error behavior affects billing interpretation;
• ledger totals differ in a way that cannot be explained by timing, rounding, or known exclusions;
• your team cannot identify the source used for a historical price.

The goal is not to make every variance disappear. The goal is to make every variance explainable and evidence-backed.

CTA

If your team is evaluating a unified API workflow and wants to compare implementation options, you can start with CometAPI. Verify current pricing, endpoint, and billing details from the official CometAPI sources before committing production controls.

FAQ

What is the first thing to check in a CometAPI pricing reconciliation?

Start with the pricing source snapshot. Confirm which CometAPI pricing source was used, when it was accessed, which model IDs were included, and which pricing unit was applied.

Should I use the public pricing page or the API documentation?

Use both when available. The CometAPI pricing documentation is the primary place to verify pricing rules, while the public pricing page is useful for cross-checking visible pricing information. If they appear to differ, pause and review before closing the reconciliation.

Can I hard-code CometAPI endpoint paths in my reconciler?

Only after verifying them from the current CometAPI API documentation. This draft intentionally uses placeholders because the prompt does not quote exact endpoint paths.

How should I handle failed or retried requests?

Classify them separately. Do not assume they are free or billable unless the current CometAPI documentation, account terms, or billing evidence supports that conclusion.

What if a model appears in usage but not in the pricing snapshot?

Mark it as unmapped. Assign an owner to verify the model ID against CometAPI sources, then rerun the calculation after the mapping is approved.

How often should pricing reconciliation run?

Run it at the cadence your budget process requires. Many teams use a daily operational check plus a stricter close-period review, but the exact cadence should match your finance controls and traffic volume.

What evidence should be attached to a variance?

Attach the pricing snapshot, usage rows, model mapping, calculation version, and a short explanation of the variance bucket. If a manual adjustment is made, include the approver and reason.

Sources checked