CometAPI

What is CometAPI?

CometAPI is a multi-model API aggregation platform designed for developers and enterprises; it uses a single set of accounts, keys, and billing mechanisms to connect text, image, video, and audio models from different vendors. Its main purpose is to address the issue of fragmented interface formats, keys, billing systems, and switching logic associated with various models.

The product’s information page states that CometAPI was founded by Sonic in January 2025, and its services are intended for professional users around the world; the applicable terms are governed by Hong Kong law. The current public page does not reveal the full name of the legal entity responsible for its operation, so businesses should verify the contracting party in the contracts, invoices, and data processing documents when placing orders.

Main functions

Unified model directory and interfaces

• Multiple providers’ models can be invoked using a single CometAPI key, covering tasks such as dialogue, reasoning, programming, image generation and analysis, video, speech, and music.
• The public model catalog provides information such as model identifiers, providers, capabilities, available endpoints, and billing details; applications can query this catalog before running.
• Common text, image, audio, and video workflows use an OpenAI-compatible request format; for projects that already have an OpenAI SDK, it is usually sufficient to replace the base address, keys, and model identifiers in order to start migration testing.
• Not all models support exactly the same parameters, input formats, or output structures; it is necessary to consult the documentation related to a particular model before integrating it, and one cannot simply replace the model’s name.

Text, image, video, and audio capabilities

Model switching and fault fallback

• The application can switch from the main model to a compatible backup model, while keeping the same key and interface address.
• The official documentation recommends implementing fallback measures only in cases of connection failures, timeouts, rate limits, and temporary server errors; parameter errors, key errors, and unsupported fields should be corrected directly.
• If it is necessary to revert to the direct connection provided by the model vendor, a separate vendor account, keys, budget, and model identifier are required; the costs associated with this direct connection will also be charged separately.
• When moving between different model families, it is necessary to standardize the input and output fields, and to verify essential capabilities such as tool invocation, visualization, context length, and structured output.

Asynchronous tasks, polling, and callbacks

• After a video of equal length is created, a task identifier is returned; the application can then poll the task status until it succeeds, fails, or is canceled.
• A callback address can be configured only if the selected endpoint explicitly supports it; the way callbacks are handled varies among different providers, so the application should save the original events and normalize them on its own.
• Polling should serve as the basis for determining the final status in the event of a loss callback; the handling of such callbacks must be idempotent, using task identifiers to prevent duplicate notifications from leading to repeated data entries.
• The completed results may be returned through the result field or a content download endpoint; the specific format is determined by the model page.

Workspace and team management

• Workspace is used to manage members within an organization; Owners and Admins can invite or remove members, while Members can view the list of members.
• The workspace does not hold Credits on its own; members request to use the organization’s balance. Only the Organization Owner can top up funds, set up automatic top-ups, or exchange balance codes.
• The invitation expires after 24 hours, and when a member is removed, the API key records created by that member in the workspace are deleted as well.
• The team should create separate keys for the environment and the services, and implement limits on usage, key rotation, and procedures for handling employee departures; multiple people should not share the same long-term key.

Complete integration process

1. Register and log in to the console, first check the current model directory, the available endpoints, and the billing units, then select the primary model along with alternative models that have similar capabilities.
2. Create API keys with clear names, and set maximum usage limits per project; copy them and store them in the server’s key management system or as environment variables.
3. Replace the base URL and keys of the interface in the existing OpenAI client, or install the official SDK and then enter the exact model identifier provided in the directory.
4. Use short prompts for minimal calls, and record the response content, model identifier, Token usage, latency, and request identifier to verify that the request format is correct.
5. Depending on the business requirements, outputs in stream format, structured results, images, or asynchronous media streams may be generated; do not send the same set of parameters to models that do not support such outputs.
6. Exponential backoff, random jitter, and a concurrency limit are implemented to control traffic volume and handle temporary errors; retries are stopped for invalid requests and authentication failures.
7. Check the balance and usage in the console, and set budgets, key quotas, and auto-recharge thresholds based on the actual call records.
8. Before going live, test the primary model, the backup model, as well as the necessary direct vendor connection for fallback purposes; simultaneously set up alerts for model deactivation, price changes, and abnormal billing.

Developing interfaces and SDKs

The official Node.js and TypeScript SDKs are intended for use on the server side; it is explicitly advised not to store long-term keys in browser code, logs, screenshots, or public repositories. The current 0.1.x version supports task completion, Responses, and a list of models, while features such as handling images, videos, audio, batch processing, fine-tuning, and real-time operations are not part of the default capabilities provided by this SDK.

Prices and billing methods

CometAPI uses a pay-as-you-go model based on prepaid Credits; there are no fixed monthly fees, minimum spending requirements, or subscription charges. After a user top-ups funds, those funds are deducted according to the actual number of Tokens, assets generated, segments created, or duration of use, and the balance in the account does not expire as long as it remains valid.

Pricing methods for different models

The price page displays the current unit price for different models; the prices of these models, as well as those set by the manufacturers, can change over time. The budget should be estimated using the current input price, output price, or task unit price associated with the same model, and it should be adjusted based on the actual invoice after the task is completed.

Automatic top-up and failed requests

• Users can set up automatic top-ups via Stripe when the balance in their account falls below a certain threshold, and they can modify or disable these settings at any time.
• Requests that are rejected due to parameters or authentication before being forwarded by the gateway are not charged, nor are requests that return server errors from the upstream source.
• Stream generation is interrupted once the content has been returned, and billing is typically based on the number of tokens generated; requests that are completed successfully but whose results do not meet the expected standards are billed in full.
• When the balance is insufficient or the payment fails, the platform can suspend or restrict the services; the production system should not rely solely on automatic top-ups to ensure continuity.

Refund rules

• Credits that have been used or consumed, as well as API calls and computation time, are non-refundable; the remaining balance cannot be transferred or exchanged for cash.
• If no Credits have been used, a written request can be submitted; however, approval is at the discretion of CometAPI, and a refund is not guaranteed by default.
• The application should include the amount topped up, the date of purchase, the current unused balance, and the reason for the request; the refund policy states that a response is usually given within 5 working days.
• The refund, once approved, will be issued back using the original payment method; any processing fees that cannot be refunded by the payment service provider, bank, or intermediary may be deducted.
• Any dispute regarding a suspected erroneous charge must be raised within 30 days from the date of the charge; failure to do so may result in the charge being considered accepted.

Suitable for users and scenarios

• Application development teams looking to use a set of interfaces to compare and switch between multiple models.
• Product teams need to dynamically select products with the appropriate cost and capabilities in areas such as customer service, content, search, programming, or proxy systems.
• Creative technology teams that generate images, short videos, voiceovers, or music in bulk, while aiming to have a unified balance and billing system.
• Enterprise R&D departments that need to assign workspaces to their members, share the organization’s budget, and manage keys in a centralized manner.
• Infrastructure teams that require multi-model fallback or wish to reduce reliance on infrastructure provided by a single model vendor.

Advantages and capabilities boundaries

• Unified keys, directories, and billing can reduce redundant access, but the aggregation layer does not eliminate the differences among various models in terms of parameters, content policies, capabilities, and output quality.
• The platform supports fallback within the model, but error classification, idempotency, queues, timeouts, and direct connection to the vendor must still be designed by the application itself.
• The throttling limits are influenced by the account, the model, the routing mechanism, and the capacity of upstream systems; the high capacity values mentioned in promotional materials should not replace actual performance testing or the commitments outlined in contracts.
• The number of available models and their specific versions are subject to change; in a production environment, it is necessary to use fixed model identifiers and to monitor any announcements regarding model discontinuation.
• The model’s outputs may be inaccurate, infringe on rights, or not suitable for business use; therefore, users still need to conduct checks regarding facts, security, copyrights, and compliance.
• The services cannot be resold, relicensed, or redistributed without written authorization; if a business platform wishes to provide API capabilities to its downstream customers, it must first determine the appropriate method of authorization.

Privacy, Security, and Compliance

• The privacy policy states that CometAPI does not collect, store, or record prompts, inputs, outputs, or conversation contents, nor does it save such information in its own database.
• Requests are still routed in real time to the actual model providers to generate results; therefore, the data processing, retention, and content policies of each upstream provider must still be examined separately.
• The platform collects limited information such as IP addresses, time stamps, request frequency, browser type, device details, and access records, for purposes related to security, compliance, analysis, and service optimization.
• Account registration may collect a username and email address; when logging in using GitHub or Google, the username and email address used for authentication are obtained with the user’s consent.
• The platform states that it does not sell, rent, or trade personal information, but may disclose such information under legal or regulatory requirements; it also claims to take reasonable technical and organizational measures yet cannot guarantee absolute security.
• The company lists SOC 2 Type II as an item on its roadmap for future implementation; therefore, it cannot be concluded that the platform already holds this certification.

Security recommendations for API keys

1. Create separate keys for development, testing, and production, set appropriate limits for them, and store them only in server-side environment variables or key management systems.
2. It is prohibited to write keys in browser packages, mobile clients, public code repositories, logs, screenshots, or support tickets.
3. The log retains only troubleshooting fields such as the model identifier, status, latency, and request identifier; it does not store keys or unnecessary original user text.
4. Upon detecting a leak, the key is immediately revoked and replaced, while abnormal usage, automatic top-ups, and member permissions are checked.

Open-source status and platform support

Summary

CometAPI is suitable for development teams that need to quickly access multiple models, maintain a unified balance of resources, and retain the ability to switch between models. Its actual value depends on whether the target models are stable and available, whether the interfaces are fully compatible, and whether the team can manage costs, keys, retry attempts, and related policies effectively.

When starting to use it, it is advisable to first carry out the minimal number of calls using trial credits, and then use actual business data to assess quality, latency, and costs. Before preparing for production deployment or making large top-ups, it is also necessary to verify the model’s lifecycle, the level of service provided, the parties involved in the agreement, the conditions for refunds, and the requirements regarding upstream data processing.