Katalog-Modelle mit einer providers.yaml in Raycast AI bringen.

Kurzantwort: Custom Providers aktivieren, eine Datei editieren.

Raycasts Pfad für OpenAI-kompatible Endpoints ist das Custom-Providers-Feature, gerichtet an fortgeschrittene Nutzer und standardmäßig deaktiviert. Aktivier es unten im AI-Abschnitt der Raycast-Einstellungen, nutz Reveal Providers Config, um den Config-Ordner zu öffnen, und kopier die mitgelieferte providers.template.yaml zu providers.yaml. Die Datei liegt unter ~/.config/raycast/ai/providers.yaml. Jeder Provider-Eintrag nimmt eine id, einen Anzeigenamen, eine base_url und einen api_keys-Block; jedes Modell, das du im Picker willst, wird explizit deklariert mit seiner id, einem Anzeigenamen und seinem Kontextfenster, plus einem abilities-Block, der beschreibt, was Raycast vom Modell verlangen darf. Die base_url-Form folgt derselben Konvention wie die eingebauten Local-Model-Beispiele, die auf eine /v1-Wurzel zeigen, APIsRouters Wert ist also https://api.apisrouter.com/v1. Die Datei hält Credentials, behandle sie also wie jede Secrets-Datei.

providers:
  - id: apisrouter
    name: APIsRouter
    base_url: https://api.apisrouter.com/v1
    api_keys:
      default: sk-APIsRouter-...
    models:
      - id: claude-sonnet-4-6
        name: Claude Sonnet 4.6
        context: 200000
        abilities:
          temperature:
            supported: true
          tools:
            supported: true
      - id: claude-haiku-4-5-20251001
        name: Claude Haiku 4.5
        context: 200000
        abilities:
          temperature:
            supported: true

Zwei Raycast-Features, die ähnlich klingen und es nicht sind.

Raycast dokumentiert zwei Wege, eigenen KI-Zugang mitzubringen, und die Suche nach dem einen fördert zuverlässig den anderen zutage, die Unterscheidung ist es also wert, klar ausgesprochen zu werden. Bring Your Own Keys, die BYOK-Seite im Raycast-Handbuch, verbindet deinen persönlichen Anthropic-, Google- oder OpenAI-Key (OpenRouter auf iOS) mit Raycast AI. Es ist das einfachere Feature, dokumentiert als funktionierend ohne Pro-Abo, aber es ist kein custom Endpoint: Requests routen über Raycasts Server zur API-Vereinheitlichung, und das Handbuch ist explizit, dass nur Modelle zugänglich sind, die bereits in Raycast AI verfügbar sind. Ein Gateway-Key passt dort nicht rein, weil BYOK nie nach einer URL fragt. Custom Providers ist das Feature, das diese Seite konfiguriert: deine eigene base_url, dein eigener Key, deine eigenen deklarierten Modelle, Requests gehen dorthin, wo du sie hinschickst. Es ist der Pfad für ein Multi-Vendor-Gateway, für lokale Server, und für jedes Modell, das Raycasts eingebaute Liste nicht führt. Der Preis ist Explizitheit, Raycast ruft die Modellliste des Endpoints nicht selbst ab (diese Bequemlichkeit ist eine offene Feature-Anfrage), der Picker zeigt also genau das, was deine YAML deklariert, nicht mehr und nicht weniger.

Modelle ehrlich deklarieren: IDs, Kontext, Fähigkeiten.

Weil es keine Autodiscovery gibt, ist die YAML ein Vertrag, und jedes Feld darin leistet echte Arbeit. Die Modell-ID muss exakt zur /v1/models-Liste des Gateways passen; sie ist es, was im Request mitreist. Der Name ist nur das Label, das Raycast anzeigt. Der context-Wert sagt Raycast, wie viel Konversationshistorie es in einen Request packen darf, ihn zu unterschätzen verschenkt Fähigkeit, und ihn zu überschätzen produziert Requests, die das Modell ablehnt; nutz das dokumentierte Fenster für die ID, die du deklarierst. Der abilities-Block ist das, was Leute falsch machen. Er deklariert, worauf sich Raycast verlassen darf: Temperature-Kontrolle, Vision-Input, System-Messages, Tool-Use, Reasoning Effort. Eine Fähigkeit zu deklarieren, die dem Modell fehlt, produziert verwirrende Laufzeitfehler innerhalb von Raycast-Features statt sauberer Fehler, und eine vorhandene wegzulassen deaktiviert still das entsprechende Raycast-Verhalten. Fang minimal an, Temperature plus Tools für die Modelle, die du mit KI-Erweiterungen nutzen wirst, und füg Fähigkeiten hinzu, sobald du sie gegen die Dokumentation des Modells bestätigt hast. Es gibt eine community-gepflegte Raycast-Erweiterung speziell dafür, diese Datei aus einer UI heraus zu verwalten, mit automatischen Backups vor jeder Änderung, gut zu wissen, falls YAML-von-Hand nicht deine Präferenz ist. So oder so liest Raycast die Datei von der Platte, gib den AI-Einstellungen also nach dem Editieren einen Moment oder schalt das Feature um, um sicherzustellen, dass der Picker die aktuelle Datei widerspiegelt.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# declare these ids verbatim in providers.yaml

Modelle für einen Launcher wählen.

Weil jedes deklarierte Modell über denselben Key abrechnet, ist die Vergleichsschleife ein Picker-Wechsel: lauf dieselben Quick-Commands einen Tag auf zwei IDs, lies dann die Ausgaben pro Modell in der Konsole und behalt das, das sich seinen Platz verdient hat.

• Launcher-KI ist Burst-Arbeit: fass das zusammen, formulier das um, erklär die Auswahl. claude-haiku-4-5-20251001 und gemini-3.5-flash antworten, bevor die Fenster-Animation fertig ist, das Gefühl, das Raycast-Nutzer erwarten.
• AI-Chat-Sessions und langes Verfassen verdienen sich claude-sonnet-4-6 oder gpt-5.5; deklarier sie neben der schnellen Stufe und wechsle pro Aufgabe im Picker.
• KI-Erweiterungen, die Tools rufen, brauchen ein Modell mit verlässlichem Tool-Use und den abilities-Block passend deklariert; claude-sonnet-4-6 ist dort die sichere Erstwahl.
• deepseek-v4-flash ist die Volumen-Wahl für Nutzer, die KI in jedes Textfeld verdrahten, das sie berühren; konstante kleine Completions summieren sich, und die schnelle Stufe hält die Gewohnheit auf dem Guthaben unsichtbar.
• Deklarier wenige Modelle bewusst statt viele spekulativ: jeder Eintrag ist eine Picker-Zeile, an der du vorbeiscrollst, und die YAML ist leicht zu erweitern, am Tag, an dem du eine weitere ID brauchst.

Nutzungsbasiert · unter offiziellem Preis

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Fehlerbilder speziell für Raycast.

BYOK zu konfigurieren, wenn du Custom Providers meintest, ist der Top-Fehler, und es ist nicht deine Schuld: die Features teilen sich einen Suchraum. Fragt der Flow, in dem du bist, nach einem Vendor-Key, aber nie nach einer URL, bist du in BYOK, und das Gateway gehört dort nicht hin. Geh zurück zu Settings, AI, und dem Custom-Providers-Toggle unten. Wird die Datei ignoriert, bedeutet das meist, das Feature-Toggle ist aus, die Datei heißt noch providers.template.yaml, oder die YAML hat einen Syntaxfehler, in welchem Fall Raycast nichts Gültiges zu laden hat und der Picker einfach keine custom Modelle zeigt. Validier die YAML, bevor du etwas Tieferes vermutest. Ein Modell, das bei manchen Raycast-Features Fehler wirft, bei anderen nicht, ist ein Fähigkeiten-Mismatch: Tool-nutzende KI-Erweiterungen scheitern, während normaler Chat funktioniert, wenn tools bei einem Modell deklariert wurde, dem es fehlt, oder nie deklariert wurde bei einem, das es hat. Wegen Größe abgelehnte Requests weisen auf einen überschätzten context-Wert hin. Und beacht ehrlich die Plattformgrenze: Custom Providers wird auf dem Mac konfiguriert, in einer lokalen Config-Datei. Findet ein Teil deiner Raycast-Nutzung anderswo statt, prüf das Handbuch, was das Feature dort unterstützt, bevor du Parität annimmst.

Wer Raycast AI über ein Gateway routet.

• Power-User, die im Launcher leben und schnelle KI-Commands auf schnellen Katalog-IDs wollen, ohne dass ein Abo entscheidet, welche Modelle sie berühren dürfen.
• Leute, die bereits Editor- und Terminal-Tools über ein Gateway routen und den Launcher auf demselben Key wollen, ein Nutzungslog über jede Oberfläche.
• Nutzer, die Modelle wollen, die Raycasts eingebaute Liste nicht führt, DeepSeek- und GLM-IDs eingeschlossen, einmal in YAML deklariert und überall in der App verfügbar.
• Builder von KI-Erweiterungen, die ein bestimmtes tool-fähiges Modell hinter ihrer Erweiterung brauchen, gepinnt per ID statt einer gehosteten Liste unterworfen.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und den ersten Command debuggen.

Lauf zuerst den Modelle-curl und kopier IDs aus dessen Output in die YAML; IDs aus dem Gedächtnis zu tippen ist hier die führende Ursache für Model-not-found-Fehler, weil die Datei Raycasts einzige Modellquelle ist. Aktivier dann das Toggle, bestätige, dass der Picker deine deklarierten Namen zeigt, und lauf einen schnellen KI-Command auf dem schnellen Modell. Ein leerer Picker ist das Toggle, der Dateiname, oder die YAML-Syntax. Ein Authentifizierungsfehler ist der api_keys-Block. Ein Not-found-Fehler ist ein ID-Mismatch gegen die Liste, die du gerade gecurlt hast. Ein Command, der im Chat funktioniert, aber in einer KI-Erweiterung scheitert, ist die abilities-Deklaration dieses Modells. Sobald Commands fließen, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Launcher-KI sind Hunderte kleine Requests statt weniger großer, und das Nutzungslog ist, wo dieses Muster zu einer Zahl wird, pro Modell, pro Tag, auf derselben Seite wie jedes andere Tool, das du über das Gateway routest.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

Häufige Fragen