ib_insync-Alternative ib_async, Sync-Wrapper und GPL.

Wer 2026 noch ib_insync einsetzt, hat zwei sinnvolle Wege: den gepflegten Community-Nachfolger ib_async oder die offizielle TWS API von Interactive Brokers mit ihrem neuen synchronen Python-Wrapper. ib_async ist der schnellste Umstieg für bestehenden Code, die offizielle API der herstellernahe Weg mit mehr Umbauaufwand. In den letzten Versionen hat sich an der TWS API viel getan: Protobuf ab 10.35.01, der TWSSyncWrapper ab 10.40, Stückzahlen als Decimal ab 10.44 und seit 10.49 die GPL als Lizenz. Dieser Artikel zeigt Stand Oktober 2026, worin sich die Wege unterscheiden, was Sie zur GPL prüfen sollten, wie Sie alte Skripte migrieren und warum vor dem Live-Betrieb ein Paritätstest im Paper-Konto dazugehört.

Hinweis: Dieser Beitrag gibt den Rechts- und Steuerstand zum unten angegebenen Datum allgemein wieder. Er ist keine Rechts- oder Steuerberatung und ersetzt nicht die Prüfung Ihres Einzelfalls durch eine Rechtsanwältin, einen Rechtsanwalt, eine Steuerberaterin oder einen Steuerberater. Alle Angaben ohne Gewähr für Vollständigkeit und Aktualität.

ib_insync wird nicht mehr gepflegt: Was heißt das für bestehenden Code?

Die letzte Version von ib_insync auf PyPI ist 0.9.86 vom Juli 2023, das GitHub-Repository des ursprünglichen Entwicklers Ewald de Wit ist archiviert. Laut der Projektgeschichte von ib_async ist er Anfang 2024 überraschend verstorben; weil niemand mehr Zugriff auf Repository und Paketverwaltung hatte, führen frühere Mitstreiter die Bibliothek seitdem unter neuem Namen als ib_async weiter. Interactive Brokers (IBKR) schreibt in seiner Dokumentation, ib_insync beruhe auf einer veralteten Version der TWS API und werde nicht mehr aktualisiert. Wer die Struktur weiter nutzen will, dem nennt IBKR ib_async als Weg. Zugleich betont IBKR, dass das weder Empfehlung noch Warnung sei, dass der API-Support für diese Pakete keine Programmierhilfe leistet und dass IBKR grundsätzlich die direkte TWS API empfiehlt.

Für laufende Skripte bedeutet das zunächst: Sie brechen nicht über Nacht. ib_insync spricht das Socket-Protokoll von TWS und IB Gateway selbst und handelt beim Verbinden einen Versionsbereich aus. Das Problem ist schleichend. Fehlerbehebungen kommen nicht mehr, neue Felder und Ordertypen fehlen, und jede künftige Änderung auf Seiten von IBKR kann ein Verhalten verändern, ohne dass jemand die Bibliothek anpasst. Aus einem funktionierenden Werkzeug wird so technische Schuld, die mit jedem TWS-Update etwas teurer wird.

Hinzu kommt das Umfeld. Viele ib_insync-Setups starten IB Gateway über IBC (IBController). Dessen Repository ist seit dem 01.09.2026 archiviert, die letzte Version 3.24.2 erschien am 21.08.2026. Wer ohnehin an die Infrastruktur muss, sollte die Migration der Python-Seite gleich mitplanen. Grundlagen zu Architektur, Ports und Ordertypen stehen im Praxis-Leitfaden zur IB API mit Python; dieser Artikel behandelt nur die Umstiegsentscheidung.

Was hat sich an der TWS API geändert?

Das alte Argument für ib_insync lautete: Die offizielle Python-API ibapi zwingt Sie in ein umständliches Callback-Modell. Sie senden über EClient eine Anfrage, die Antwort trifft zeitversetzt in einer EWrapper-Methode ein, und Sie müssen Threads, Request-IDs und Zwischenspeicher selbst verwalten. Inzwischen hat IBKR an genau dieser Stelle nachgelegt.

Stand Oktober 2026 nennt die Download-Seite von IBKR die Version 10.50 als „Stable“ (09.09.2026) und 10.51 als „Latest“ (30.09.2026). Ein Fallstrick: Das Paket ibapi auf PyPI steht noch auf 9.81.1.post1 vom Dezember 2020. Die aktuelle offizielle API installieren Sie aus dem IBKR-Download, nicht per pip install ibapi.

Der Sync-Wrapper vereint EClient und EWrapper in einer Klasse. connect_and_start() verbindet und startet die Nachrichtenschleife in einem eigenen Thread; jede Methode wartet bis zu einem Timeout auf die Antwort. Der globale Standardwert liegt bei 30 Sekunden, einzelne Funktionen haben laut Doku eigene, kürzere Voreinstellungen, etwa 3 Sekunden bei get_open_orders(). Dokumentiert sind unter anderem get_contract_details(), get_market_data_snapshot(), get_historical_data(), place_order_sync(), cancel_order_sync(), get_open_orders(), get_executions(), get_positions() und get_portfolio(). Ein typisches Beispiel, angelehnt an die IBKR-Doku, gegen ein Paper-Konto:

from ibapi.sync_wrapper import *

app = TWSSyncWrapper(timeout=30)
if not app.connect_and_start(host="127.0.0.1", port=7497, client_id=11):
    raise SystemExit("Keine Verbindung zu TWS/Gateway")

c = Contract()
c.symbol, c.secType, c.exchange, c.currency = "AAPL", "STK", "SMART", "USD"
details = app.get_contract_details(c)        # Liste, statt Callback
contract = details[0].contract
snap = app.get_market_data_snapshot(contract) # dict: BID, ASK, LAST, *_SIZE als Decimal
print(app.get_positions())
app.disconnect_and_stop()

ib_async oder offizielle API mit Sync-Wrapper?

Beide Wege sind legitim. Sie unterscheiden sich weniger in der Leistungsfähigkeit als in Herkunft, Pflege, Lizenz und Programmiermodell. Die folgende Tabelle fasst den Stand Oktober 2026 zusammen.

Daraus ergibt sich eine einfache Faustregel. ib_async passt, wenn Sie eine größere ib_insync-Codebasis mit Ereignissen wie pendingTickersEvent oder orderStatusEvent haben und schnell wieder auf gepflegtem Code stehen wollen. Die offizielle API passt, wenn Sie neu beginnen, wenn Ihr System überwiegend Anfrage-Antwort-Logik nutzt (Kontrakt prüfen, Snapshot holen, Order senden, Position abfragen) oder wenn Herstellernähe und schneller Zugang zu neuen Funktionen für Sie schwerer wiegen als der Umbau. Für eventlastige Systeme ist asyncio ohnehin das passende Modell; mehr dazu im Artikel zu asyncio für Trading-Bots.

Ein Mischbetrieb ist möglich: Research-Skripte und Reports wandern auf den Sync-Wrapper, der eventgetriebene Ausführungsteil läuft vorerst auf ib_async. Jede Verbindung braucht dann eine eigene Client-ID. Orders lassen sich in der Regel nur über die Client-ID ändern, unter der sie platziert wurden, und ohne Master-Client-ID sieht eine Verbindung nur die Orders und Ausführungen ihrer eigenen Client-ID.

Die GPL-Lizenz ab 10.49: Was Entwickler prüfen sollten.

IBKR schreibt im Changelog nur knapp, dass TWS API 10.49 und neuer unter der GNU General Public License veröffentlicht wird. Eine bestimmte GPL-Version nennen Changelog und Produktseite nicht; maßgeblich ist der Lizenztext im jeweiligen Download. Für private Trader, die ihre Skripte nur selbst nutzen, ändert sich praktisch meist wenig. Die Pflichten der GPL knüpfen in der Regel an die Weitergabe von Software an. Spannend wird es für alle, die Programme auf Basis der TWS API an Dritte geben oder verkaufen.

Diese Punkte sollten Sie klären, bevor Sie auf 10.49 oder neuer aktualisieren:

• Weitergabe: Geben Sie Software an Kunden, Partner oder andere Gesellschaften weiter, etwa als installierbares Tool, als Bot für Endkunden oder als Teil eines Produkts?
• Versionsstand: Welche API-Version steckt in Ihren ausgelieferten Paketen? Für ältere Versionen gelten die Lizenzbedingungen, die dem jeweiligen Download beilagen.
• Architektur: Wie eng ist Ihr eigener Code mit der API verbunden, und wie wird er ausgeliefert? Ob eine Trennung die Lizenzfolgen verändert, ist eine juristische Frage.
• Alternative Bibliothek: ib_async enthält nach eigener Aussage nicht das Paket ibapi, sondern implementiert das Protokoll selbst und steht unter BSD-Lizenz. Ob das für Ihr Produkt den entscheidenden Unterschied macht, sollte ebenfalls fachkundig geprüft werden.

Unabhängig von der GPL gilt ein weiterer Hinweis von IBKR: Die TWS API darf ohne vorherige schriftliche Zustimmung nicht genutzt werden, um Marktdaten oder andere lizenzierte Informationen an Dritte oder nicht registrierte Kunden weiterzugeben. Für Weitergabe-Szenarien gehört das in dieselbe Prüfung. Die Lizenzfrage selbst klären Sie im Einzelfall mit einem auf Softwarelizenzen spezialisierten Anwalt.

Migration alter ib_insync-Skripte Schritt für Schritt.

Wenn ich Trading-Systeme für Interactive Brokers umbaue, beginne ich nicht mit dem Code, sondern mit einer Bestandsaufnahme. Bewährt hat sich diese Reihenfolge:

1. Inventur: Alle Stellen mit from ib_insync import suchen und notieren, welche Funktionen genutzt werden: Ereignisse, util.startLoop() in Notebooks, Bracket-Orders, historische Daten, Account-Werte.
2. Umgebung festhalten: Python-Version (für ib_async mindestens 3.10), TWS- oder Gateway-Version und alle Paketversionen fixieren, damit Sie Unterschiede später eindeutig zuordnen können.
3. Pfad A, ib_async: Import auf from ib_async import umstellen, Tests laufen lassen, Änderungshistorie lesen. Ein Major-Release wie 2.x kann inkompatible Änderungen enthalten; verlassen Sie sich nicht auf reines Suchen und Ersetzen.
4. Pfad B, offizielle API: Aufrufe übersetzen. Die Tabelle unten zeigt typische Entsprechungen. Ereignisgetriebene Teile bleiben beim Callback-Modell oder bekommen eine eigene Schleife.
5. Datentypen prüfen: Stückzahlen kommen als Decimal. Vergleiche wie size == 100 funktionieren, aber Decimal plus float löst in Python einen TypeError aus. Legen Sie fest, wo Sie konvertieren.
6. Timeouts richtig deuten: Bei place_order_sync() betrifft der Timeout laut Doku nur die Rückmeldung; die Order wird trotzdem übermittelt. Ein automatischer Neuversuch nach Timeout kann deshalb doppelte Orders erzeugen. Prüfen Sie vorher mit get_open_orders().

Die Rückgaben sind nicht identisch. ib_insync liefert eigene Objekte wie Trade oder Ticker, der Sync-Wrapper Listen und Dictionaries. Eine dünne Adapterschicht in Ihrem Code, die beide Formen auf ein internes Format abbildet, macht den späteren Vergleich deutlich leichter.

Grenzen und Risiken beider Wege.

Keiner der beiden Wege ist risikofrei. Die wichtigsten Punkte im Überblick:

• Pflege von ib_async: Die Bibliothek hängt an wenigen Freiwilligen. Seit Version 2.1.0 vom Dezember 2025 gab es Stand Oktober 2026 kein neues Release auf PyPI, die Arbeit läuft in Entwicklungszweigen weiter, darunter einer für Protobuf. Das ist kein Warnsignal an sich, aber ein Faktor für Ihre Planung.
• Kein Hersteller-Support: Bei Problemen mit ib_async hilft Ihnen IBKR nicht beim Code. Sie brauchen Logs und Testfälle, mit denen Sie Fehler selbst eingrenzen.
• Reife des Sync-Wrappers: Er ist vergleichsweise neu und deckt vor allem Anfrage-Antwort-Muster ab. Blockierende Aufrufe mit Timeouts von einigen bis 30 Sekunden passen nicht zu jeder Strategie; wer viele Instrumente parallel überwacht, braucht ein durchdachtes Thread- oder Event-Konzept.
• Lizenz: Die GPL betrifft vor allem weitergegebene Software. Wer das ignoriert, riskiert Streit über Quellcode-Offenlegung oder Nutzungsrechte.
• Trügerische Tests: Ein Skript, das im Paper-Konto sauber läuft, kann sich live anders verhalten. Mehr dazu im nächsten Abschnitt.

Und unabhängig von der Technik: Automatisierter Handel mit Hebelprodukten kann zum Totalverlust des eingesetzten Kapitals führen. Eine Migration ist eine Änderung an einem laufenden Risikosystem und verdient dieselbe Sorgfalt wie eine neue Strategie.

Paritätstest im Paper-Konto vor dem Live-Betrieb.

Ein Paritätstest prüft, ob der neue Code dasselbe tut wie der alte. Lassen Sie dafür alte und neue Version parallel mit unterschiedlichen Client-IDs gegen dasselbe Paper-Konto laufen und vergleichen Sie die Ergebnisse automatisiert, nicht per Augenmaß:

• Kontrakte: gleiche conId, gleiche Börse und Handelsklasse für alle Instrumente Ihres Universums.
• Historische Daten: gleiche Bars für identische Zeiträume, Zeitzonen und Einstellungen.
• Konto: Positionen, Portfolio- und Account-Werte zum selben Zeitpunkt.
• Order-Lebenszyklus: Statusfolge, Teilausführungen, Stornierung, Ablehnungen, Verhalten nach einem Verbindungsabbruch.
• Stückzahlen: Werden Decimal-Werte überall korrekt verarbeitet und protokolliert?

Kennen Sie dabei die Grenzen der Simulation. Laut IBKR werden Fills im Paper Trading nur vom Top of Book simuliert, ohne Markttiefe. Stops und andere komplexe Ordertypen werden immer simuliert und können sich anders verhalten als im Live-Konto. VWAP-, Auction-, RFQ- und Pegged-to-Market-Orders sind dort nicht verfügbar, Combo-Handel nur eingeschränkt. Der Paritätstest zeigt also, ob alter und neuer Code übereinstimmen, nicht, wie gut Ihre Orders live ausgeführt werden. Für den Übergang ist ein Start mit minimaler Positionsgröße und engen Limits sinnvoll.

Was Sie jetzt konkret tun können.

1. Prüfen Sie, wo ib_insync und IBC in Ihrem Setup noch laufen, und notieren Sie Versionen von Python, TWS oder Gateway und API.
2. Entscheiden Sie anhand der Tabelle oben: schneller Wechsel auf ib_async oder geplanter Umbau auf die offizielle API, gegebenenfalls gemischt.
3. Klären Sie vor einem Update auf 10.49 oder neuer, ob Sie Software weitergeben; falls ja, lassen Sie die GPL-Folgen anwaltlich prüfen.
4. Bauen Sie eine Adapterschicht und einen automatisierten Paritätstest im Paper-Konto, bevor der neue Code echtes Geld bewegt.
5. Planen Sie Pflege ein: Changelog von IBKR und Releases von ib_async regelmäßig lesen, Updates zuerst im Paper-Konto testen.

Wer dabei Unterstützung möchte, findet unter Trading-Automatisierung meinen Ansatz für Migration, Tests und Betrieb, für private Trader ebenso wie für Unternehmen.

Häufige Fragen.

Funktioniert ib_insync 2026 noch?

Bestehende Skripte laufen oft weiter, weil ib_insync das Socket-Protokoll selbst spricht und TWS beim Verbinden einen Versionsbereich aushandelt. Die Bibliothek erhält aber keine Updates mehr; die letzte Version 0.9.86 stammt von 2023. Fehler werden nicht behoben, neue API-Funktionen fehlen. Für produktive Systeme ist ein geplanter Umstieg auf ib_async oder die offizielle API sinnvoll.

Was ist der Unterschied zwischen ib_insync und ib_async?

ib_async ist die weitergeführte Version von ib_insync, gepflegt von früheren Mitstreitern unter neuem Namen. Struktur, Klassen und Ereignisse bleiben weitgehend gleich, deshalb ist der Umstieg meist mit überschaubarem Aufwand möglich. ib_async 2.1.0 vom Dezember 2025 setzt Python 3.10 oder neuer voraus und steht unter BSD-Lizenz. Programmierhilfe für beide Bibliotheken bietet Interactive Brokers nicht.

Was ist der TWSSyncWrapper der TWS API?

Der TWSSyncWrapper ist ein offizieller synchroner Wrapper für Python, den Interactive Brokers mit TWS API 10.40 eingeführt hat. Er vereint EClient und EWrapper, startet die Nachrichtenschleife in einem eigenen Thread und gibt Ergebnisse direkt zurück, etwa Kontraktdetails, Snapshots, Positionen oder Orderstatus. Jeder Aufruf wartet bis zu einem einstellbaren Timeout, global standardmäßig 30 Sekunden, bei einzelnen Funktionen kürzer voreingestellt.

Darf ich die TWS API trotz GPL in eigener Software nutzen?

Die Nutzung ist möglich, doch seit Version 10.49 gilt die GNU General Public License. Deren Pflichten knüpfen in der Regel an die Weitergabe von Software an. Wer Programme auf Basis der API verkauft oder an Dritte gibt, sollte Versionsstand, Architektur und Lizenztext im Einzelfall von einem Anwalt prüfen lassen. Für rein eigene Skripte ändert sich praktisch meist wenig.

Kann ich ibapi einfach per pip installieren?

Das Paket ibapi auf PyPI steht noch auf Version 9.81.1.post1 vom Dezember 2020 und ist veraltet. Die aktuelle offizielle TWS API mit Sync-Wrapper laden Sie bei Interactive Brokers herunter; Stand Oktober 2026 sind das 10.50 als Stable und 10.51 als Latest. Installieren Sie den Python-Teil aus diesem Download in eine eigene virtuelle Umgebung.

Quellen und Stand.

• ib_insync and ib_async — Interactive Brokers (TWS API Documentation)
• Synchronous API Wrapper: Introduction — Interactive Brokers (TWS API Documentation)
• Changelog August 3, 2026: TWS API 10.49 and GPL — Interactive Brokers
• Changelog January 26, 2026: Decimal sizes from API 10.44 — Interactive Brokers
• TWS API Download (Stable 10.50, Latest 10.51) — Interactive Brokers
• ib-async auf PyPI — Python Package Index
• ib_async Repository (README, Lizenz, Projektgeschichte) — ib-api-reloaded auf GitHub
• About Paper Trading Accounts — Interactive Brokers (IBKR Guides)
• ib_insync Quellcode: client.py (Versionsbereich beim Verbindungsaufbau) — erdewit/ib_insync auf GitHub (archiviert)

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

Sie wollen bestehenden ib_insync-Code auf ib_async oder die offizielle TWS API umstellen? Unverbindlich anfragen — wir klären Bestand, Migrationsweg und einen Paritätstest im Paper-Konto vor dem Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.