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.

pkpass-Datei unter iOS importieren

Dateien für das Wallet unter iOS können unter anderem als pkpass-Datei bezogen werden. Allerdings können diese nicht ohne weiteres über die Dateien-App importiert werden, da hier das Wallet nicht als Ziel angeboten wird.

Die Datei wird als Anhang in der Mail-App dargestellt

Ein Workaround führt über die Mail-App. So kann die pkpass-Datei einfach als E-Mail an den eigenen Account versandt werden. Dort wird sie anschließend als Anhang erkannt und kann direkt in das Wallet unter iOS importiert werden.

Probleme beim Deployen zu Maven Central

Im Rahmen einiger Wartungsarbeiten wollte ich eine neue Version einer Java-Bibliothek zu Maven Central deployen. Stattdessen wurde ich von der Meldung:

Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy failed: An API incompatibility was encountered while executing org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy: java.lang.ExceptionInInitializerError: null

überrascht. Am dahinterliegenden Problem wird bereits gearbeitet. Um das Deployment trotzdem durchführen zu können, eignet sich folgender Workaround:

export MAVEN_OPTS="--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED"
mvn clean deploy

Anschließend wird das entsprechende Deployment durchgeführt, was je nach Auslastung einige Minuten dauern kann.

Ulysses und Probleme mit der Synchronisation unter iOS

Das Schreibprogramm Ulysses erschien vor einigen Wochen in der Version 18. Neben der macOS-Version erschien zeitgleich die entsprechende iOS-Version. Die beiden Versionen können über iCloud oder per Dropbox synchronisiert werden.

Ulysses: Schreibprogramm
Preis: Kostenlos+
Ulysses Mobile
Preis: Kostenlos+

Bei der Dropbox-Variante wurden bis zur Version 18 ausschließlich Markdown-Dateien synchronisiert, welche allerdings nicht alle Features von Ulysses abdecken. Mit der neuen Version können nun auch die internen von Ulysses genutzten Dateien zur Synchronisierung genutzt werden.

Im ersten Schritt müssen die Einstellungen für den Ordner geöffnet werden

Allerdings werden, nachdem der Ordner aus der Dropbox unter iOS hinzugefügt wurde, nur die Ordner und nicht die Texte synchronisiert. Verantwortlich hierfür ist ein Bug, welcher in einer der nächsten Versionen behoben werden soll. Zum Glück kann sich mit einem Workaround beholfen werden.

Anschließend kann auf das interne Format umgestellt werden

Dazu müssen die Einstellungen des Dropbox-Ordners unter iOS geöffnet werden. Anschließend sollte dort das Feld Markdowndateien lesen und schreiben deaktiviert werden. Danach beginnt die Synchronisierung der internen Ulysses-Dateien. Der Fortschritt lässt sich am besten über das Statistikfenster beobachten. Manchmal scheint die Synchronisation erst zu starten, wenn ein Ordner geöffnet wurde, in welchem das Cloud-Symbol angezeigt wird.

Was leider auch mit der neuen Ulysses-Version immer noch nicht funktioniert, ist die Einbindung über WebDAV, sodass der Nutzer im Moment immer noch gezwungen ist fremde Cloud-Dienste zu nutzen. Eine Anbindung an eine eigene Nextcloud-Instanz (über WebDAV) ist somit immer noch Zukunftsmusik und wird vom Ulysses-Team gefühlt sehr stiefmütterlich behandelt. Stattdessen wird der Nutzer immer wieder auf unbestimmte Zeit vertröstet. Bei einer Software die vom Nutzer abonniert werden muss und somit dauerhaft zur Finanzierung der Firma beiträgt, darf der Nutzer erwarten, dass solche Anwendungsszenarien Beachtung finden.

Kalenderdateien mit webcal-Schema herunterladen

Manche Dienste und Webseiten bieten Kalenderdateien über das inoffizielle URL-Schema webcal:// an. Wird nun versucht eine solche URL herunterzuladen:

wget webcal://example.org

erhält der Nutzer in den meisten Fällen die Meldung:

Nicht unterstütztes Schema »webcal«

Abhilfe schafft es in diesem Fall das Schema webcal durch http bzw. https zu ersetzen. Anschließend kann die Datei mit den Kalendereinträgen problemlos heruntergeladen werden.