Tool-Aufrufe unter OpenCode reparieren

Der Open-Source AI-Coding-Agent OpenCode lässt sich nicht nur mit den üblichen Cloud-Anbietern, sondern auch mit lokalen bzw. selbst gehosteten Sprachmodellen nutzen. Dazu kann beispielsweise Ollama über dessen OpenAI-kompatible API angebunden werden.

OpenCode Desktop unter macOS

In Verbindung mit bestimmten Modellen wie dem qwen3-coder:30b zeigte sich allerdings ein interessantes Problem. Tool-Aufrufe funktionieren nicht, da sie oft als Klartext ausgeben und nicht korrekt interpretiert werden. Probleme mit Tool-Aufrufen sind im OpenCode-Projekt bereits länger bekannt und diskutiert.

Ob das verwendete Modell grundsätzlich Tool-Aufrufe unterstützt, lässt sich mit:

ollama show qwen3-coder:30b

überprüfen. Unter Capabilities sollte hierbei unter anderem:

tools

aufgeführt sein. Ist dies der Fall und funktionieren die Werkzeuge in OpenCode trotzdem nicht zuverlässig, kann die Ursache im von Ollama verwendeten Kontextfenster liegen.

OpenCode benötigt für agentisches Arbeiten vergleichsweise viel Kontext. Neben der eigentlichen Unterhaltung befinden sich dort unter anderem der System-Prompt und die Beschreibungen der zur Verfügung stehenden Werkzeuge. Ist das Kontextfenster zu klein, können Tool-Aufrufe dadurch nicht mehr zuverlässig funktionieren. Auch die OpenCode-Dokumentation weist bei Problemen mit Tool Calls in Verbindung mit Ollama darauf hin, num_ctx zu erhöhen.

Wird Ollama allerdings über die OpenAI-kompatible Schnittstelle von OpenCode angesprochen, lässt sich num_ctx nicht ohne Weiteres zuverlässig über die OpenCode-Konfiguration setzen. Als Workaround kann deshalb ein eigenes Ollama-Modell mit fest eingestellter Kontextgröße angelegt werden. Dazu wird das gewünschte Modell zunächst gestartet:

ollama run qwen3-coder:30b

Anschließend wird die Kontextgröße gesetzt:

/set parameter num_ctx 131072

und die Konfiguration unter einem neuen Modellnamen gespeichert:

/save qwen3-coder:30b-128k
/bye

Damit existiert neben dem ursprünglichen Modell nun eine Variante, bei welcher das größere Kontextfenster fest hinterlegt ist. Die Größe muss nicht zwangsläufig 128K betragen. Für Tool-Aufrufe empfiehlt OpenCode eine Erhöhung in den Bereich von 16K bis 32K. Bei entsprechend verfügbarem Speicher kann für längere Coding-Sitzungen allerdings auch ein deutlich größeres Kontextfenster sinnvoll sein. In OpenCode muss anschließend das neu angelegte Modell konfiguriert werden:

nano ~/.config/opencode/opencode.json

Eine entsprechende Konfiguration kann beispielsweise wie folgt aussehen:

{
  "$schema": "https://opencode.ai/config.json",

  "provider": {
    "remote-ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Remote Ollama",

      "options": {
        "baseURL": "https://example.org/ollama/v1",

        "headers": {
          "Authorization": "Bearer secret-token-123"
        }
      },

      "models": {
        "qwen3-coder:30b-128k": {
          "name": "Qwen3 Coder 30B 128K",
          "tools": true,
          "limit": {
            "context": 131072,
            "output": 16384
          }
        }
      }
    }
  },

  "model": "remote-ollama/qwen3-coder:30b-128k"
}

Wichtig ist hierbei die Unterscheidung zwischen den beiden Konfigurationen. Mit:

"limit": {
  "context": 131072,
  "output": 16384
}

wird OpenCode mitgeteilt, welche Grenzen das Modell besitzt. Dadurch wird allerdings nicht die tatsächliche Kontextgröße gesetzt, diese wurde stattdessen im neuen Modell angelegt. Nach einem Neustart von OpenCode kann das Tooling beispielsweise mit:

Erstelle eine Datei todo.md mit exakt dem Inhalt ‚hello world‘.

getestet werden. Wird die Datei tatsächlich über die OpenCode-Werkzeuge angelegt, funktionieren die Tool-Aufrufe. Da sich OpenCode und die Anbindung lokaler Modelle derzeit schnell weiterentwickeln, kann es allerdings auch mit dieser Konfiguration zu Problemen mit Tool-Aufrufen kommen, die andere Ursachen haben.

Rosetta-Probleme unter macOS 27

Mit dem Umstieg von Intel-Prozessoren auf Apple Silicon führte Apple im Jahr 2020 Rosetta 2 ein. Die Übersetzungsschicht ermöglicht es, für Intel-Prozessoren kompilierte Anwendungen auch auf Macs mit Apple Silicon auszuführen. Auch unter macOS 27 ist Rosetta noch vorhanden. Nach dem Update auf macOS 27 kann es allerdings passieren, dass eine zuvor funktionierende Intel-Anwendung plötzlich nicht mehr startet, so z. B. Spiele unter Steam.

Das Spiel lässt sich unter macOS nach einem Update nicht mehr starten

In einem solchen Fall kann es helfen, Rosetta erneut zu installieren. Dies ist über das Terminal möglich:

softwareupdate --install-rosetta --agree-to-license

Nach der erneuten Installation lassen sich die betroffenen Anwendungen meist wieder wie gewohnt starten. Interessant wird dies vor allem deshalb, weil Rosetta langsam seinem Ende entgegengeht. macOS 27 ist die letzte macOS-Version, in der Rosetta als allgemeine Kompatibilitätsschicht für Intel-Anwendungen zur Verfügung steht. Ab macOS 28 sollen gewöhnliche Intel-Anwendungen nicht mehr über Rosetta ausgeführt werden können.

Ganz verschwinden wird die Technik allerdings zunächst nicht. Apple möchte einen Teil der Rosetta-Funktionalität für ältere, nicht mehr gepflegte Spiele erhalten. Apple spricht allerdings ausdrücklich nur von einem Teil der Rosetta-Funktionalität für solche Spiele. Daraus lässt sich nicht ableiten, dass jedes derzeit über Rosetta laufende Spiel auch unter macOS 28 weiterhin funktionieren wird.

Homebrew-Pakete übertragen

Wer auf einem Mac viele Applikationen über Homebrew installiert hat und diese ebenfalls auf einem anderen Rechner installieren möchte, kann hierfür ebenfalls Homebrew nutzen:

brew bundle dump

Damit wird ein Brewfile angelegt. Dieses enthält die installierten Formulae und Casks. Auf einem neuen oder frisch installierten System können die Pakete anschließend mit:

brew bundle

wieder installiert werden. Damit lässt sich die Homebrew-Umgebung eines Macs mit wenig Aufwand reproduzieren.

Raspberry Pi Imager

Wer ein Betriebssystem für einen Raspberry Pi auf eine SD-Karte oder einen anderen Datenträger schreiben möchte, kann hierfür den offiziellen Raspberry Pi Imager nutzen. Die Anwendung übernimmt dabei nicht nur das Schreiben des Images, sondern vereinfacht auch die Auswahl und Vorkonfiguration des gewünschten Systems.

Der Raspberry Pi Imager

Nach dem Start wird im ersten Schritt das verwendete Raspberry Pi-Modell ausgewählt. Anschließend kann das gewünschte Betriebssystem festgelegt werden. Neben den unterschiedlichen Varianten von Raspberry Pi OS stehen dort auch eine Reihe weiterer Systeme zur Verfügung. Alternativ kann über die Option Use Custom ein bereits heruntergeladenes Image ausgewählt werden.

Im letzten Schritt muss der Zieldatenträger, beispielsweise eine SD-Karte oder ein USB-Datenträger, ausgewählt werden. Vor dem eigentlichen Schreiben bietet der Imager bei unterstützten Betriebssystemen zusätzliche Möglichkeiten zur Konfiguration.

So können unter anderem Hostname, Benutzername und Passwort, Zeitzone und Tastaturlayout sowie die WLAN-Verbindung bereits vor dem ersten Start festgelegt werden. Daneben können SSH und Raspberry Pi Connect aktiviert werden. Für SSH kann neben der Anmeldung mittels Passwort auch direkt ein öffentlicher SSH-Schlüssel hinterlegt werden.

Das geschriebene Image wird verifiziert

Damit eignet sich der Imager, insbesondere für sogenannte Headless-Installationen. Ein Raspberry Pi kann damit vorbereitet werden, ohne ihn für die Ersteinrichtung zunächst an Bildschirm und Tastatur anschließen zu müssen. Nach dem Schreiben der SD-Karte reicht es im Idealfall aus, diese einzulegen und den Raspberry Pi zu starten. Anschließend ist das System bereits über das Netzwerk erreichbar.

Der Raspberry Pi Imager steht für macOS, Linux und Windows zur Verfügung. Der Raspberry Pi Imager ist freie Software unter der Apache License.

iCloud-Daten sichern

Eine Cloud ist eine schöne Sache, solange sie funktioniert und verfügbar ist. Allerdings sollte nicht vergessen werden, dass Dienste wie iCloud in erster Linie der Synchronisation dienen und eine solche Synchronisation kein Backup ersetzt. Auch das der Zugriff auf eine Cloud eingeschränkt wird, ist kein realitätsfernes Szenario mehr. Problematisch wird dies insbesondere dann, wenn sich große Teile der eigenen Daten ausschließlich in iCloud befinden. Für ein zusätzliches Backup dieser Daten bietet sich unter macOS die Applikation Parachute Backup an.

Parachute Backup

Parachute Backup ermöglicht es, die Daten aus iCloud Drive und iCloud Photos automatisiert auf einen anderen Speicher zu sichern. Als Ziel können unter anderem externe Datenträger, eingebundene NAS-Systeme oder andere Cloudspeicher genutzt werden. Neben vollständigen Backups unterstützt Parachute Backup inkrementelle Backups und Spiegelungen. Bei iCloud Photos werden die Originale inklusive Bearbeitungen und Live Photos gesichert. Die Sicherungen können dabei manuell oder nach einem Zeitplan ausgeführt werden. Zu finden ist die Applikation auf der Webseite des Herstellers.