Last reviewed: 2026-07-05
Direct answer
Model price intake notes should record where the current CometAPI pricing evidence came from, which billing-unit area changed, who owns the forecast impact, and which assumptions are still unverified. The note should not copy old forecast numbers forward unless the linked pricing, support, and account-owned evidence still support them.
A practical intake record has five parts: a dated source snapshot, the affected model or workload category, the forecast owner, the expected cost-driver change, and the follow-up evidence needed before the forecast changes. For a closely related intake pattern, see Price Change Intake Workflow for AI API Budget Owners . For the ownership side of the same control, pair the note with Allocation Owner Mapping for AI API Costs .
Use CometAPI when you need a single place to compare model access and pricing evidence before forecast work: Start with CometAPI .
Operator workflow
Setup assumptions: the operator has read-only access to the current public pricing source, the CometAPI documentation pages used by the team, a dated forecast worksheet, and a cost-owner roster. Private credentials, request payloads, prompts, full generated responses, account balances, and payment records stay outside the public note. If a local test needs a credential, represent it only as <API_KEY_PLACEHOLDER> in examples and keep the real value in the team-owned secret store.
Happy-path request plan: open the current pricing documentation, the public pricing page, and the support page on the same day. Record each URL and access date. Identify whether the forecast assumption depends on token billing, per-call billing, account-level discounting, support guidance, or a workload classification. Then attach the note to the forecast change record with the cost owner, affected workload, and decision status.
Error-path check: if the pricing page, documentation page, or support guidance cannot be opened, mark the intake as blocked for that source and keep the prior forecast assumption unchanged until a fresh public or account-owned source is available. If the public documentation and the private worksheet disagree, record the disagreement and ask the owner to reconcile it before the new assumption affects budget planning.
Minimum assertions: the source URL was reachable, the access date was recorded, the affected workload owner was named, the billing area was labeled, the assumption status was either verified or marked for follow-up, and unsupported price values were excluded.
Pass/fail logging fields: intake_date, source_url, source_access_status, workload_owner, billing_area, forecast_assumption, evidence_status, follow_up_owner, and decision.
What not to assert: do not assert exact model prices, account discounts, rate limits, quota behavior, uptime, model availability, final billing totals, or private support outcomes unless the cited source and account-owned evidence explicitly support them.
Sanitized log-record template:
intake_date: 2026-07-05
source_url: https://apidoc.cometapi.com/pricing/about-pricing
source_access_status: reachable
workload_owner: <TEAM_OR_SERVICE_PLACEHOLDER>
billing_area: <TOKEN_OR_CALL_OR_ACCOUNT_NOTE_PLACEHOLDER>
forecast_assumption: <SHORT_ASSUMPTION_PLACEHOLDER>
evidence_status: <VERIFIED_OR_NEEDS_FOLLOW_UP>
follow_up_owner: <OWNER_PLACEHOLDER>
decision: <ACCEPT_OR_HOLD>
Who this is for
This guide is for budget owners, FinOps analysts, platform operators, and engineering leads who update AI API forecasts after pricing documentation, support guidance, or workload assumptions change. It is especially useful when a forecast depends on CometAPI evidence but the team does not want unsupported values entering the planning sheet.
The workflow is intentionally narrow. It does not replace the pricing page, the account dashboard, or private commercial records. It gives operators a repeatable way to say what changed, where the evidence came from, who owns the effect, and what still needs confirmation. That makes it easier to review a forecast variance later without reconstructing the decision from chat messages or old spreadsheets.
Key takeaways
- Keep price intake notes evidence-first: source URL, access date, billing area, owner, and assumption status.
- Separate public pricing documentation from account-specific discounts, balances, orders, and commercial terms.
- Use FinOps allocation and unit-economics framing to connect model-price assumptions to teams, products, workloads, or business units.
- Hold the forecast change when the current source cannot be reached or when the note depends on unsupported exact values.
- Keep credentials, prompts, full responses, private billing exports, and real support case details out of the public intake note.
- Pair price intake with forecast review work such as Forecast Assumption Checklist for AI API Budgets before a planning number is accepted.
Sources checked
CometAPI help center - accessed 2026-07-05; purpose: verify support and escalation documentation areas.
CometAPI documentation - accessed 2026-07-05; purpose: verify current CometAPI documentation navigation.
CometAPI pricing documentation - accessed 2026-07-05; purpose: verify pricing documentation boundaries.
FinOps allocation capability - accessed 2026-07-05; purpose: verify cost allocation review context.
FinOps unit economics capability - accessed 2026-07-05; purpose: verify unit economics review context.
CometAPI public pricing page - accessed 2026-07-05; purpose: identify the public pricing page as the place operators should check for current pricing values without copying unsupported values here.
Contract details to verify
| Area | What to verify | Source URL | Accessed | Safe candidate wording |
|---|---|---|---|---|
| Support caveats | Whether support guidance mentions price adjustments, request-volume monitoring, maintenance windows, abnormal charges, recharge-credit handling, or when to contact customer service. | https://apidoc.cometapi.com/support/help-center | 2026-07-05 | “Escalate to support or hold the note when the change depends on account-specific handling.” |
| Documentation map | Which CometAPI documentation page should be used for model, setup, billing, usage, or cost-tracking context. | https://apidoc.cometapi.com/ | 2026-07-05 | “Use the current documentation map instead of stale saved links.” |
| Ownership | Which team, product, or service should own the forecast change. | https://www.finops.org/framework/capabilities/allocation/ | 2026-07-05 | “Attach each intake note to an owner before it affects shared budgets.” |
| Unit-cost framing | Which business metric or workload unit the price assumption affects. | https://www.finops.org/framework/capabilities/unit-economics/ | 2026-07-05 | “Translate source evidence into a unit-cost assumption only after the billing area is clear.” |
Failure modes
- Evidence gap: the operator cannot inspect the source page, account-owned note, forecast worksheet, or local command output that supports the change. The safe action is to stop and record the missing evidence instead of guessing.
- Scope drift: the note expands from price intake into endpoint migration, model selection, retry policy, or quota planning. Keep this record tied to price evidence and send adjacent questions to the right runbook.
- Environment mismatch: a local check uses different credentials, feature flags, workspace settings, or runtime assumptions than the hosted path. Record the mismatch before treating the result as proof.
- Unsupported fallback: the team changes models, endpoints, permissions, or retry behavior to make a forecast look acceptable without preserving the review boundary. Treat access and provider failures as operational blockers, not pricing evidence.
- Private-data leakage: a public note includes account balances, payment screenshots, support case numbers, full prompts, full responses, or real credentials. Replace those details with placeholders and keep the evidence in the private forecast packet.
- Weak handoff: the final note says the issue is resolved but omits the source URL, access date, owner, decision, and remaining uncertainty. That makes the next reviewer repeat the investigation.
Reader next step
Before changing the next AI API forecast, create one price intake row with the fields in the template above. Link the current CometAPI pricing documentation, the public pricing page if a current value must be inspected, and the relevant owner mapping. Then decide whether the row is ready to enter the forecast or should stay on hold. If the row depends on private discounts, support guidance, or account balances, keep those details in the private forecast packet and summarize only the decision status in the public note.
A useful first review is small: choose one workload, one model-price assumption, one owner, and one forecast period. Confirm that the assumption has a dated source and a clear billing-area label. If it does not, do not update the forecast yet. Send the owner to the pricing source, collect the missing evidence, and return to the forecast only after the assumption can be traced.
FAQ
Should the intake note include exact model prices?
Only when the operator is citing a current, reachable pricing source and the value is copied into a controlled forecast record. This guide avoids listing exact prices because they can change and may depend on account context.
What happens when CometAPI pricing documentation and a worksheet disagree?
Hold the forecast change, record the source URLs and access dates, and ask the forecast owner to reconcile the assumption before it enters the planning model. Do not average the values or choose the lower number without evidence.
Should private account discounts go into the public note?
No. Account-specific discounts, balances, orders, payment screenshots, and support cases belong in the private forecast record, not in a public operator guide.
Why include FinOps allocation in a model price intake note?
Allocation keeps the forecast change tied to an owner. Without ownership, a model-price change can look like a platform-level variance even when one product, team, or workload caused it.
How does unit economics help here?
Unit economics turns a price assumption into a workload question. Instead of only asking whether a model costs more or less, the operator can ask which product action, request class, user cohort, or business unit is affected.
When should a price intake row be rejected?
Reject or hold the row when the source is unreachable, the owner is missing, the billing area is unclear, the row contains private data that should not be public, or the requested forecast change depends on exact values that the cited evidence does not support.