CometAPI

Was ist CometAPI?

CometAPI ist eine mehrmodellbasierte API-Plattform für Entwickler und Unternehmen, die mithilfe eines Accounts, von Schlüsseln sowie eines Abrechnungssystems Modelle für Texte, Bilder, Videos und Audio von verschiedenen Anbietern verbindet. Sie löst hauptsächlich das Problem der unterschiedlichen Schnittstellformate, Schlüssel, Abrechnungsverfahren sowie Wechsellogiken der einzelnen Modelle.

Auf der Produktseite heißt es, dass CometAPI im Januar 2025 von Sonic gegründet wurde und sich an professionelle Nutzer auf der ganzen Welt richtet. Die allgemeinen Bedingungen unterliegen dem Recht Hongkongs. Auf der aktuellen öffentlichen Seite wird der vollständige Name des Unternehmens, das für den Betrieb verantwortlich ist, nicht angegeben. Bei Geschäftsabschlüssen sollte das Unternehmen den Vertragspartner in den Verträgen, Rechnungen sowie Dokumenten zur Datenverarbeitung genauer überprüfen.

Hauptfunktionen

Einheitliches Modellverzeichnis und Schnittstellen

• Über einen einzigen CometAPI-Schlüssel können Modelle mehrerer Anbieter aufgerufen werden, um Aufgaben wie Dialoge, Inferenz, Programmierung, Bildgenerierung und -analyse, Video, Sprache und Musik abzudecken.
• Der öffentliche Modellkatalog bietet Informationen zu den Modellen, ihren Anbietern, ihren Fähigkeiten, den verfügbaren Endpunkten sowie zu den Gebühren. Anwendungen können vor dem Start den aktuellen Katalog abfragen.
• Häufige Workflows für Texte, Bilder, Audiodaten und Videodateien nutzen ein mit OpenAI kompatibles Anfrageformat. Bei Projekten, die bereits über ein OpenAI SDK verfügen, reicht es in der Regel aus, die Basisadresse, den Schlüssel sowie die Modellidentifikation zu ersetzen, um mit den Migrationstests zu beginnen.
• Nicht jedes Modell unterstützt genau die gleichen Parameter, Eingaben oder Ausgabestrukturen. Vor der Verwendung muss man die Dokumentation zu den Endpunkten des Modells einsehen; es reicht nicht aus, nur den Namen des Modells zu ändern.

Funktionen für Texte, Bilder, Videos und Audio

Modellwechsel und Fehlerrückfall

• Die Anwendung kann unter Beibehaltung derselben Schlüssel und der gleichen Schnittstelle-Adresse das Hauptmodell durch ein kompatibles Ersatzmodell ersetzen.
• Die offiziellen Dokumente empfehlen, auf Rückfallmaßnahmen nur bei Verbindungsfehlern, Zeitüberschreitungen, Bandbreitenbeschränkungen und vorübergehenden Serverfehlern zurückzugreifen; Parameterfehler, Schlüsselfehler sowie nicht unterstützte Felder sollten direkt behoben werden.
• Um wieder auf die direkte Verbindung zum Modellhersteller zurückzukehren, sind ein separates Konto des Herstellers, ein Schlüssel, ein Budget sowie eine Modellidentifikation erforderlich. Die Kosten für die direkte Verbindung werden außerdem separat abgerechnet.
• Bei der Übertragung zwischen Modellfamilien müssen Eingangs- und Ausgabefelder vereinheitlicht werden, und es müssen notwendige Fähigkeiten wie Toolaufrufe, Visualisierung, Kontextlänge sowie strukturierte Ausgaben überprüft werden.

Asynchrone Aufgaben, Polling und Callbacks

• Nach der Erstellung einer Aufgabe mit gleichem Video-Länge wird eine Aufgaben-ID zurückgegeben. Die Anwendung kann den Status der Aufgabe abfragen, bis sie erfolgreich abgeschlossen ist, fehlschlägt oder storniert wird.
• Eine Callback-Adresse kann nur konfiguriert werden, wenn die ausgewählten Endpunkte dies ausdrücklich unterstützen; die Callback-Verarbeitung bei den verschiedenen Anbietern ist nicht vollständig einheitlich, daher sollte die Anwendung die ursprünglichen Ereignisse speichern und sie selbst normalisieren.
• Die Polling-Methoden sollten als Grundlage für den Endzustand im Falle eines fehlenden Callbacks dienen. Die Verarbeitung der Callbacks muss auf der Grundlage der Task-ID idempotent erfolgen, um zu vermeiden, dass mehrfache Benachrichtigungen zu wiederholten Einträgen führen.
• Das Ergebnis der Bearbeitung kann über das Ergebnisfeld oder den Endpunkt zum Herunterladen des Inhalts zurückgegeben werden; die genaue Form richtet sich nach der Seite des Modells.

Arbeitsbereich und Teammanagement

• Der Workspace dient zur Verwaltung der Mitglieder in einer Organisation. Owner und Admin können Mitglieder einladen oder entfernen, während die Mitglieder die Liste der Mitglieder einsehen können.
• Die Arbeitsbereiche verfügen nicht über eigene Credits; die Mitglieder bitten darum, den Kontostand der Organisation zu teilen. Nur der Organisator kann Credits aufladen, automatische Aufladungen einrichten oder Gutschriftscodes einsetzen.
• Die Einladung wird nach 24 Stunden ungültig. Wenn ein Mitglied entfernt wird, werden auch die API-Schlüssel, die es im Arbeitsbereich erstellt hat, gelöscht.
• Das Team sollte für Umwelt und Dienste jeweils eigene Schlüssel erstellen und diese mit Limitierungen, Rotation sowie Prozessen bei Austritten von Mitarbeitern verknüpfen; mehrere Personen sollten keinen einzigen langfristigen Schlüssel teilen.

Vollständiger Anmeldeprozess

1. Registrieren Sie sich und gehen Sie in die Konsole, um zunächst den aktuellen Modellkatalog, die verfügbaren Endpunkte sowie die Abrechnungseinheiten anzusehen. Wählen Sie anschließend das Hauptmodell sowie ein Ersatzmodell mit ähnlichen Fähigkeiten aus.
2. Erstellen Sie API-Schlüssel mit klaren Namen, für die Sie Obergrenzen pro Projekt festlegen können; kopieren Sie sie und speichern Sie sie im Schlüsselverwaltungssystem des Servers oder in Umgebungsvariablen.
3. Ersetzen Sie die Basis-Adresse und den Schlüssel der API im vorhandenen OpenAI-Client oder installieren Sie das offizielle SDK und geben Sie anschließend die genaue Modellidentifikation aus dem Verzeichnis ein.
4. Führen Sie minimale Aufrufe mit kurzen Hinweisen durch, und dokumentieren Sie den Antwortinhalt, die Modellidentifikation, den Tokenverbrauch, die Verzögerung sowie die Anfrageidentifikation, um zu überprüfen, ob das Anfrageformat korrekt ist.
5. Je nach zusätzlichem Geschäftsfluss für Stream-Ausgabe, strukturierte Ergebnisse, Bilder oder asynchrone Medienprozesse: Senden Sie nicht denselben Satz an Parameter an Modelle, die dies nicht unterstützen.
6. Zur Begrenzung des Datentransfers sowie bei vorübergehenden Fehlern werden exponentieller Backoff, zufällige Verzögerungen sowie eine Obergrenze für die Konkurrenz eingeführt; für ungültige Anfragen und fehlgeschlagene Authentifizierungen werden weitere Versuche unterbunden.
7. Überprüfen Sie im Console den Saldo und die Verbrauchsmenge, und legen Sie anhand der tatsächlichen Aufrufprotokolle Budgets, Schlüssellimitierungen sowie Schwellwerte für automatische Aufladungen fest.
8. Vor dem Go-Live werden das Hauptmodell, das Ersatzmodell sowie notwendige Rückfalllösungen für eine direkte Verbindung zum Hersteller getestet, und es werden Alarme für den Ausfall des Modells, Preisänderungen sowie abweichende Rechnungen eingerichtet.

Entwicklung von Schnittstellen und SDKs

Die offiziellen Node.js- und TypeScript-SDKs sind für die Verwendung auf der Serverseite vorgesehen. Es wird ausdrücklich darauf hingewiesen, dass langfristige Schlüssel nicht in Browsercode, Logs, Screenshots oder öffentliche Repositorien gespeichert werden sollten. Die aktuelle Version 0.1.x unterstützt das Abschließen von Dialogen, Responses sowie die Anzeige einer Liste von Modellen. Bilder, Videos, Audiodateien, Batchverarbeitung, Fine-Tuning sowie Echtzeitfunktionen gehören nicht zu den im Rahmen dieses SDKs angebotenen Funktionen.

Preise und Abrechnungsmethoden

CometAPI verwendet ein Abrechnungsmodell mit im Voraus bezahlten Credits – es werden keine festen Monatsgebühren, Mindestausgaben oder Abonnementkosten erhoben. Nach dem Aufladen des Kontos werden die Kosten entsprechend der tatsächlich genutzten Tokens, erstellten Assets, Segmente oder Dauer abgezogen. Solange das Konto in Ordnung ist, verfällt der Kaufsaldo nicht.

Preisgestaltung bei verschiedenen Modellen

Die Preisseite zeigt gleichzeitig den aktuellen Einzelpreis für verschiedene Modelle an. Sowohl die Preise für die verfügbaren Modelle als auch die Preise der Hersteller können sich ändern. Für die Kostenschätzung sollte der aktuelle Eingangspreis, Ausgangspreis oder Auftragspreis des jeweiligen Modells herangezogen werden; nach Abschluss der Auftragsabwicklung sollte dieser Wert mit der tatsächlichen Rechnung korrigiert werden.

Automatische Aufladung und fehlgeschlagene Anfragen

• Der Benutzer kann in seinem Konto einstellen, dass bei einem Saldo unter dem Schwellenwert automatisch über Stripe nachgeladen wird, und die Einstellungen können jederzeit geändert oder deaktiviert werden.
• Anfragen, die aufgrund von Parametern oder Authentifizierungsproblemen vom Gateway vor der Weiterleitung abgelehnt werden, sind nicht gebührenpflichtig. Ebenso sind Anfragen, bei denen der Server eine Fehlermeldung zurücksendet, nicht gebührenpflichtig.
• Die fließende Erstellung wird abgebrochen, sobald der Inhalt bereits zurückgegeben wurde; in der Regel wird gemäß den erzeugten Tokens abgerechnet. Anfragen, die erfolgreich abgeschlossen werden, deren Ergebnisse jedoch nicht den subjektiven Erwartungen entsprechen, werden vollständig berechnet.
• Wenn der Saldo nicht ausreicht oder die Zahlung fehlschlägt, kann die Plattform den Service vorübergehend einstellen oder einschränken. Das Produktionsystem sollte nicht ausschließlich auf automatische Aufladungen angewiesen sein, um seine Kontinuität zu gewährleisten.

Rückgaberegeln

• Verwendete oder aufgebrauchte Credits, API-Aufrufe sowie Rechenzeit sind nicht rückerstattbar, und der verbleibende Betrag kann weder übertragen noch in Bargeld umgewandelt werden.
• Ohne verwendete Credits kann eine schriftliche Anfrage eingereicht werden, doch die Genehmigung liegt in der Entscheidungsgewalt von CometAPI und stellt kein automatisches Rückgaberecht dar.
• Der Antrag muss den Betrag der Aufladung, das Kaufdatum, den aktuellen ungenutzten Saldo sowie den Grund enthalten; die Rückerstattungspolitik besagt in der Regel, dass innerhalb von 5 Arbeitstagen geantwortet wird.
• Der Rückbetrag wird so weit wie möglich auf die ursprüngliche Zahlungsmethode zurücküberwiesen. Gebühren, die von der Zahlungsdienstleisterin, der Bank oder einem Zwischenhändler nicht erstattet werden können, können abgezogen werden.
• Bei vermutlichen Fehlbuchungen muss innerhalb von 30 Tagen ab dem Datum der Abrechnung Einwand erhoben werden; andernfalls gilt dies als Zustimmung zu dieser Gebühr.

Passend für Nutzer und Szenarien

• Entwicklerteams, die mit einer Reihe von Schnittstellen mehrere Modelle vergleichen und wechseln möchten.
• Es ist notwendig, Teams für Produkte auszuwählen, die in Bezug auf Kosten und Leistung dynamisch über Support-, Inhalt-, Such-, Programmier- oder Proxy-Systeme bestimmt werden.
• Kreative Technik-Teams, die Bilder, Kurzvideos, Untertitel oder Musik in großen Mengen erstellen und gleichzeitig eine einheitliche Kontostands- und Rechnungsverwaltung anstreben.
• Entwicklungsteams von Unternehmen, die Arbeitsbereiche für Mitarbeiter zuweisen, den gemeinsamen Organisationsbudget verwalten sowie Schlüssel zentral steuern müssen.
• Infrastruktur-Teams, die auf mehrere Modelle zurückgreifen müssen oder deren Abhängigkeit von einem einzigen Modellhersteller verringert werden soll.

Vorteile und Grenzen der Fähigkeiten

• Einheitliche Schlüssel, Verzeichnisse und Rechnungen können wiederholte Anfragen reduzieren, doch die Aggregierschicht beseitigt nicht die Unterschiede zwischen den Modellen in Bezug auf Parameter, Inhaltspolitiken, Fähigkeiten und Ausgabequalität.
• Die Plattform unterstützt einen Rückfall innerhalb des Modells, doch fehlerhafte Klassifizierung, Idempotenz, Warteschlangen, Zeitüberschreitungen sowie eine direkte Verbindung zum Hersteller müssen weiterhin von der Anwendung selbst gestaltet werden.
• Die Bandbreitenbeschränkungen hängen vom Konto, vom Modell, von der Routing-Strategie sowie von der Kapazität der upstream-Systeme ab. Die in der Werbung angegebenen hohen Kapazitäten ersetzen nicht die Ergebnisse von Belastungstests in der Produktion sowie die vertraglichen Zusagen.
• Die Anzahl der offiziell verfügbaren Modelle sowie die genauen Modellbezeichnungen ändern sich ständig. In der Produktionsumgebung muss die Identifikation der Modelle festgelegt werden, und es ist notwendig, die Mitteilungen über das Ende der Produktion zu überwachen.
• Die Ausgaben des Modells können ungenau, urheberrechtsverletzend oder für den Geschäftsbetrieb ungeeignet sein; der Nutzer muss weiterhin eine Überprüfung hinsichtlich Fakten, Sicherheit, Urheberrechten und Konformität durchführen.
• Ohne schriftliche Genehmigung darf der Service weder weiterverkauft, weiterlizenziert noch erneut verteilt werden. Wenn Plattformen ihre API-Funktionen an Endkunden bereitstellen möchten, müssen sie zunächst die Genehmigungsmodalitäten klären.

Privatsphäre, Sicherheit und Konformität

• Laut der Datenschutzerklärung sammelt CometAPI weder Hinweise, Eingaben, Ausgaben noch Gesprächsinhalte, speichert sie auch nicht und führt sie in seiner eigenen Datenbank nicht auf.
• Die Anfragen werden weiterhin in Echtzeit an den tatsächlichen Modellanbieter weitergeleitet, um Ergebnisse zu erzeugen. Daher müssen die Datenverarbeitungs-, Speicher- und Inhaltspolitiken jedes upstream-Anbieters weiterhin separat geprüft werden.
• Die Plattform sammelt begrenzte Informationen wie IP-Adressen, Zeitangaben, Anfruffrequenz, Browser, Geräte sowie Zugriffsprotokolle zur Sicherheit, Konformität, Analyse und Optimierung der Dienste.
• Bei der Anmeldung eines Kontos werden möglicherweise Benutzernamen und E-Mail-Adressen erfasst. Bei der Anmeldung über GitHub oder Google werden mit Zustimmung des Benutzers die zur Authentifizierung benötigten Benutzernamen und E-Mail-Adressen abgerufen.
• Die Plattform gibt an, keine personenbezogenen Daten zu verkaufen, zu vermieten oder zu handeln, kann diese jedoch aufgrund gesetzlicher oder regulatorischer Anforderungen offengeben. Zudem wird betont, dass zwar angemessene technische und organisatorische Maßnahmen ergriffen werden, eine absolute Sicherheit jedoch nicht gewährleistet werden kann.
• Das Unternehmen listet SOC 2 Type II in seinem Roadmap als Projekt im Aufbau auf; daraus kann jedoch nicht geschlossen werden, dass die Plattform bereits diese Zertifizierung besitzt.

Empfehlungen zur Sicherheit von API-Schlüsseln

1. Für Entwicklung, Testing und Produktion werden jeweils eigene Schlüssel erstellt, angemessene Limits festgelegt, und diese werden ausschließlich in Server-Umgebungsvariablen oder einem Schlüsselverwaltungssystem gespeichert.
2. Es ist verboten, Schlüssel in Browserpakete, mobile Clients, öffentliche Code-Repositories, Protokolle, Screenshots oder Supportanfragen einzugeben.
3. Das Protokoll speichert nur Fehlerbehebungsfelder wie Modellidentifikator, Status, Verzögerung und Anfragenidentifikator; Schlüssel oder unnötige ursprüngliche Benutzertexte werden nicht aufgezeichnet.
4. Sofort nach Entdeckung eines Lecks sollten die Schlüssel zurückgenommen und ausgetauscht werden. Zudem müssen abweichende Nutzungsmengen, automatische Aufladungen sowie Berechtigungen der Mitglieder überprüft werden.

Open-Source-Zustand und Plattformunterstützung

Zusammenfassung

CometAPI eignet sich für Entwicklerteams, die einen schnellen Zugriff auf mehrere Modelle benötigen, einen einheitlichen Kontostand verwalten möchten und gleichzeitig die Möglichkeit haben müssen, zwischen den Modellen zu wechseln. Sein tatsächlicher Nutzen hängt davon ab, ob die gewünschten Modelle stabil und verfügbar sind, ob die Schnittstellen vollständig kompatibel sind sowie ob das Team in der Lage ist, Kosten, Schlüsselwerte, Wiederholungsversuche sowie die Richtlinien bezüglich der Verarbeitung der Daten zu verwalten.

Beim ersten Einsatz sollten zunächst Test-Credits verwendet werden, um die minimale Anzahl an Aufrufen durchzuführen. Anschließend kann die Qualität, die Verzögerung sowie die Kosten mithilfe echter Geschäftsdaten getestet werden. Vor der Bereitstellung in der Produktion oder vor einem großen Aufladen sollte außerdem das Lebenszyklusmanagement des Modells, der Servicelevel, die verantwortlichen Parteien, die Bedingungen für Rückerstattungen sowie die Anforderungen an die Verarbeitung der Daten im Hintergrund überprüft werden.