/bedrock
Konfiguriert AWS Bedrock als Modell-Backend, sofern das Bedrock-Feature aktiviert ist.
/bedrock [subcommand] konfiguriert AWS Bedrock als Modell-Backend für die Cursor CLI. Laut Referenztabelle funktioniert der Befehl nur, wenn das Bedrock-Feature für deinen Account freigeschaltet ist — ist das nicht der Fall, hat er keine Wirkung.
Laut Cursor-Changelog richtest du darüber Bedrock „mit deinen eigenen Zugangsdaten" ein: entweder über klassische AWS-Access-Keys oder über eine Team-IAM-Rolle. Die Einrichtung gilt laut Changelog übergreifend — sie wirkt sowohl in interaktiven Sitzungen als auch im Headless-Modus und in Editor-Integrationen, du musst Bedrock also nicht pro Modus einzeln konfigurieren.
/bedrock ist für Setups gedacht, bei denen Modellanfragen über die eigene AWS-Infrastruktur statt über Cursors Standard-Backend laufen sollen, etwa aus Compliance- oder Kostengründen im Unternehmensumfeld.
✅ WANN EINSETZEN?
Bedrock mit eigenen AWS-Zugangsdaten einrichten
/bedrock — eigene Access-Keys hinterlegen, damit Modellanfragen über die eigene AWS-Infrastruktur laufen
Team-weite Bedrock-Anbindung über eine IAM-Rolle statt einzelner Keys
/bedrock im Unternehmenskontext nutzen, um stattdessen eine Team-IAM-Rolle zu hinterlegen
⛔ WANN EHER NICHT?
Das Bedrock-Feature ist für den Account nicht freigeschaltet
Laut Doku funktioniert /bedrock nur, wenn das Bedrock-Feature aktiviert ist.
Besser: Modell regulär über /model wählen bzw. Bedrock-Zugang beim Cursor-Team anfragen
Es reicht, kurzfristig ein anderes Standardmodell zu testen
/bedrock ist für eine dauerhafte Backend-Konfiguration gedacht, nicht für einen schnellen Modellwechsel.
Besser: /model oder einen Modell-Shortcut wie /composer nutzen
QUELLEN
- Cursor Docs — Slash Commands ↗ cursor.com
- Cursor Docs — Changelog ↗ cursor.com