← Alle Insights

Grok X Search API X-Sentiment für Trading-Research.

Mit dem X-Search-Tool der Grok-API lassen sich Posts auf X automatisiert suchen, lesen und in einem Schritt einordnen, etwa als positive, neutrale oder negative Stimmung zu einem Wert. Für Trading-Research ist das ein schneller Recherche-Zugang, aber kein sauberer Datenfeed: Der Zeitfilter kennt nur ganze Tage, das Modell wählt die Treffer selbst, und rückwirkende Abrufe sind nicht zeitpunkttreu. Stand Oktober 2026 kostet X Search laut xAI 5 USD pro 1.000 abgerufene Posts, zuzüglich Token-Kosten. Dieser Artikel zeigt, was das Tool technisch kann, was ein tägliches Stimmungsbild kostet, wann die direkte X API die bessere Wahl ist und warum Sentiment-Backtests so oft zu gut aussehen. Dazu gibt es eine Python-Skizze für eine Vorwärts-Sammlung mit sauberen Zeitstempeln und eine Liste mit Prüfregeln. Es geht um Handwerk für Daten und Tests, nicht um Handelssignale.

Was kann das X-Search-Tool der Grok-API?

X Search ist ein sogenanntes serverseitiges Tool: Sie schicken eine Anfrage an ein Grok-Modell, und das Modell durchsucht X selbst, bevor es antwortet. Laut xAI-Dokumentation beherrscht das Tool vier Arten des Zugriffs: Stichwortsuche, semantische Suche (nach Bedeutung statt nach exaktem Wortlaut), Nutzersuche und das Abrufen ganzer Threads. Zusätzlich lassen sich Bilder und Videos in Posts auswerten, wenn Sie enable_image_understanding bzw. enable_video_understanding setzen.

Angesprochen wird das Tool über das xAI-SDK oder über die OpenAI-kompatible Responses API unter api.x.ai. Die Antwort enthält Zitate: Inline-Verweise mit der URL des jeweiligen Posts (Format x.com/…/status/<ID>) und eine Liste aller Quellen, die das Modell bei der Suche gesehen hat. Den Verbrauch meldet die API im Feld usage.server_side_tool_usage_details, unter anderem als Zahl abgerufener Posts und Profile.

Für Trading-Research bedeutet das: Sie bekommen Suche, Lektüre und eine erste Einordnung in einem Aufruf. Was Sie nicht bekommen, ist ein Datenfeed. Das Modell formuliert die eigentlichen Suchanfragen selbst, wählt die Treffer aus und fasst sie zusammen. Diese Zwischenschritte sind für Sie nur teilweise sichtbar. Das ist bequem für Recherche und problematisch für alles, was später reproduzierbar sein muss.

Welche Filter und Zeiträume unterstützt X Search?

Die Steuerung des Tools ist bewusst schmal gehalten. Stand Oktober 2026 dokumentiert xAI diese Parameter:

ParameterFunktionGrenze
allowed_x_handlesnur Posts dieser Kontenmax. 20 Handles, nicht mit Ausschlussliste kombinierbar
excluded_x_handlesPosts dieser Konten ausschließenmax. 20 Handles
from_date / to_dateZeitraum eingrenzennur Format JJJJ-MM-TT, Tagesgrenze in UTC; Datum mit Uhrzeit wird laut Doku nicht angewendet
enable_image_understandingBilder in Posts auswertenerhöht den Tokenverbrauch
enable_video_understandingVideos in Posts auswertennur bei X Search, nicht bei Web Search

Die wichtigste Einschränkung steckt in der Datumszeile. Der Filter arbeitet nur mit ganzen Tagen. Sie können also nicht sagen: „alle Posts zu einer Aktie bis 15:29 Uhr, eine Minute vor der Zahlenveröffentlichung“. Wer intraday handelt, bekommt über den Filter allein keine saubere Grenze zwischen „vorher“ und „nachher“. Hinzu kommt die Zeitzone: Laut Dokumentation zählt das Datum in UTC. Ein UTC-Tag deckt sich weder mit dem Handelstag in Frankfurt noch mit dem in New York, und das ist für die Abgrenzung kein Detail.

Ebenfalls nicht dokumentiert ist ein Parameter, mit dem Sie die Zahl der abgerufenen Posts fest begrenzen. Wie viele Treffer das Modell holt, entscheidet es selbst. Das wirkt sich direkt auf die Kosten aus. Die Listen mit 20 Handles eignen sich für eine kuratierte Auswahl, etwa offizielle Unternehmenskonten oder bekannte Nachrichtenkonten. Für ein breites Stimmungsbild über einen Cashtag (Tickersymbol mit vorangestelltem Dollarzeichen) wie $TSLA sind sie zu eng.

Was kostet X-Sentiment pro Tag? Ein Rechenbeispiel.

Die Preislogik hat drei Teile. Laut Preisseite von xAI (Stand Oktober 2026) kostet X Search 5 USD pro 1.000 abgerufene Posts und 10 USD pro 1.000 abgerufene Nutzerprofile. Abgerechnet wird pro Element, nicht pro Aufruf, und zwar jeder zurückgegebene Post einschließlich Eltern- und zitierter Posts. Dazu kommen die Token-Kosten des Modells: Bei grok-4.7 sind es unter 200.000 Prompt-Tokens 2,00 USD pro 1 Mio. Input-Tokens und 6,00 USD pro 1 Mio. Output-Tokens. Gecachter Input kostet 0,50 USD statt 2,00 USD. Reasoning-Tokens, also das interne Nachdenken des Modells, berechnet xAI laut Preisseite ebenfalls zu den Tokenpreisen des Modells.

Rechenbeispiel (eigene Annahmen, keine Messwerte): Sie beobachten 20 Werte, rufen pro Wert einmal täglich ab, und das Modell holt im Schnitt 100 Posts.

PostenAnnahmeKosten pro Tag
Abgerufene Posts20 × 100 = 2.000 Posts × 0,005 USD10,00 USD
Input-Tokens20 × 40.000 Tokens = 0,8 Mio. × 2,00 USD1,60 USD
Output-Tokens20 × 2.000 Tokens = 0,04 Mio. × 6,00 USD0,24 USD
Summeohne Reasoning-Tokens und Profilerund 12 USD

Auf 30 Tage sind das rund 350 USD. Der größte Posten sind die Posts, nicht die Tokens. Prompt-Caching hilft deshalb nur begrenzt: Es senkt den Preis für wiederkehrende Teile des Prompts, etwa eine lange Klassifikationsanleitung, ändert aber nichts an der Post-Gebühr. Wie viele Tokens die Suchergebnisse im Kontext tatsächlich erzeugen, beschreibt die Dokumentation nicht genau. Messen Sie das in einer Testwoche über die Nutzungsfelder der API, bevor Sie hochrechnen, und setzen Sie ein Ausgabenlimit im Konto.

Grok-API oder direkte X API?

Die Alternative ist der direkte Zugriff über die X API. Seit Februar 2026 rechnet X sie nach Verbrauch ab (Pay-per-Use). Laut X-Dokumentation kostet ein gelesener Post 0,005 USD, ein Nutzerprofil 0,010 USD, und derselbe Post wird innerhalb eines UTC-Tages nur einmal berechnet. Die Pay-per-Use-Pläne sind laut aktueller X-Dokumentation bei 3 Mio. Post-Reads pro Abrechnungsmonat gedeckelt; wer mehr braucht, muss auf einen Enterprise-Vertrag wechseln. Neben der Suche über die letzten sieben Tage gibt es eine Archivsuche zurück bis März 2006, die laut Doku auch Pay-per-Use-Kunden offensteht.

KriteriumGrok-API mit X SearchDirekte X API
Preis pro Post5 USD / 1.000, plus Tokens5 USD / 1.000, Duplikate pro UTC-Tag einmal
Zeitfilternur ganze TageZeitfenster mit Uhrzeit
Kontrolle über TrefferModell wählt Suchanfragen und TrefferSie definieren Query und Trefferzahl
Reproduzierbarkeitgering, Antworten schwankenhoch, gleiche Query, gleiche Rohdaten (solange Posts existieren)
Klassifikationim selben Aufruf enthalteneigener Schritt, beliebiges Modell
Aufwandgering, ein Aufrufhöher: Paginierung, Limits, Speicherung

Pro Post liegen beide Wege in derselben Größenordnung. Der Unterschied liegt in der Kontrolle. Für explorative Recherche („Worüber wird bei diesem Wert gerade gesprochen, und warum?“) ist die Grok-API das schnellere Werkzeug. Für ein Datenset, das später in Tests und Regeln einfließt, spricht mehr für die direkte X API: Rohdaten abrufen, mit exakten Zeitstempeln speichern und erst danach mit einem Sprachmodell Ihrer Wahl klassifizieren. Dann lässt sich die Klassifikation auch mit einem anderen Modell oder einer neuen Anleitung wiederholen, ohne die Posts erneut zu bezahlen.

Warum Social-Sentiment schwer sauber zu backtesten ist.

Ein Backtest ist nur so gut wie seine Zeitpunkt-Treue (englisch Point-in-Time): Jede Entscheidung im Test darf nur Informationen nutzen, die zu diesem Moment tatsächlich verfügbar waren. Bei X-Daten, die Sie heute rückwirkend abrufen, ist diese Bedingung an mehreren Stellen verletzt:

Die ehrliche Konsequenz: Rückwirkend über X Search erzeugte Sentiment-Reihen sind für Backtests kaum belastbar. Belastbarer ist eine Vorwärts-Sammlung. Sie rufen ab heute regelmäßig ab, speichern Rohdaten und Abrufzeitpunkt und testen erst, wenn genug echte Historie vorliegt. Das dauert Monate, ist aber der einzige Weg zu sauberen Daten. Wie sich Look-Ahead-Fehler bei LLM-Signalen systematisch vermeiden lassen, beschreibt der Artikel LLM-Signale ehrlich backtesten.

Python-Skizze: Abruf, Klassifikation, Speicherung mit Zeitstempel.

Die folgende Skizze zeigt das Grundmuster einer Vorwärts-Sammlung mit der Grok-API über das OpenAI-Python-SDK. Sie ist bewusst knapp, nicht produktionsreif und muss gegen die aktuelle xAI-Dokumentation geprüft werden. Entscheidend sind drei Dinge: Der Abrufzeitpunkt wird in UTC gespeichert, die Rohantwort bleibt erhalten, und der Erstellungszeitpunkt jedes Posts wird aus seiner ID berechnet, statt der Zusammenfassung des Modells zu vertrauen.

import json, os, sqlite3
from datetime import date, datetime, timezone
from openai import OpenAI

client = OpenAI(api_key=os.getenv("XAI_API_KEY"), base_url="https://api.x.ai/v1")
SNOWFLAKE_EPOCH_MS = 1288834974657

def post_zeit(url: str) -> str:
    # Post-IDs sind Snowflake-IDs: der Erstellungszeitpunkt steckt in der ID
    post_id = int(url.rstrip("/").split("/")[-1])
    ms = (post_id >> 22) + SNOWFLAKE_EPOCH_MS
    return datetime.fromtimestamp(ms / 1000, tz=timezone.utc).isoformat()

def abrufen(cashtag: str, tag: date) -> dict:
    resp = client.responses.create(
        model="grok-4.7",
        tools=[{"type": "x_search",
                "from_date": tag.isoformat(), "to_date": tag.isoformat()}],
        input=[{"role": "user", "content":
            f"Suche Posts zu {cashtag} von diesem Tag. Antworte nur mit JSON: "
            '{"posts": [{"url": "...", "label": "positiv|neutral|negativ"}]}'}],
    )
    return {"abgerufen_utc": datetime.now(timezone.utc).isoformat(),
            "roh": resp.output_text,
            "nutzung": resp.usage.model_dump() if resp.usage else {}}

def db_oeffnen(pfad="sentiment.db") -> sqlite3.Connection:
    db = sqlite3.connect(pfad)
    db.execute("CREATE TABLE IF NOT EXISTS abrufe (cashtag, tag, abgerufen_utc, roh, nutzung)")
    db.execute("CREATE TABLE IF NOT EXISTS posts (url PRIMARY KEY, cashtag, "
               "erstellt_utc, abgerufen_utc, label)")
    return db

def speichern(db: sqlite3.Connection, cashtag: str, tag: date, erg: dict):
    db.execute("INSERT INTO abrufe VALUES (?,?,?,?,?)",
               (cashtag, tag.isoformat(), erg["abgerufen_utc"],
                erg["roh"], json.dumps(erg["nutzung"])))
    for p in json.loads(erg["roh"]).get("posts", []):
        db.execute("INSERT OR IGNORE INTO posts VALUES (?,?,?,?,?)",
                   (p["url"], cashtag, post_zeit(p["url"]),
                    erg["abgerufen_utc"], p["label"]))
    db.commit()

Post-IDs auf X sind sogenannte Snowflake-IDs, in denen der Erstellungszeitpunkt auf die Millisekunde kodiert ist: Die oberen Bits zählen die Millisekunden seit einem festen Startzeitpunkt, den Twitter im veröffentlichten Snowflake-Quellcode mit 1288834974657 angibt. Damit können Sie im Nachhinein alle Posts herausfiltern, die nach Ihrem Entscheidungszeitpunkt entstanden sind, obwohl der Datumsfilter nur ganze Tage kennt. Die Spalte abgerufen_utc dokumentiert, wann Ihr System die Information tatsächlich hatte. Im Backtest zählt dieser Zeitpunkt, nicht der Erstellungszeitpunkt des Posts.

Zwei Ergänzungen gehören in jede echte Umsetzung. Erstens eine Prüfung, dass jede zurückgegebene URL auch in den Zitaten der Antwort vorkommt; ein Sprachmodell kann Links sonst frei erfinden. Zweitens eine Fehlerbehandlung für Antworten, die kein gültiges JSON sind. Wer die Klassifikation lieber getrennt halten will, ruft die Posts über die X API ab und lässt ein Modell nur noch einordnen. Wie man aus Texten strukturierte Ereignisse statt bloßer Stimmungswerte gewinnt, zeigt der Beitrag zur Event-Extraktion aus News.

Grenzen und Risiken von X-Sentiment im Trading.

Sentiment aus sozialen Medien ist eine Datenquelle mit hohem Rauschanteil, kein Signal mit eingebauter Vorhersagekraft. Ob es für einen bestimmten Markt und Zeithorizont überhaupt etwas beiträgt, kann nur ein sauberer Test zeigen, und auch der kann zu dem Ergebnis kommen, dass kein Mehrwert übrig bleibt. Je liquider und stärker beobachtet ein Wert ist, desto schneller sind öffentlich sichtbare Stimmungen eingepreist.

Prüfregeln, bevor Sentiment in ein System einfließt.

Wenn ich Trading-Systeme mit zusätzlichen Datenquellen entwickle, gilt dieselbe Reihenfolge: erst Datenqualität, dann Hypothese, dann Test, zuletzt Ausführung. Für X-Sentiment lässt sich das in konkrete Prüfregeln übersetzen:

  1. Zeitstempel doppelt speichern: Erstellungszeit des Posts und Abrufzeit Ihres Systems, beide in UTC.
  2. Rohdaten behalten: Posts bzw. Rohantwort sichern, Klassifikation als eigene, versionierte Schicht.
  3. Vorwärts sammeln: Für Tests nur Daten verwenden, die Ihr System zum jeweiligen Zeitpunkt tatsächlich abgerufen hat.
  4. Stabilität messen: Denselben Abruf mehrfach ausführen und prüfen, wie stark Treffer und Labels schwanken.
  5. Bot-Anteil schätzen: Doppelte Texte, neue Konten und auffällige Posting-Frequenzen markieren und das Signal mit und ohne diese Posts vergleichen.
  6. Nur als Filter beginnen: Sentiment zunächst als zusätzliche Bedingung in einem bestehenden, getesteten Regelwerk prüfen, nicht als alleinigen Auslöser.
  7. Kosten pro Signal ausweisen: Datenkosten gehören in die Auswertung wie Gebühren und Slippage (die Abweichung zwischen erwartetem und tatsächlichem Ausführungspreis).

Wenn Sie diese Regeln einhalten, haben Sie nach einigen Monaten eine Datenbasis, mit der sich die Frage nach dem Nutzen ehrlich beantworten lässt. Bei der technischen Umsetzung, vom Datenabruf bis zum Einbau in ein automatisiertes System, unterstütze ich im Rahmen der Trading-Automatisierung.

Häufige Fragen.

Was kostet die Grok X Search API?

Stand Oktober 2026 berechnet xAI für X Search 5 USD pro 1.000 abgerufene Posts und 10 USD pro 1.000 Nutzerprofile. Abgerechnet wird pro Element, auch Eltern- und zitierte Posts zählen. Hinzu kommen die Token-Kosten des Modells, bei grok-4.7 unter 200.000 Prompt-Tokens 2 USD Input und 6 USD Output pro 1 Mio. Tokens. Prüfen Sie die aktuelle Preisseite, die Preise ändern sich.

Kann man mit der Grok-API Twitter-Sentiment in Python auswerten?

Ja. Über das xAI-SDK oder die OpenAI-kompatible Responses API lässt sich X Search als Tool aktivieren und das Modell bitten, gefundene Posts als JSON mit Stimmungslabel zurückzugeben. Für Research reicht das oft. Für Backtests sollten Sie Rohdaten, Post-Zeitpunkt und Abrufzeitpunkt speichern und prüfen, ob jede URL in den Zitaten der Antwort vorkommt.

Kann ich mit X Search historisches Sentiment für einen Backtest abrufen?

Technisch ja, belastbar meist nicht. Der Datumsfilter kennt nur ganze Tage, gelöschte Posts fehlen, die Rangfolge der Treffer ist von heute, und das Modell kennt den Ausgang älterer Ereignisse. Für ehrliche Tests ist eine Vorwärts-Sammlung ab heute mit gespeicherten Zeitstempeln deutlich verlässlicher, auch wenn sie Monate braucht.

Ist die direkte X API günstiger als X Search über Grok?

Pro Post kaum: Beide liegen bei rund 0,005 USD pro gelesenem Post. Die X API berechnet denselben Post innerhalb eines UTC-Tages aber nur einmal, und es fallen keine Modell-Tokens an, solange Sie nicht klassifizieren. Ihr Hauptvorteil ist die Kontrolle über Query, Zeitfenster und Trefferzahl. Der Aufwand für Paginierung und Speicherung liegt dafür bei Ihnen.

Quellen und Stand.

Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen X-Daten sauber erfassen und in einem Trading-System testen lassen? Unverbindlich anfragen — wir klären Datenquelle, Zeitstempel-Logik, Testumfang und Kostenkontrolle. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.