Modelle & Anbieter

Jeder Coding-Agent in Bromure Agentic Coding — Claude Code, Codex, Grok, Kimi und omp — bezieht Modell und Zugangsdaten von einer Stelle: dem Modelle-Board. Sie registrieren jede Quelle einmal (die Anmeldung oder den API-Schlüssel eines Cloud-Anbieters, Amazon Bedrock, OpenRouter, einen eigenen Inferenzserver oder Modelle, die auf diesem Mac laufen), und jede Maschine kann sie nutzen. Eine Maschine (im Einstellungseditor ein Arbeitsbereich) übernimmt diese globalen Einstellungen standardmäßig und kann jeden Teil davon überschreiben.

Dieses Kapitel behandelt das Board selbst, An- und Abmelden, die Modellwahl pro Agent, Überschreibungen pro Maschine, wie Agenten Anbieter erreichen, die nicht ihre eigenen sind, was mit laufenden Agenten passiert, wenn Sie etwas ändern, und die eingebaute Engine auf dem Gerät: ihren Katalog, Downloads, Überwachungsfenster und model-Befehle. Eine Auflistung des Arbeitsbereich-Bereichs Feld für Feld finden Sie unter Modelle-Einstellungen. Fusion — mehrere Modelle beantworten einen Prompt — ist eine eigene Funktion mit eigenem Bereich.

Hinweis: Frühere Versionen hatten einen Bereich Agenten pro Arbeitsbereich, einen Bereich Lokale Modelle und einen „hybriden“ Routing-Modus, der von der Cloud auf ein lokales Modell auswich. Alle drei sind weg. Modell- und Zugangsdatenwahl liegen auf dem Modelle-Board, und der Verkehr einer Maschine geht pro Agent entweder in die Cloud oder an ein lokales Backend, wie unten beschrieben.

Wo das Modelle-Board erscheint

Dasselbe zweispaltige Board erscheint an vier Stellen:

Der Bereich trägt die Überschrift Modelle mit der Beschriftung „Registrieren Sie links eine Quelle. Jeder Agent nutzt das Standardmodell seines Anbieters, sofern Sie rechts kein anderes wählen.“ Links ist die Spalte Anbieter, rechts die Spalte Agenten.

Anbieter

Jede Zeile unter Anbieter hat einen Statuspunkt und einen einzeiligen Untertitel. Grün heißt nutzbar, grau nicht eingerichtet, orange eine abgelaufene Abonnement-Anmeldung. Klicken Sie auf eine Zeile, um ihr Konfigurations-Popover zu öffnen.

Der Untertitel der Zeile zeigt, wie ein Anbieter eingerichtet ist: API key, subscription, Anmeldung abgelaufen, AWS-Zugangsdaten (Bedrock), ein Hostname (eigener Server) oder N installed (auf dem Gerät). In der Überschreibung einer Maschine kann er auch inherited API key, inherited subscription, overridden here oder off here lauten.

Anmeldung und API-Schlüssel

Bei Anthropic, OpenAI, xAI und Moonshot beginnt das Popover mit Sign in with Anbieter („Interaktive Anmeldung in einer temporären VM — kein API-Schlüssel nötig.“), dann „oder einen API-Schlüssel einfügen“ über einem Feld API-Schlüssel. Ohne beides zeigt es Noch nicht konfiguriert.

Die Anmeldung führt den CLI-Login des Anbieters in einer Wegwerf-VM aus; die Seite des Anbieters öffnet sich in Ihrem Browser, und die erfasste Anmeldung wird auf dem Host gespeichert, nie in einer Maschine. Nach der Anmeldung zeigt das Popover Angemeldet mit der Zeit seither sowie Erneut anmelden… und Abmelden…. Abmelden… fragt nach — „Von Anbieter abmelden?“, „Workspaces, die diese Anmeldung nutzen, funktionieren erst wieder, wenn Sie sich erneut anmelden.“ — mit Abmelden / Abbrechen.

Lehnt der Anbieter eine gespeicherte Anmeldung ab (etwa weil sie anderswo widerrufen wurde), wechselt das Popover zu einem orangen Feld Anmeldung abgelaufen, das erklärt, dass Sitzungen sie erst nach erneuter Anmeldung wieder nutzen können, mit einer gut sichtbaren Schaltfläche Erneut anmelden.

Ein eingefügter API-Schlüssel hat beim selben Anbieter Vorrang vor einem Abonnement: Das Eintippen eines Schlüssels stellt diesen Anbieter auf nutzungsbasierte Abrechnung um. Schlüssel werden verschlüsselt gespeichert (siehe Wo die Einstellungen gespeichert werden).

Hinweis: Ein Abonnement kann nur seinen eigenen Agenten betreiben — ein Claude-Abonnement betreibt Claude Code, ein ChatGPT-Abonnement Codex und so weiter. Ein per Abonnement angemeldeter Anbieter erscheint deshalb nie im Modellmenü eines anderen Agenten und kann nicht in der Zeile Default verwendet werden. API-Schlüssel haben diese Einschränkung nicht.

Reichweite eines Abonnements: jede Maschine oder nur eine

Eine unter Einstellungen › Modelle gestartete Anmeldung wird immer von allen Maschinen geteilt. Eine im Einstellungseditor einer Maschine (in ihrem Bereich Modelle) gestartete Anmeldung endet mit einer Frage: Mit jedem Arbeitsbereich teilen? — „Diese Anbieter-Anmeldung für jeden Bromure-Arbeitsbereich verwenden (und die eigene Anbieter-Anmeldung jedes Arbeitsbereichs ersetzen) oder nur für diesen?“ — mit Jeder Arbeitsbereich und Nur diesen Arbeitsbereich.

• Jeder Arbeitsbereich speichert die Anmeldung als die geteilte und entfernt jede maschinenspezifische Anmeldung für diesen Anbieter, sodass die neue Anmeldung wirklich die ist, die jede Maschine verwendet.
• Nur diesen Arbeitsbereich speichert sie nur für diese Maschine. Eine Maschine mit eigener Anmeldung verwendet diese immer vor der geteilten.

Wurde die Anmeldung von einem gespiegelten entfernten Mac gestartet und beantwortet niemand die Frage, gilt standardmäßig Nur diesen Arbeitsbereich.

Amazon Bedrock

Das Bedrock-Popover erklärt: „Jeder Agent kann auf Amazon Bedrock laufen: Claude Code nativ, die anderen über die OpenAI-kompatible API von Bedrock. Signieren Sie Anfragen mit den eigenen AWS-Zugangsdaten jedes Arbeitsbereichs (Anmeldedaten → AWS) oder fügen Sie einen Bedrock-API-Schlüssel ein.“

1. Schalten Sie Amazon Bedrock verwenden ein.
2. Legen Sie optional eine AWS-Region fest. Bleibt sie leer, nutzt jede Maschine die Region ihrer eigenen AWS-Zugangsdaten, sonst us-east-1.
3. Fügen Sie optional einen Bedrock-API-Schlüssel (optional — sonst signieren die AWS-Anmeldedaten) ein. Ohne Schlüssel signiert der Host jede Anfrage mit den AWS-Zugangsdaten der Maschine aus ihrem Bereich Zugangsdaten; die Zugangsdaten gelangen nie in die VM.

Das Einschalten von Bedrock belegt das Hauptmodell von Claude Code mit einer Bedrock-Claude-Modell-ID vor. Modell-IDs sind die, die Bedrock verwendet (zum Beispiel us.anthropic.claude-sonnet-4-6); wählen Sie sie pro Agent im Menü oder tippen Sie mit Eigene ID… eine eigene ein. Bedrock hat keinen Endpunkt zum Auflisten von Modellen, daher bietet das Menü eine kurze, kuratierte Liste.

Ein Agent auf Bedrock ohne API-Schlüssel ist nur auf Maschinen startbereit, die AWS-Zugangsdaten haben. Das Ausschalten von Amazon Bedrock verwenden löscht jede Modellwahl, die auf Bedrock zeigte, sodass diese Agenten auf ihre Standardwerte zurückfallen.

Eigener Server

Eigener Server ist jeder OpenAI-kompatible Inferenzserver — vLLM, Ollama, LM Studio, llama-server — auf diesem Mac oder anderswo in Ihrem Netzwerk. Das Popover nennt ihn „Recommended for local models.“

1. Schalten Sie Aktiviert ein.
2. Geben Sie die Server-URL ein (zum Beispiel http://127.0.0.1:11434/v1) und, falls der Server einen braucht, einen API-Schlüssel (optional).
3. Klicken Sie auf Verbindung testen. Bei Erfolg zeigt es N model(s), und die Modelle des Servers erscheinen im Menü jedes Agenten unter Eigener Server; bei einem Fehler zeigt es den Fehler des Servers.

Bei einem eigenen Server ist die Modell-ID die eigene ID des Servers, unverändert (zum Beispiel qwen3:32b). Der Reparatur-Proxy des Hosts übersetzt das Leitungsformat jedes Agenten (Anthropic-Messages, OpenAI-Chat, OpenAI-Responses) in das /v1/chat/completions des Servers und zurück, und Kontextfenster, Vision- und Reasoning-Unterstützung des Modells werden beim Server abgefragt und an die Agenten weitergegeben. Für einen eigenen Server wird auf dem Mac kein Engine-Prozess gestartet.

Modelle auf dem Gerät

Auf dem Gerät öffnet eine Liste von Katalogmodellen — „MLX models run in-process on this Mac (N GB) — the lazy backup, nothing to install.“ Jede Zeile zeigt den Modellnamen, ein Passungs-Abzeichen (Fits, Tight oder Won't fit) und die Downloadgröße sowie eine Aktion:

Installierte Modelle erscheinen im Menü jedes Agenten unter Auf dem Gerät. Downloads werden von allen Maschinen geteilt. Katalog, Passungsregeln und Engine werden unter Die Engine auf dem Gerät beschrieben.

Agenten: Modelle wählen

Die Spalte Agenten hat eine Zeile Default und dann eine Zeile pro Agent: Claude Code, Codex, Grok, Kimi und omp. Jede Zeile hat einen Modell-Chip; klicken Sie darauf, um zu wählen.

Was ein Chip zeigt:

• Agent default — nichts ist gewählt, und der eigene Anbieter des Agenten ist eingerichtet, also nutzt der Agent das Standardmodell dieses Anbieters, genau wie sein eigenes „Default“ in /model. Sie müssen nichts wählen.
• Auswählen… — nichts ist gewählt, und für diesen Agenten lässt sich nichts auflösen.
• Eine Modell-ID mit einem farbigen Punkt für ihre Quelle (blau: ein Cloud-Anbieter; mint: der eigene Server; lila: auf dem Gerät; orange, durchgestrichen und mit · nicht verfügbar markiert: ein Anbieter, den dieser Agent nicht erreichen kann — siehe Welcher Agent welchen Anbieter erreicht). · übernommen nach der ID bedeutet, dass der Wert aus der Zeile Default stammt (oder, in einer Maschinen-Überschreibung, aus den globalen Einstellungen). Ein ✕ neben einer ausdrücklichen Wahl löscht sie.

Das Menü des Chips listet jeden nutzbaren Anbieter, den der Agent erreichen kann, als Untermenü von Modell-IDs (eine kuratierte Liste, zusammengeführt mit der Live-Modellliste des Anbieters, wo es eine gibt), dann Eigener Server und Auf dem Gerät, sofern eingerichtet. Jedes Anbieter-Untermenü endet mit Eigene ID…, das nach „The id exactly as the backend names it (e.g. claude-opus-5, glm-4.6, qwen3-coder).“ fragt. Für einen Agenten mit ausdrücklicher Wahl bietet das Menü außerdem Standard verwenden (oder Use agent’s default, wenn in der Zeile Default nichts gesetzt ist), um sie zu löschen.

Hat das Menü nichts anzubieten, sagt es das: Konfigurieren Sie zuerst einen Anbieter; No configured provider can power agent, wenn alle eingerichteten Anbieter für diesen Agenten unerreichbar sind; oder Ein Abonnement kann nur seinen eigenen Agenten betreiben, wenn die einzigen eingerichteten Anbieter Abonnements anderer Agenten sind. Unter Eigener Server bedeutet Verbindung testen, um Modelle aufzulisten, dass der Server noch nicht abgefragt wurde.

Die Zeile Default

Ein Modell in der Zeile Default gilt für jeden Agenten ohne eigene Wahl — auch für Agenten, deren eigener Anbieter eingerichtet ist und die sonst das Standardmodell ihres Anbieters nutzen würden. Lassen Sie Default auf Auswählen…, wenn jeder Agent das Standardmodell seines eigenen Anbieters nutzen soll.

Größen

Claude Code nutzt drei Modellplätze; jeder andere Agent nutzt ein Modell. Die Zeilen Default und Claude Code haben einen Bereich Größen mit zwei zusätzlichen Chips:

Nicht gesetzt, folgen der große und der kleine Platz den eigenen Standardwerten von Claude Code. Größen klappt von selbst auf, wenn einer davon gesetzt ist. In der Zeile Claude Code verwirft Auf Standard zurücksetzen alle eigenen Wahlen von Claude Code, sodass es wieder die Zeile Default übernimmt. Codex, Grok, Kimi und omp nutzen nur den Haupt-Chip.

Welcher Agent welchen Anbieter erreicht

Jeder Agent erreicht seinen eigenen Anbieter nativ. Er kann außerdem auf einige andere Anbieter gerichtet werden, die der Host für ihn überbrückt:

Beim Weg über den Reparatur-Proxy spricht der Agent in der VM mit dem Host, der das Leitungsformat des Agenten übersetzt, den echten Schlüssel hält (oder für Bedrock signiert) und die Anfrage weiterleitet. Der Schlüssel gelangt nie in die VM. Die OpenRouter- und z.ai-Wege von Claude Code richten den Agenten dagegen direkt auf den Anthropic-kompatiblen Endpunkt des Anbieters (https://openrouter.ai/api, https://api.z.ai/api/anthropic), mit einem Platzhalterschlüssel, den der Host auf der Leitung gegen den echten tauscht, wie bei jedem Cloud-Zugangsdatum (siehe Zugangsdaten & die Übertragungsgrenze).

Das Modellmenü eines Agenten bietet nur die Anbieter an, die er erreichen kann. Claude Code spricht nur den Anthropic-Dialekt, daher hat sein Menü keine OpenAI-, xAI- oder Moonshot-Modelle; die OpenAI-kompatible API von z.ai ist keine, zu der die anderen Agenten überbrückt werden können, daher ist das Menü von Claude Code das einzige Agentenmenü mit z.ai-Modellen (omp, auf z.ai umgestellt, erreicht es selbst).

Eine Wahl, die gespeichert wurde, bevor sie unerreichbar wurde — oder die ein Agent aus der Zeile Default übernimmt, ohne sie nutzen zu können —, erscheint orange, durchgestrichen, mit · nicht verfügbar dahinter. Ihr Tooltip erklärt: „Agent can’t use provider models, so it runs on its own provider instead. Pick another model.“

omp hat keinen eigenen Anbieter auf dem Board und kann kein Abonnement nutzen; geben Sie ihm einen Anbieter mit API-Schlüssel.

Überschreibungen pro Maschine

Der Einstellungseditor einer Maschine hat einen Bereich Modelle (in der Gruppe Modelle). Standardmäßig zeigt er einen Schalter, Eigene Modelleinstellungen für diesen Workspace, ausgeschaltet — „Inheriting the global settings (Preferences → Models).“ — und eine Übersicht Übernommene Modelle: die globalen Modelle Large / Medium / Small und die eingerichteten Anbieter.

Schalten Sie den Schalter ein und wählen Sie einen von zwei Modi:

• Übernehmen, mit Änderungen (Standard) — „Starts from the global settings; only what you set below is different here.“ Das vollständige Board erscheint und zeigt die globalen Einstellungen mit den Änderungen dieser Maschine darüber. Alles, was Sie nicht anfassen, folgt weiter live den globalen Einstellungen — ein Anbieter, den Sie später global registrieren, erscheint auch hier.
• Eigenständig — „This workspace has its own providers, logins and model choices below — the global settings are ignored.“ Der Wechsel zu Eigenständig startet mit einer Kopie dessen, was gerade gilt, sodass sich nichts ändert, bis Sie etwas bearbeiten.

Im Modus Übernehmen, mit Änderungen sagt jedes Anbieter-Popover, woher der Anbieter kommt, und lässt Sie das nur für diese Maschine ändern:

Modell-Chips funktionieren wie auf dem globalen Board; ein unveränderter Chip zeigt · übernommen, und das Löschen einer ausdrücklichen Wahl setzt ihn auf den globalen Wert zurück (Globale Einstellung verwenden).

Die Überschreibung wird mit der Maschine gespeichert, wenn Sie auf Sichern klicken. In einer Überschreibung eingegebene Schlüssel werden mit den übrigen Geheimnissen der Maschine verschlüsselt gespeichert.

Modelle auf laufenden Maschinen ändern

Für eine Modell- oder Zugangsdatenänderung müssen Sie nie eine Maschine neu starten. Wenn Sie einen Anbieter registrieren, einen Schlüssel einfügen oder ändern, sich an- oder abmelden, einen Agenten auf ein anderes Modell umstellen oder eine Maschinen-Überschreibung sichern:

1. Der Host aktualisiert, was die Agenten der Maschine lesen — die Tauschtabelle der Zugangsdaten, die Umgebung und die Konfigurationsdateien der Agenten — für jede laufende Maschine.
2. Jeder Agent, dessen Zugangsdaten oder Modell sich tatsächlich geändert haben, wird in seinem Tab gestoppt und sofort mit seinen Fortsetzungs-Flags neu gestartet, sodass das Gespräch weitergeht. In der Chat-Ansicht behält die Sitzung ihr Transkript; in einem Terminal sehen Sie, wie der Agent beendet wird und gleich wiederkommt.
3. Agenten, deren Konfiguration sich nicht geändert hat, bleiben unberührt, und die VM selbst startet nie neu.
4. Die Fusion-Einrichtung der Maschine folgt denselben Einstellungen: Ihre Zweige und ihr Richter werden neu bewertet, und der Schalter ⚡ wird deaktiviert, wenn weniger als zwei nutzbare Modelle übrig bleiben.

Änderungen auf dem globalen Board gelten etwa anderthalb Sekunden, nachdem Sie aufgehört haben zu tippen.

Warnung: Ein Agenten-Neustart unterbricht, was der Agent gerade tut. Steckt ein Agent mitten in einer langen Runde, warten Sie, bis er fertig ist, bevor Sie sein Modell oder seine Zugangsdaten ändern.

Wo die Einstellungen gespeichert werden

Die globalen Einstellungen liegen in ~/Library/Application Support/BromureAC/models.enc, verschlüsselt mit demselben Schlüssel wie der Geheimnistresor der Arbeitsbereiche. Die Überschreibung einer Maschine wird mit der Maschine gespeichert, ihre Schlüssel im verschlüsselten Geheimnisspeicher. Abonnement-Anmeldungen hält der Zugangsdaten-Proxy auf dem Host, geteilt oder pro Maschine, wie oben gewählt. Keines dieser Geheimnisse wird je in eine VM kopiert: Agenten erhalten Platzhalterwerte, die der Host auf der Leitung tauscht.

Grenzen

• Abonnements gibt es nur für Anthropic, OpenAI, xAI und Moonshot, und jedes betreibt nur seinen eigenen Agenten.
• omp nutzt nur API-Schlüssel.
• Ein eigener Server muss OpenAI-kompatibel sein.
• Innerhalb einer Maschine teilen sich alle lokal laufenden Agenten (eigener Server oder auf dem Gerät) ein einziges lokales Modell: Die Wahl des Hauptagenten gewinnt.
• Die Engine auf dem Gerät nutzt die eine GPU des Macs und führt jeweils nur eine Generierung aus.
• Das Modelle-Board ist in Bromure Remote auf iPhone, iPad oder Apple Vision Pro nicht verfügbar; bearbeiten Sie Modelle auf einem Mac.

Die Engine auf dem Gerät

Die Engine auf dem Gerät führt Open-Weight-Coding-Modelle mit Apples MLX-Framework auf der GPU Ihres Macs aus — kein Umweg über die Cloud, keine Abrechnung pro Token und kein Code, der den Mac verlässt. Es gibt nichts zu installieren, keine Python-Umgebung und keinen Server einzurichten.

Hinweis: Die Inferenz läuft auf dem Mac, nicht in der VM. Das optionale Metal-Grafikgerät des Browsers stellt Linux weder GPU-Rechenleistung noch MLX-Zugriff bereit, daher erreicht der Gast die Engine über die Übertragungsgrenze. Apple Silicon ist erforderlich — dieselbe Voraussetzung wie für die App selbst.

Der Engine-Prozess

Die MLX-Engine läuft als überwachter Kindprozess des eigenen Programms der App (bromure-ac model _mlx-engine), nicht in der App. Ein Modell zu laden, das zu groß für den Speicher des Macs ist, beendet nur den Engine-Kindprozess, nie die App oder ihre laufenden VMs. Die App startet eine abgestürzte Engine automatisch neu, bis zu dreimal; danach gibt sie mit der Protokollzeile engine child crashed repeatedly — giving up (a model likely OOMs this Mac) auf. Der Kindprozess wird beendet, wenn die App beendet wird, und ein nach einem harten Absturz verwaister Prozess wird beim nächsten Start aufgeräumt.

Eine Engine bedient alle Maschinen. Sie bindet einen vom Kernel zugewiesenen Loopback-Port auf 127.0.0.1 — nie 0.0.0.0 und nie Ollamas üblichen 11434, sodass eine separate Ollama- oder LM-Studio-Installation weiter funktioniert. Sie kann mehrere Modelle innerhalb eines Speicherbudgets halten (der vereinheitlichte Speicher des Macs abzüglich eines Puffers), lädt jedes bei der ersten Verwendung und verdrängt das am längsten ungenutzte, wenn der Speicher knapp wird.

Während die Engine hochfährt, zeigt die Symbolleiste einer Maschine ein kleines CPU-Abzeichen mit Aktivitätsanzeige („Starting local engine…“); es wird grün, sobald das Modell bereit ist, oder orange, wenn die Engine nicht starten konnte (zeigen Sie mit der Maus darauf, um den Grund zu sehen).

Wie der Gast sie erreicht

Agenten in der VM sprechen nie direkt mit der Engine. Sie zielen auf den synthetischen Host https://bromure.llm, der kein echtes DNS hat: Der host-seitige Proxy fängt ihn ab, wendet dieselbe Prompt-Injection-Prüfung und dieselbe Trace-Erfassung an wie beim Cloud-Verkehr und leitet die Anfrage an die Engine weiter. Lokale Inferenz ist nie ein blinder Fleck.

Agenten werden mit der echten Modell-ID konfiguriert, die die Engine bereitstellt (zum Beispiel mlx-community/Qwen3-8B-4bit-DWQ), sodass ihre Kontextbemessung und Fähigkeitsabfragen die Wahrheit sehen.

Hinweis: Ein Modell, dessen Architektur die MLX-Engine noch nicht unterstützt, schlägt mit einem klaren, dauerhaften Fehler fehl — „its architecture … isn't supported by the on-device engine yet — pick a different model“ —, der als Client-Fehler zurückgegeben wird, damit der Agent es nicht in einer Schleife erneut versucht. Nutzen Sie für solche Modelle einen eigenen Server.

Der Katalog

Der Katalog ist eine kuratierte Liste vorkonvertierter MLX-Modelle, jedes auf das geprüft, was beim agentischen Programmieren am meisten zählt — zuverlässige Tool-Aufrufe —, und jedes mit Downloadgröße und Mindestmenge an vereinheitlichtem Speicher.

Ein Basiskatalog wird mit der App ausgeliefert, damit die Liste vom ersten Tag an offline funktioniert. Die App holt einen aktualisierten Katalog von https://dl.bromure.io/mlx/catalog.json; ein neuerer veröffentlichter Katalog ersetzt den Basiskatalog, statt mit ihm zusammengeführt zu werden. Ein aus dem veröffentlichten Katalog entferntes Modell verschwindet aus der Liste, es sei denn, Sie haben es bereits installiert.

Der mitgelieferte Katalog enthält vier Qwen3-Modelle, alle auf Tool-Aufrufe geprüft:

Ein aktualisierter Katalog kann ohne App-Update neuere oder größere Builds hinzufügen.

Das Passungs-Abzeichen

Jedes Modell wird am vereinheitlichten Speicher Ihres Macs gemessen:

• Won't fit — das Minimum des Modells übersteigt Ihren Speicher. Die Zeile ist abgeblendet und kann nicht heruntergeladen werden.
• Tight — es lädt, mit weniger als 16 GB Reserve für alles andere.
• Fits — Minimum plus 16 GB Puffer passen.

Zum Beispiel zeigt Qwen3 8B (16 GB Minimum) auf einem 16-GB-Mac Tight und ab 32 GB Fits.

Downloads und Speicherung

Die Gewichte kommen direkt von huggingface.co über einen eingebauten Downloader — kein Python und keine Konvertierung. Jede Gewichtsdatei wird in eine temporäre .partial-Datei gestreamt und nach Abschluss umbenannt, sodass ein unterbrochener Download Datei für Datei fortgesetzt wird und ein Teil-Download nie für ein installiertes Modell gehalten wird. Dokumentation, Bilder und GGUF-Dateien im Repository werden übersprungen. Zuerst läuft eine Prüfung des Speicherplatzes, die früh abbricht, statt Ihre Festplatte zu füllen:

Not enough disk space: 40 GB free, but about 270 GB is needed.

Modelle werden pro Repository gespeichert unter:

~/Library/Application Support/BromureAC/models/<org>--<name>/

Modelle, die bereits von anderen Werkzeugen in ~/.cache/huggingface/hub zwischengespeichert sind, werden einmalig per Hardlinks in dieses Verzeichnis übernommen, sodass nichts doppelt heruntergeladen wird.

Jedes Hugging-Face-Repository, das bereits im MLX-Format vorliegt, lässt sich auch über seinen Namen org/repo von der Befehlszeile laden (siehe Befehlszeilen-Referenz); ein solches Modell ist ungetestet — keine Garantie für Tool-Aufrufe oder Speicherpassung. GGUF-Repositories werden abgelehnt, weil GGUF das Format von Ollama und llama.cpp ist, nicht von MLX:

That's a GGUF (Ollama/llama.cpp) model — Bromure serves MLX weights only.

Streaming, Denken und Vision

Lokale Runden streamen Token für Token, sowohl bei der Engine auf dem Gerät als auch bei einem eigenen Server. Der Proxy gibt Text weiter, während er erzeugt wird, und hält nur so viel vom Ende zurück, wie nötig ist, um einen durchgesickerten Tool-Aufruf zu entfernen; dann schließt er die Runde mit dem reparierten Ergebnis ab.

Reasoning-Modelle streamen ihr Denken als native Thinking-Blöcke in jedem Leitungsformat, sodass Agenten es so darstellen wie das Denken eines Cloud-Modells; das Denken wird nicht ins Transkript zurückgespeist. Vision-fähige Modelle (von einem eigenen Server abgefragt oder im Katalog markiert) akzeptieren Bilder: Der Proxy übersetzt Bildblöcke zwischen Leitungsformaten.

Hinweis: Die erste Runde einer Sitzung zahlt für das Prefill des gesamten Agenten-Prompts durch das Modell — oft Zehntausende Tokens an System-Prompt und Tool-Schemas —, bevor das erste Token erscheint. Bei einem 8B-Modell kann das eine Minute oder länger dauern; spätere Runden nutzen den Cache der Engine und beginnen fast sofort.

Reparatur von Tool-Aufrufen

Quantisierte Modelle geben einen Tool-Aufruf oft als Klartext statt als strukturierten Aufruf aus. Ein Reparatur-Proxy vor jedem lokalen Backend — auf dem Gerät oder eigener Server — puffert jede Antwort und erkennt die vielen Formen, die ein durchgesickerter Aufruf annehmen kann, zum Beispiel:

<function name="write_file" arguments='{…}'>
<tool_call>{…}</tool_call>
[{"name": "…", "parameters": {…}}]

sowie das native Format von Qwen3-Coder <function=Name><parameter=k>v</parameter></function> und das Kanalformat von Gemma. Was er findet, wandelt er in echte Tool-Aufrufe im eigenen Leitungsformat des Agenten um. Er erkennt außerdem ein Modell, das eine Aktion ankündigt („Now I'll create the file:“) und dann aufhört, ohne das Tool aufzurufen, und fordert bis zu zweimal nach, um den Aufruf zu retten. Die Reparatur ist bei lokaler Inferenz immer aktiv.

Engine-Probleme kommen beim Agenten als lesbare Fehler in seinem eigenen Leitungsformat an, zum Beispiel:

Local inference engine unreachable (starting up, reloading a model, or stopped) — retry in a moment.

Zu erwartende Leistung

• Der Durchsatz hängt von Modell und Chip ab. Ein kleines Modell wie Qwen3 8B ist auf jedem unterstützten Mac flott; die großen Mixture-of-Experts-Builds sind langsamer und brauchen weit mehr Speicher. Das Fenster Inferenz-Metriken zeigt die echten Raten auf Ihrer Hardware.
• Die erste Anfrage zahlt für das Laden des Modells in den Speicher.
• Spätere Runden sind günstiger. Die Engine hält einen Prompt-Cache pro Gespräch, sodass jede Agentenrunde nur die neuen Tokens verarbeitet.
• Die Generierung ist serialisiert. Die Engine führt jeweils nur eine Generierung aus; mehrere beschäftigte Sitzungen teilen sich die GPU, statt parallel zu laufen.

Lokale Inferenz überwachen

Zwei Fenster im Menü Fenster lassen Sie lokale Inferenz ohne Console.app verfolgen.

Inferenz-Metriken

Fenster › Inferenz-Metriken… öffnet ein Live-Telemetriefenster (Inferenz-Metriken) mit einem Tab pro genutzter Engine — die eingebaute Engine plus jeder eigene Server, auf den Ihre Maschinen zeigen. Der eingebaute Tab mit der Überschrift Local inference und der Loopback-Adresse der Engine zeigt Karten für Decode tok/s, Prefill tok/s, Running, Waiting, In flight, Avg latency, Cache hit, Metal mem, Gen tokens und Prompt tokens, eine Liste Geladene Modelle und einen aufklappbaren Bereich All metrics mit der Rohtabelle.

Das Fenster fragt alle 5 Sekunden ab, nur solange es offen ist. Decode- und Prefill-Raten sind Durchschnitte über die gesamte Laufzeit und wirken daher ruhig. Ist die Engine nicht erreichbar, zeigt das Fenster engine not reachable; während einer langen Generierung kann es kurz engine busy (timed out) zeigen. Eigene Server ohne Metrik-Endpunkt (etwa Ollama) bekommen trotzdem Karten, die der Proxy aus dem weitergeleiteten Verkehr misst.

Inferenz-Engine-Log

Fenster › Inferenz-Engine-Protokoll… öffnet eine Live-Ansicht (Protokoll der Inferenz-Engine) der Ausgabe der Engine und ihrer Lebenszyklus-Ereignisse — Modell-Ladevorgänge, „serving“, Statistiken pro Anfrage sowie jeden Speichermangel, Absturz, Neustart oder Ladefehler. Die Zeilen sind farbcodiert (rot für Fehler, grün für gesunde Ereignisse, orange für Warnungen, blau für laufende Arbeit). Die Symbolleiste hat ein Feld Filtern…, ein Kontrollkästchen Auto-Scroll, Kopieren und Leeren; solange nichts protokolliert ist, zeigt sie No inference-engine activity yet. Der Puffer behält die letzten 5.000 Zeilen, und jede Zeile wird außerdem in die Standardfehlerausgabe der App geschrieben.

Tipp: Wirkt ein lokales Modell langsam oder hängt es, öffnen Sie zuerst das Protokoll der Inferenz-Engine: Modell-Ladevorgänge, Verdrängungen, Neustarts wegen Speichermangels und Fehler zu nicht unterstützten Architekturen erscheinen dort alle im Klartext.

Kommandozeilenreferenz

Die model-Befehle verwalten Modelle auf dem Gerät; sie sprechen mit der laufenden App. Befehle, die auf eine Maschine wirken, nehmen ein abschließendes Argument <vm>: eine VM-ID oder den Namen eines Arbeitsbereichs. Die übrigen Befehle finden Sie unter CLI, API & MCP.

bromure-cli model catalog [--all] [--offline]
bromure-cli model pull <catalog-id | org/repo>
bromure-cli model ls
bromure-cli model use <catalog-id | org/repo> <vm>
bromure-cli model rm <catalog-id | org/repo>
bromure-cli vm routing cloud|local <vm>

model use und vm routing sind Live-Anpassungen für eine laufende Maschine; auf dem Modelle-Board werden die Modelle einer Maschine eingerichtet, und das gilt beim nächsten Start der Maschine.

Interne Diagnosebefehle

Diese versteckten Unterbefehle gibt es für Entwicklung und Fehlersuche.

Befehl	Zweck
bromure-cli model _mlx-serve <repo>	Startet den MLX-Server für ein Modell und blockiert, wobei Port und Schlüssel für Tests mit curl ausgegeben werden.
bromure-cli model _mlx-selftest <repo>	Lädt ein Modell, generiert einmal und gibt die Zeit bis zum ersten Token und die Decode-Geschwindigkeit aus.
bromure-cli model _repair-serve --engine-port <port>	Führt den Tool-Aufruf-Reparatur-Proxy eigenständig gegen eine laufende Engine aus.
bromure-cli model _tc-test <path>	Führt die Tool-Aufruf-Rettung an einer gespeicherten Textdatei aus.
bromure-cli model _spec-bench <main-repo> --draft <draft-repo>	Benchmarkt spekulatives Decodieren aus versus ein für ein Modellpaar.