Anbieterprotokolle und Modellschnittstellen
Anyy v0.1.107 implementiert fünf native Gesprächsprotokollfamilien. Gemeinsames Verhalten folgt dem festen Pi v1.2.0, Commit 06a466935536f8c9bcacb2d5efc0fc021be1bdff. Dies beschreibt Protokoll- und Schnittstellenumfang und verspricht keine Live-Prüfung jedes Anbieterendpunkts, Kontos oder jeder Authentifizierungsvariante.
Gesprächsprotokolle
Anyy api_mode | Entsprechende Pi-API | Anfragefamilie |
|---|---|---|
openai-compatible | openai-completions | OpenAI-artige Chat Completions einschließlich kompatibler lokaler Dienste |
openai-responses | openai-responses | OpenAI Responses |
codex-responses | openai-codex-responses | Codex-Abonnement-Responses und ihr Transport-/Sitzungsverhalten |
anthropic-messages | anthropic-messages | Anthropic Messages |
google-gemini | google-generative-ai | Gemini Generative AI |
Anbietermarken können mehrere Endpunktverträge anbieten; die Markenwahl macht sie nicht austauschbar. Ollama und Ollama Cloud verwenden die vorhandene OpenAI-kompatible Familie. Ollama /api/tags entdeckt nur Modelle.
Die fünf zusätzlichen Pi-APIs azure-openai-responses, bedrock-converse-stream, google-vertex, mistral-conversations und pi-messages haben in dieser Version keine eigenständige native Implementierung oder Qualifikation. Ein kompatibles Gateway kann eine der fünf implementierten Familien verwenden, wenn es deren Vertrag tatsächlich implementiert; die eigene native API des Dienstes wird dadurch nicht ergänzt. Blockierte Einrichtungsoptionen einschließlich nativer Azure- und Bedrock-Wege bleiben nicht verfügbar.
Endpunkt- und Authentifizierungsdetails
Verwenden Sie die vom gewählten Endpunkt erwartete API-Wurzel. Native Anthropic Messages hängt /v1/messages?beta=true an die angegebene Basis-URL an, ohne vorhandenes Präfix zu entfernen. Für Anthropic direkt ist die Wurzel https://api.anthropic.com; ergänzen Sie /v1 nicht erneut. Eigene Proxys müssen den entstehenden Pfad bereitstellen.
Anyy löst Zugangsdaten vor Vorbereitung einer Anbieteranfrage auf. Native Anthropic-Authentifizierung folgt wirksamem Schlüssel und nativen Header-/Beta-Regeln; auth_transport ist kein Schalter zum Erzwingen eines anderen nativen Messages-Schemas. OAuth-/Abonnementeinrichtung bleibt endpunktspezifisch. Codex verwendet eigene Abonnementzugangsdaten und sendet die Clientidentität von Anyy (standardmäßig originator: anyy), statt sich als Anbieterclient auszugeben. Konfigurierte Modellheader werden vor Anfrageheadern angewendet; ein Anfrageheader kann diese Markierung überschreiben oder löschen. Anyy verwaltet weiterhin Authentifizierung und wahrheitsgemäßen User-Agent.
Typisierter Modellkatalog
Der Modellkatalog trennt Operationen nach type:
| Typ | Zweck | Grenze |
|---|---|---|
chat | Gesprächs- und Werkzeugaufrufmodell | Standard bei ausgelassenem Typ; Haupt-/Ausweichchatmodelle verwenden ihn |
image | Typisierte Bilderzeugung | Verwendet von models.generateImages() |
classifier | Strukturierte Auswahl-, Bewertungs- und boolesche Klassifizierung | Verwendet von models.classify() |
Eine Modell-ID wird mit Anbieter und Typ aufgelöst. Dieselbe ID kann in verschiedenen Typen existieren; ein Bild- oder Klassifiziererdatensatz kann nicht stillschweigend Chatmodell werden. Katalogbeschreibungen enthalten API, Ein-/Ausgabemodalitäten, Grenzen, Kosten, Kompatibilitätsmetadaten und konfigurierte Sampling-Einstellungen. Diese Deklarationen beschreiben eine Route; sie prüfen keine Remote-Verfügbarkeit.
Erweiterte Felder providers[].models[] sind type, api, base_url, input, output, headers, input_limits, sampling_params, sampling_params_by_thinking_level, compat, capabilities und cost. Verwenden Sie den deklarierten Übertragungsvertrag und die dokumentierten Dienstparameter. Natives Sampling vereinigt Modellvorgaben, Parameter der wirksamen Thinking-Stufe und dann Anfrageparameter; spätere Felder überschreiben frühere. Diese Einstellungen führen weder eine neue Protokollfamilie ein noch garantieren sie, dass Remote-Endpunkte beliebige Optionen akzeptieren.
Codemode-Modellhilfen
Sind Modellhilfen in Codemode verfügbar, verwenden diese asynchronen Funktionen denselben konfigurierten Katalog und dieselben Zugangsdaten:
| Funktion | Ergebnis |
|---|---|
models.getModelsOfType(type, provider?) | Katalogdatensätze für chat, image oder classifier |
models.getAvailableOfType(type, provider?) | Nach Anbieteraktivierung und auflösbaren Zugangsdaten gefilterte Datensätze |
models.getModelOfType(type, provider, id) | Exakter Datensatz oder bei Fehlen undefined |
models.classify(model, context) | Typisiertes Klassifizierungsergebnis |
models.generateImages(model, context) | Typisiertes Bildergebnis |
„Verfügbar“ ist eine lokale Zugangsdaten-/Aktivierungsprüfung, kein Live-Inferenztest. Skripte erhalten Katalogbeschreibungen ohne konfigurierte Header. Ausführung löst das ursprünglich konfigurierte Modell erneut auf; das Bearbeiten einer gelieferten Beschreibung lenkt die Operation nicht auf einen anderen Endpunkt um.
Die implementierte Bild-API ist openrouter-images. Klassifizierer-APIs sind typesafe-system-one, cloudflare-workers-ai-system-one, llama-cpp-classify und openai-decisions. Ihre lokalen Anfrage-/Ergebnisprüfungen qualifizieren nicht jeden externen Einsatz oder jedes Konto.
Beispielsweise in Codemode:
const candidates = await models.getAvailableOfType("image");
if (!candidates.length) throw new Error("Configure an image model first");
const result = await models.generateImages(candidates[0], {
input: [{ type: "text", text: "A landscape watercolor of a quiet lake" }],
});
if (result.stopReason !== "stop") throw new Error(result.errorMessage);
for (const block of result.output) {
if (block.type === "image") image(block);
}
generateImages akzeptiert Text und optionale Base64-Bildreferenzblöcke. classify akzeptiert state, questions und optionale vom Modell unterstützte Bilder; Fragetypen sind choice, score und bool. Native Fehler bleiben typisierte Fehler-/Abbruchergebnisse. Prüfen Sie stopReason vor Ausgabeverwendung. Diese Hilfen ergänzen keine allgemeine Schnittstelle models.chat().
Klassifiziererkontexte benötigen ein Objekt state und ein nicht leeres Objekt questions. Jede Frage hat type, instructions und criteria:
| Fragetyp | Form von criteria |
|---|---|
choice | Nicht leeres Objekt mit Labels und Zeichenfolgenbedeutungen |
score | Nicht leeres Array von Zeichenfolgenbeschreibungen, von niedrig nach hoch |
bool | Objekt mit Bedeutungen für true und false |
Optionale images verwenden Blöcke { type: "image", data: "<base64>", mimeType: "image/png" } und benötigen einen bildfähigen Klassifizierer. Klassifizierungsausgabe liegt in answers, Bildausgabe in output, Verbrauch ist enthalten, wenn das Backend ihn liefert.
Das Produktwerkzeug Bilderzeugung ist separat: Es verwendet derzeit OpenAI Responses und speichert einen Gesprächsanhang. Seine Dashboard-Route konfiguriert weder openrouter-images noch Klassifiziererdatensätze.
Wiederholungen, Ausweichrouten und virtuelles Routing
Diese Mechanismen haben unterschiedliche Zuständigkeiten:
| Mechanismus | Steuerung |
|---|---|
| Automatische Sitzungswiederholung | Wiederholt wiederholbaren Assistentenfehler; standardmäßig aktiv, 3 Wiederholungen, exponentielle Verzögerung von 2.000 ms bis höchstens 60.000 ms |
| Anbieter-SDK-Wiederholung | Wiederholt geeignete anfängliche Transport-/HTTP-Fehler gemäß retry.provider; spielt keinen bereits gestreamten Antwort-Body erneut ab |
| Konfigurierte Ausweichroute | Versucht bei erlaubender Fehlerrichtlinie geordneten kompatiblen Anbieter/Modell |
| Virtueller Modell-Callback | Löst registrierte virtuelle Auswahl in physisches Katalogmodell und wirksame Thinking-Stufe auf |
Die erste Anfrage zählt nicht zu den Sitzungswiederholungen. Abrechnungs-/Kontolimitfehler sind keine gewöhnlichen vorübergehenden Wiederholungen, und Kontextüberlauf folgt Kontextwiederherstellung statt diesem Wiederholungsweg. Abbruch beendet Wiederholungswarten. retry.enabled: false deaktiviert automatische Sitzungswiederholung; es deaktiviert nicht jedes Anbieter-SDK-Verhalten oder konfigurierte Ausweichrouting.
Erweiterte Profileinstellungen verwenden die exakten camelCase-Schlüssel:
retry:
enabled: true
maxRetries: 3
baseDelayMs: 2000
maxAgentDelayMs: 60000
provider:
maxRetries: 0
maxRetryDelayMs: 60000
httpIdleTimeoutMs: 300000
retry.provider.timeoutMs ist ein optionales Anbieteranfrage-Zeitlimit. httpIdleTimeoutMs beträgt standardmäßig 300.000 ms; 0 oder disabled deaktiviert den Leerlauftimer. Medienrouten haben eigene Grenzen. Sitzungs-, SDK-, Ausweichversuche und native Codex-Transportwiederherstellung sind getrennt; eine Einstellung ist daher kein Gesamtlimit für Anfragenanzahl oder Laufzeit.
Virtuelle Modelle verwenden die interne Registrierungs-/Callback-Schnittstelle pi-virtual. Sie sind kein sechstes Remote-Inferenzprotokoll; v0.1.107 hat weder YAML-Routerdeklaration noch CLI-Assistent oder Dashboard-Routereditor. Ein registrierter Callback erhält Benutzer-/Fortsetzungs-/Wiederholungs-/Direktkontext und kann Zweigroutenzustand bewahren, muss aber ein physisches Katalogmodell mit nutzbaren Zugangsdaten liefern. Er darf weder zu einem unregistrierten Modell noch rekursiv zu einem weiteren virtuellen Modell routen. Eine konfigurierte Ausweichliste allein registriert keinen solchen Callback.
Alltägliche Einrichtung finden Sie unter Modelle konfigurieren und Dashboard-Modelle.