Es gibt Skandale, bei denen man kurz die Augenbraue hebt – und es gibt Skandale, bei denen einem der Kaffee im Hals stecken bleibt. Der aktuelle Fall rund um Grok Build, xAIs Kommandozeilen-Tool für agentisches Coding, gehört eindeutig in die zweite Kategorie. Die Sicherheitsforscher bei Cereblab haben sich die Mühe gemacht, den Netzwerkverkehr von Grok Build im Detail zu analysieren – mit einem simplen, sehr unschuldigen Test: Die CLI wurde angewiesen, ausschließlich mit „OK“ zu antworten, außerdem wurde es ihr explizit verboten, irgendwelche Dateien zu öffnen. Tja, und das Ergebnis dieses Tests hat das Zeug, das Vertrauen in sämtliche Coding Tools von LLM-Herstellern nachhaltig und komplett zu zerstören.
Nachdem die US-amerikanische Regierung Exportkontrollen über Claude Fable 5 verhängt hatte, wurde anschließend auch OpenAI damit bedacht und durfte sein neues Modell GPT 5.6 nicht in die allgemeine Verfügbarkeit bringen. Es heißt zwar nun, in Kürze würden beide Modelle wieder zugänglich gemacht werden, aber die Falle des „Gut genug“ ist schon längst zugeschnappt, und man muss deshalb mittlerweile auch ganz andere Motive für die Exportkontrollen in Betracht ziehen, als die behaupteten Sicherheitsbedenken.
Wenn man mit Kunden spricht, merkt man oft, die größte Angst beim Einsatz von KI im Nutzerkontakt sind bösartige Prompts, die die KI dazu verleiten könnten, entweder Internas preiszugeben, oder Unsinn zu erzählen, für den das Unternehmen in Haftung genommen werden könnte. Auch die großen Chatbot-Anbieter selbst, wie Anthropic oder OpenAI, haben damit zu kämpfen, und müssen sich bereits Klagen wegen fragwürdiger Aussagen ihrer KI stellen. Eine neue Technologie nimmt sich jetzt der Problematik an.
Es geht dabei um sogenannte Safeguard-Modelle. Uns sind bisher zwei solche Modelle bekannt, GPT-OSS-Safeguard und Llama Prompt Guard 2. Safeguard-Modelle sind speziell auf das Erkennen von Prompts trainiert, die die Sicherheit von KI-Modellen aushebeln sollen, und außerdem für genau diese Aufgabe hochoptimiert, damit die Prüfung sehr schnell geht.
Das Problem, das diese Modelle adressieren, heißt Prompt Injection. Die OWASP – die weltweit anerkannte Non-Profit-Organisation für Applikationssicherheit – führt Prompt Injection seit 2025 als Nummer-eins-Risiko für KI-Anwendungen. Dahinter steckt ein simples Prinzip mit großer Wirkung: Ein Nutzer formuliert seine Eingabe so, dass der Chatbot seinen ursprünglichen Auftrag vergisst und stattdessen macht, was der Angreifer will. Das könnte harmlos klingen – ist es aber nicht. Direkte Injections kommen über die Benutzeroberfläche, indirekte schmuggeln sich über externe Datenquellen ein. In Agentenszenarien, wo KI-Systeme miteinander kommunizieren, kann sich ein einziger kompromittierter Prompt wie ein Virus durch die gesamte Kette fressen.
Auch wir bei Cephei setzen deshalb die Safeguard-Technologie ein. Wir können die Sorgen der Kunden sehr gut nachvollziehen, wir haben sie nämlich selbst. Und deshalb ist unser eigener Chat Prompt ebenfalls mit einem Safeguard geschützt.
Safeguard-Modelle sind extrem schnell. Sie haben sehr kurze Time-To-First-Token und eine hohe Arbeitsgeschwindigkeit (mehrere hundert Token pro Sekunde, je nach Modell und Hardware). Sie sind nur mit spezialisierten Aufrufen verwendbar, die der eigentlichen Anfrage an den Chatbot vorgeschaltet werden. Normal „reden“ kann man mit einem solchen Safeguard-Modell nicht. Das liefert nur eine kurze Begründung und 0 oder 1 in einem Datenfeld des Rückgabe-JSONs. Hier ist ein Leitfaden, wie man das OpenAI-Safeguard-Modell einsetzt.
Falls Sie die Modelle nicht auf eigener Hardware betreiben können oder wollen – die Anforderungen sind moderat, aber vorhanden –, empfehlen wir Ihnen einen Blick auf Groq.com. Groq, nicht zu verwechseln mit Grok von X (Elon Musk), hat sich auf superschnelle und günstige Inferenz für Open-Source-Modelle fokussiert und bietet bereits die neuen Safeguard-Modelle an.
Wie bei jeder Sicherheitstechnologie gilt aber auch hier: Ein einzelnes Werkzeug ersetzt kein durchdachtes Gesamtkonzept. Wenn Sie wissen möchten, wie das in Ihrer Umgebung aussehen könnte – wir sprechen gerne mit Ihnen darüber.
Z.ai hat vor kurzem GLM 5.2 herausgebracht. Vielleicht sagen Sie nun, ach, schon wieder so ein Open-Source-Modell, die sind doch Monate hinter OpenAI und Anthropic. Aber diesmal liegen die Dinge anders. GLM 5.2 ist auf Augenhöhe mit Opus 4.8 und besser als GPT 5.5. Ich habe sogar One-Shot-Demos gesehen, da hat GLM 5.2 besser abgeschnitten als Opus 4.8. Das ist, soweit ich weiß, das erste Open-Source-Modell, das die Marktführer eingeholt hat. Selbst getestet, mit einer guten Harness, wie Goose, Cline, opencode oder Hermes Agent vermisst man nichts mehr. Und während die Kosten bei OpenAI und Anthropic dermaßen explodiert sind, dass sogar Weltkonzerne beginnen müssen, die Token-Usage ihrer Mitarbeiter zu beschränken, kostet GLM 5.2 nur einen Bruchteil. Das ist nicht nur eine Randnotiz für Tech-Nerds. Das könnte eine Finanzkrise von riesigen Ausmaßen lostreten.
Elon Musks Raketenkonzern kauft Cursor für 60 Milliarden Dollar – und viele fragen sich: warum? Wer die Antwort versteht, begreift auch, warum Grok trotz sehr guter Qualität bisher kaum eine Rolle spielt. Und warum sich das jetzt sehr schnell ändern kann. Es gibt dabei aber noch eine zweite Antwort – und die ist deutlich ungemütlicher für Musks Wettbewerber.
Stellen Sie sich vor, Sie haben einen neuen Mitarbeiter eingestellt. Er ist unglaublich schnell, schläft nie, erledigt Aufgaben, die früher Stunden gedauert haben, in Minuten – und er hat uneingeschränkten Zugriff auf jeden Ordner, jede Datei und jeden laufenden Prozess auf Ihrem Rechner. Klingt praktisch? Ist es auch. Bis er einen Fehler macht. Genau das ist die Situation bei den neuen allgemeinen KI-Agenten. Und die Frage, wie man sie sicher ausprobiert, ohne sein Arbeitsgerät aufs Spiel zu setzen, hat eine elegante Antwort – eine, die älter ist als der KI-Hype und trotzdem perfekt passt.
Im letzten Artikel habe ich (auch) darüber geschrieben, dass Ollama plant, die Kompatibilität zu llama.cpp zu verbessern. Das ist jetzt passiert — und wie. Mit v0.30 (aktuell schon bei v0.30.6) hat Ollama die Architektur grundlegend umgebaut: Statt auf GGML aufzusetzen, wird llama.cpp jetzt direkt unterstützt, GGUF-Kompatibilität inklusive. Für Apple Silicon gibt’s außerdem MLX-Beschleunigung, für NVIDIA-Hardware spürbar mehr Performance. Wer die Änderungen im Detail nachlesen will: Die Release Notes auf GitHub sind überschaubar, aber klar. Nun, das alleine wäre schon eine Meldung wert. Aber was mich wirklich umgehauen hat, kam beim Testen.
Nach dem initialen run (oder pull) liegt das Modell lokal auf der eigenen Platte und wird künftig direkt von dort geladen. Und Datenschutz und Privatsphäre sind automatisch dabei.
Wer Modelle parametrisieren möchte, kann sie auch per Modelfile importieren. Das hat Ollama hier erklärt. Aber wer das Modell direkt von Huggingface so nutzen will, wie es dort gespeichert ist, kann sich diesen deutlich aufwändigeren Weg sparen.
Auf Ollama zu warten, hat sich also sehr gelohnt. Das neue Interface ist meiner Meinung der direkteste und leichteste Weg, auf die Huggingface-Bibliothek zuzugreifen. Und die bewährte Ollama-Qualität mit Multitasking und ausgefuchster Speicherverwaltung gibt es natürlich dazu. Bravo, Ollama! Bravissimo!
Georgi Gerganov hat still und leise eine Website lanciert: llama.app. Das klingt unspektakulär, ist aber ein bemerkenswertes Signal – denn Gerganov ist der Mann, ohne den lokale KI so, wie wir sie heute kennen, schlicht nicht existieren würde. „Our goal is to make local AI accessible to everyone“, schreibt Gerganov auf seinem X-Account und reißt, wie er es verspricht, mit seiner neuen Website alle Eintrittsbarrieren nieder. Es gibt ja einige Akteure, die freie und lokale KI möglich machen, zum Beispiel Ollama. Aber oft ist es so, dass man hinter deren „Walled Garden“ eingesperrt ist, und so ist es auch bei Ollama. Braucht man es nun nicht mehr?
Sie sind Entwickler und haben schon viel von der enormen Leistungsfähigkeit der KI beim Coden gehört. Sie spüren, das wird die ganze IT-Branche verändern, und Sie möchten sich auf die neuen Technologien einstellen. Als ITler muss man ja ohnehin ständig dazulernen, kein Problem, denken Sie. Also benutzen Sie zum ersten Mal eine KI für Ihren Code. Chat aufgemacht, Problem beschrieben, Enter gedrückt. Und herauskommt: mittelmäßiger Code. Funktioniert halbwegs, aber weit entfernt von dem, was Sie sich vorgestellt haben. Sie schließen den Tab wieder und denken: „Ist eben noch nicht so weit.“ Und haben eine Riesen-Chance vertan.
Ihre Enttäuschung ist verständlich – aber falsch interpretiert. Das Problem liegt nicht an der KI. Das Problem liegt daran, wie die KI eingesetzt wurde. Denn ein Sprachmodell, dem man im Chatfenster eine Aufgabe beschreibt, arbeitet mit dem, was es bekommt: ein paar Sätze Kontext, keine Projektstruktur, keine Architektur, keine Coding-Guidelines. Das Ergebnis ist dann erwartungsgemäß oberflächlich.
Stellen Sie sich dazu einmal vor, Sie erklären einem brillanten Entwickler Ihr Projekt in drei Sätzen und bitten ihn, ein Feature zu bauen. Ohne Zugang zum Repository, ohne die Doku, ohne zu wissen, welche Patterns im Team gelten. Das Ergebnis wird ähnlich enttäuschend sein. Nicht weil der Entwickler schlecht ist, sondern weil ihm der Kontext fehlt.
Was eine Harness ist – und warum sie alles verändert
In der KI-Welt nennt man das, was das Modell umgibt, die Harness: eine Hülle aus System-Prompts, Projektkontext, Tools, Memory und Workflows, die ein Sprachmodell von einem Chatbot zu einem produktiven Assistenten macht. Der Begriff ist im englischen Sprachraum etabliert und wird auch im Deutschen nicht als „Rüstung“ übersetzt, sondern als Fachbegriff verwendet – vergleichbar mit Framework oder Pipeline.
DeepSeek V4 ist am 24. April in zwei Versionen „Pro“ und „Flash“ erschienen, und wie versprochen ist es Open Source. Die Qualität ist sehr gut, und die Preise bemerkenswert niedrig. Läutet schon das Totenglöcklein für OpenAI und Anthropic?
Mehrere Coding-Spezialisten haben das neue Modell von DeepSeek schon unter die Lupe genommen, und deren Urteil ist einhellig: GPT 5.5 von OpenAI hat derzeit die Krone im Coding inne, es folgt Opus 4.7 von Anthropic, dann DeepSeek mit V4, dann Kimi mit K2.6.
Das könnte Open Source-Fans enttäuschen, aber man muss das in Relation setzen. DeepSeek ist nur noch ca. 3 Monate zurück, und es kostet nur einen Bruchteil. OpenAI hat ja mal eben die Token-Preise für GPT 5.5 verdoppelt, und Anthropic, das sowieso schon ein Token-Burner immer war, braucht für Opus 4.7 35% noch mehr Token gegenüber dem bisher schon heftigen Tokenverbrauch.
Und es ist außerdem ja so, nicht jedes Problem ist in der schwierigsten Liga. Anders gesagt: Da DeepSeek nun so weit aufgeholt hat, ist die Anzahl der Probleme, an denen es scheitert, viel kleiner geworden.
Das beliebte Python-Paket LiteLLM, das als einheitlicher Proxy für über 100 verschiedene KI-Modelle (darunter OpenAI, Azure, Anthropic und viele weitere) dient und monatlich millionenfach von PyPI heruntergeladen wird, wurde Opfer eines schwerwiegenden Supply-Chain-Angriffs. Die Angreifergruppe „TeamPCP“ kompromittierte mindestens zwei Versionen des Pakets (1.82.7 und 1.82.8) und injizierte Schadcode, der beim Installieren automatisch eine Remote-Backdoor auf den betroffenen Systemen einrichtete. Konkret wurde im Post-Install-Skript ein Befehl versteckt, der über eine Google Cloud-Adresse ein Shell-Skript nachlud und einen Hintergrundprozess startete, welcher den Angreifern persistenten Zugriff auf die kompromittierten Server ermöglichte. Die schadhaften Versionen waren dabei als reguläre Updates getarnt und für Nutzer auf den ersten Blick nicht erkennbar.
Die Auswirkungen dieses Angriffs sind potenziell enorm: Jedes Unternehmen, das LiteLLM als KI-Gateway einsetzt – und dazu gehören zahlreiche Firmen, die damit API-Schlüssel, Nutzerdaten und vertrauliche Prompts über ihre KI-Infrastruktur leiten –, könnte betroffen sein. Da LiteLLM häufig als zentraler Knotenpunkt in der KI-Architektur fungiert und mit weitreichenden Berechtigungen ausgestattet ist, hatten die Angreifer im schlimmsten Fall Zugriff auf sämtliche API-Keys, Zugangsdaten zu Cloud-Diensten und interne Kommunikation. Besonders brisant: Der Schadcode wurde nicht durch einen Hack der LiteLLM-Codebasis selbst eingeschleust, sondern über kompromittierte Maintainer-Zugangsdaten bei PyPI – ein Angriffsvektor, der zeigt, wie verwundbar selbst weit verbreitete Open-Source-Projekte in ihrer Lieferkette sind. Die betroffenen Versionen wurden mittlerweile von PyPI entfernt und sichere Nachfolgeversionen veröffentlicht.
Für Unternehmen, die LiteLLM im Einsatz haben, besteht dringender Handlungsbedarf: Zunächst sollte sofort geprüft werden, ob eine der kompromittierten Versionen installiert ist, und ein Update auf eine bereinigte Version durchgeführt werden (das Repository von LiteLLM wurde auf 1.82.3 zurückgesetzt in der ersten Reaktion des Maintainers, diese Version scheint also noch sicher zu sein). Darüber hinaus empfiehlt es sich, sämtliche API-Schlüssel und Zugangsdaten, die über LiteLLM geroutet wurden, als potenziell kompromittiert zu betrachten und umgehend zu rotieren.
Dieser Vorfall unterstreicht einmal mehr die Notwendigkeit, Software-Abhängigkeiten konsequent zu überwachen – etwa durch den Einsatz von Dependency-Pinning, Hash-Verifikation, Software Bill of Materials (SBOM) und automatisierten Security-Scans in der CI/CD-Pipeline. Der LiteLLM-Angriff ist ein Weckruf für die gesamte KI-Branche: Wer KI-Infrastruktur betreibt, muss Supply-Chain-Sicherheit als erstrangige Priorität behandeln.
Auf Twitter/X raunt man von 500K betroffenen Systemen, und 3 GB gestohlenen Daten. Besonders perfide außerdem, dass mit der Installation einer verwundbaren Version von LiteLLM das gesamte PyPI-Ökosystem auf einem System betroffen wurde. Die primäre Schadcode-Komponente nutzte dabei eine im Zusammenhang mit PyPI-Angriffen neuartige Technik: eine .pth-Datei namens litellm_init.pth (34.628 Byte), die im Verzeichnis „site-packages“ von Python abgelegt wurde. (.pth-Dateien werden von Python beim Start automatisch ausgeführt – das bedeutet, der Schadcode lief nicht nur bei der Nutzung von LiteLLM, sondern bei jedem Python-Aufruf auf dem betroffenen System.) Tja. Dergleichen blüht uns nun bestimmt auch bei künftigen weiteren Attacken auf Package-Registries und Code-Repositories.
Was LiteLLM selbst angeht, war die Installation via Docker ein probates Mittel, um das Problem zumindest einzudämmen. Weder die Verseuchung des gesamten Python-Systems, noch die Verankerung in systemd waren damit möglich, so dass sich die betroffenen Schlüssel ggfs. recht einfach eingrenzen ließen. Aber wie ist es mit Abhängigkeiten, also Systemen, die LiteLLM nachladen? Kaum zu überschauen, wo das Problem überall hineinschleichen konnte.
Generell ist Docker immer empfehlenswert aus Security-Sicht, das kann man dem Vorfall wieder einmal entnehmen. Aber wie das zunehmend komplexe Gefüge der aufeinander aufbauenden Software-Stacks absichern kann, das macht einen schaudern für die Zukunft. LiteLLM (bzw. BerriAI, das Unternehmen dahinter) hat sogar eine SOC 2 Type II Zertifizierung!
Dieser Angriff, der übrigens offenbar auch alle Merkmale von KI-gestütztem Coding aufweist, zeigt außerdem eine beunruhigende Synergie: Supply-Chain-Angriffe werden zunehmend durch KI-generierte Inhalte unterstützt – sei es durch täuschend echte Phishing-Mails, gefälschte Maintainer-Kommunikation oder manipulierte Dokumentation. Und dazu das Problem der immer zunehmenden und immer besser werdenden KI-generierten sonstigen Inhalte überall. Mittlerweile sind die Fakes und Betrugsversuche so gut geworden, dass es auch für sehr erfahrene Fachleute immer schwerer wird, echten Content zuverlässig zu erkennen. Geht es bald wieder zurück zu „Von Angesicht zu Angesicht“, sonst kann man rein gar nichts mehr glauben?
Wer OpenClaw verwendet, wird schnell feststellen, dass der Token-Verbrauch enorm werden kann. „Erinnerungen auf Steroiden“ haben ihren Preis. Zwar sind die Kosten für Input-Token immer deutlich niedriger als die Kosten für Output-Token, aber wenn jedesmal ein riesiger Berg von Kontext mit dem Prompt mitgeschickt wird, summiert sich das sehr schnell. Hinzu kommt, dass die großen und bekannten Anbieter die Verwendung von Chat-Accounts für Agenten explizit verbieten. Deren Pauschalangebote gelten nur für die Interaktion per Browser. Gibt es Alternativen?
Interessanterweise sind es gerade chinesische Anbieter, die attraktive Angebote speziell für agentische KI entwickelt haben. Vor allem Moonshot (mit dem Abo-Plan für Kimi Code) und MiniMax bieten Pauschalverträge mit garantierten (und günstigen) monatlichen Kosten, und bewerben explizit den Einsatz von Agenten wie OpenClaw damit. Das ist sehr schlau, denn das ist die offene Flanke der großen Anbieter. Deren – Verzeihung – gierige Preisgestaltung öffnet Möglichkeiten für die Konkurrenz, die sich bisher in der Breite noch schwer tut.
Es gibt bei Moonshot und MiniMax Usage-Limits, aber sie sind sehr großzügig bemessen und werden regelmäßig zurückgesetzt. Man kann also bei diesen Anbietern eine OpenClaw-Instanz betreiben zu einem fixen monatlichen Preis von 20 US$ oder noch weniger. Sprich, mit einem bekannten und überschaubaren Kostenrisiko. Neulich las ich einen Tweet, jemand schrieb, er habe OpenClaw mit einem der großen KI-Platzhirsche eingesetzt, und nach nur einem Monat schon über 3.600 US$ Rechnung eingefahren. Aber kein Wunder. Was OpenAI und Anthropic bei der verbrauchsorientierten Abrechnung per API-Key verlangen, sprengt jeden Rahmen, wenn OpenClaw mit seinem riesigen Kontext verwendet wird.
Die Modelle von Moonshot (Kimi Code) und MiniMax sind sehr gut, für agentische Aufgaben optimiert und können durchaus mit den besten Modellen von OpenAI und Anthropic mithalten. Doch vielleicht hat günstig auch seine Schattenseiten: Agentische KI könnte sich als hervorragendes Einfallstor für Industriespionage erweisen.
Insofern wäre unser Rat, die enormen Möglichkeiten agentischer KI zwar nicht zu ignorieren, aber wenn Sie etwas Derartiges betreiben möchten, fahren Sie es auf einer dedizierten Maschine, der Sie nur Aufgaben geben, für die Privacy kein allzu hoher Faktor ist. Solche (virtuellen) Instanzen können Sie schon ab 5 Euro im Monat mieten bei vielen Betreibern wie z.B. Hetzner. Oder Sie schnappen sich einen alten Schluffi, der irgendwo bei Ihnen noch herumliegt, und geben ihm ein neues Leben. Denn die Leistung der Maschine, auf der der KI-Agent läuft, muss nicht sonderlich groß sein. Die eigentliche Arbeit erledigt ja eine KI anderswo.
Sehr interessant sind auch ein Mac mini oder Mac Studio. Durch das Unified Memory von Apple können Sie auf diesen Geräten Ollama lokal betreiben und sehr große Modelle ausführen, wenn Sie einen Mac mit viel Speicher wählen. Das ist dann zwar eine sehr viel höhere Anfangsinvestition, hat aber keine monatlichen Kosten. Und Ihre Privatsphäre und Datensicherheit ist mit dieser Variante auch bestens garantiert.
OpenClaw, vormals MoltBot, vormals ClawdBot (Anthropic erzwang eine Namensänderung, und dann gefiel die erste Änderung doch nicht und man nannte nochmals um) ist eine coole Sache. Haben Sie schon einmal die Erinnerungen für eine Chat-KI ausprobiert? Bei OpenAI gibt es das, andere haben das bestimmt ebenfalls. Auch Open WebUI bietet eine experimentelle Implementierung bereits an. Es ist jedenfalls verblüffend, wieviel besser die Antworten werden, wenn die KI mit Erinnerungen vergangener Gespräche arbeiten kann.
Und OpenClaw ist Erinnerungen auf Steroiden. Merkt sich wirklich alles, genial gemacht. Und das ergibt ganz erstaunlich gut passende Antworten. Außerdem hat OpenClaw die Möglichkeit, auf das gesamte System zuzugreifen, auch auf digitale Accounts des Nutzers in den sozialen Medien und noch viel mehr. Natürlich, das muss man erstmal alles freischalten, aber wenn man es tut, dann kann OpenClaw auf Twitter oder Telegram posten, Mails verschicken, sogar telefonieren, auch auf Ihre Bankverbindung und Kreditkarten zugreifen, und mehr.
Vor nur sechs Monaten lebten wir in einer anderen Zeit. In der Welt der KI ist das eine Ewigkeit. Damals staunten wir über Chatbots, die leidlich gute E-Mails schreiben konnten und Code-Schnipsel erzeugten, die man „nur noch ein bisschen“ korrigieren musste. Heute? Heute wirken diese Tools wie Relikte aus der Steinzeit.
Wir stehen an einem Wendepunkt, der so steil ist, dass wir kaum noch den Gipfel sehen können.
Schauen wir uns an, was gerade passiert: Eine exponentielle Explosion der Fähigkeiten. Ein Blick auf aktuelle Entwicklungen, wie sie beispielsweise Cursor in ihrem Blog über „Scaling Agents“ beschreibt, öffnet einem die Augen. 1000 Agenten, 1 Million Zeilen Code, 1 Woche: Fertig ist ein voll funktionsfähiger Browser. Ein Browser! Eine der komplexesten Aufgaben überhaupt.
Immer wieder braucht man Passwörter. Für eine Webseite, einen Dienst, was auch immer. Man sollte es ja tunlichst vermeiden, ein Passwort mehrfach zu benutzen. Wird ein Account gehackt bei einem Anbieter, sind gleich Dutzende andere weg, Sie kennen das.
Und als Entwickler benötigt man für seine Anwendungen außerdem API-Keys, für die es spezifischere Anforderungen gibt, weil sie sich für Weitergabe in einer URL und die Befehlszeile eignen müssen.
