Eine gemeinsame KI-Rechnung im Haushalt teilen

openplate folgt dem Bring-Your-Own-Key-Prinzip: Jede Person bindet ihren eigenen KI-Anbieter an die App an und zahlt ihre eigenen Teller-Scans. In einem Haushalt ist das unsinnig. Niemand möchte vier Konten bei einem Anbieter, und ein einzelner geteilter Schlüssel ist noch schlechter: Du kannst nicht nachvollziehen, wer wie viel ausgegeben hat, und sperrst du eine Person, sperrst du alle.

Hierfür brauchst du keinen Server. Die Lösung liegt beim Anbieter: ein Konto, ein Schlüssel pro Person, ein Ausgabenlimit pro Schlüssel. Lies zuerst diesen Abschnitt; die beiden Serverlösungen weiter unten sind für jene Fälle gedacht, die dieser Ansatz nicht abdeckt.

Hier wird kein Tagebuch geteilt. Das Ernährungstagebuch jeder Person bleibt im Speicher des eigenen Browsers auf dem jeweiligen Gerät. Über das Netz gehen nur ein Foto hin und ein Schätzwert zurück. Die Person, die die Rechnung bezahlt, sieht die Anzahl der Anfragen pro Person und die entstandenen Kosten. Sie sieht nicht, wer was gegessen hat.

Die Kurzfassung, mit OpenRouter

OpenRouter kann beliebig viele API-Schlüssel unter einem Konto erzeugen, jeweils mit eigenem Ausgabenlimit und eigener Nutzungszeile. Das ist genau die Funktion, die ein Haushalt braucht.

1. 01
   Eine Person erstellt das Konto auf openrouter.ai und lädt Guthaben auf. Nur diese Person meldet sich je an, niemand sonst braucht ein Konto.
2. 02
   Öffne die Schlüsselseite und erstelle einen Schlüssel pro Person. Benenne jeden Schlüssel nach der jeweiligen Person: Genau diesen Namen siehst du später in der Verbrauchsübersicht, „Sam“ ist also besser als „Schlüssel 3“.
3. 03
   Setze beim Erstellen jedes Schlüssels ein Ausgabenlimit. Das ist die Obergrenze. Ein Schlüssel ohne Limit kann das gesamte Kontoguthaben aufbrauchen. Betrachte "unbegrenzt" daher als etwas, das du hier vermeiden willst.
4. 04
   Schicke jeder Person ihren eigenen Schlüssel. Schicke ihn so, wie du ein Passwort verschicken würdest, nicht in einem dauerhaft gespeicherten Gruppenchat.
5. 05
   Jede Person fügt ihn ein. In openplate: Einstellungen → KI, wähle OpenRouter und nutze den Bereich "API-Schlüssel manuell einfügen". Der Schlüssel wird nur in diesem Browser gespeichert. Er ist vom JSON-Export ausgenommen und erreicht den openplate-Server nie.

Das ist die gesamte Einrichtung. Fünf Minuten, kein Container, keine Wartung.

Im Betrieb

• Wer was ausgegeben hat: Das OpenRouter-Dashboard schlüsselt die Nutzung nach Schlüsseln auf. Weil jeder Schlüssel nach einer Person benannt ist, ist das deine Abrechnung pro Person.
• Einer Person den Zugang entziehen: lösche ihren Schlüssel. Niemand sonst ist betroffen, niemand sonst ändert eine Einstellung, und die gesperrte Person hat keine Ausweichmöglichkeit mehr: Dieser Schlüssel war ihr einziger Zugang. Ihr Tagebuch bleibt unberührt; es lag nie auf dem Schlüssel.
• Jemandem mehr Guthaben geben: Erhöhe das Limit dieses Schlüssels. Wirkt sofort, nirgends ist ein Neustart nötig.
• Der Schlüssel von jemandem funktioniert nicht mehr: Die Person hat ihr Limit erreicht oder du hast den Schlüssel gelöscht. openplate zeigt den Fehler des Anbieters an. Die Lösung liegt auf der Schlüsselseite, nicht in der App.

Begrenze auch das Konto, nicht nur die Schlüssel. Limits pro Schlüssel begrenzen jede Person, aber das eigentliche Kontoguthaben wird abgebucht. Halte das Guthaben auf einer Höhe, deren Verlust du verschmerzen kannst, und lade es gezielt auf.

Das Ganze automatisieren. OpenRouter bietet auch eine API, um Schlüssel programmatisch zu erstellen und zu verwalten. Das ist nützlich, wenn du Zugänge für mehr als nur eine Handvoll Personen einrichtest. Für eine Familie geht das Dashboard schneller als ein eigenes Skript.

Die andere Alternative: eine verwaltete openplate-core-Instanz

Falls dein Anbieter keine begrenzten Unterschlüssel ausstellt (Mistral, die meisten direkten Anbieter-APIs), läuft die obige Anleitung für Unterschlüssel ins Leere. Genau dafür gibt es eine verwaltete openplate-core-Instanz: Setze INSTANCE_MODE=managed (erfordert CORE_URL), und der Kontodienst, den dein Haushalt bereits für die Synchronisierung nutzt, fungiert gleichzeitig als KI-Proxy, mit einem täglichen Anfragekontingent pro Konto.

Wähle diese Option statt Anbieter-Unterschlüsseln, wenn:

• Dein Anbieter kein Ausgabenlimit pro Schlüssel anbietet und die Begrenzung daher an einem Ort liegen muss, den du kontrollierst.
• Du ein tägliches Anfrage- Limit pro Person willst statt eines Guthabens pro Person.
• Du deinen Haushalt an deinen eigenen openplate-inference-Rechner anbindest, bei dem es überhaupt kein Anbieter-Dashboard gibt; eine verwaltete Instanz liefert dann das Kontingent pro Person und die Nutzungsdaten, die der unten beschriebenen API_KEYS-Erlaubnisliste fehlen.
• Du möchtest, dass ein Widerruf ein einzelner Klick in der Verwaltungsoberfläche ist, statt eines geteilten Schlüssels, den jeder neu einfügen muss.

Bleibe bei Anbieter-Unterschlüsseln, wenn du kannst. Wenn du OpenRouter nutzt, warst du schon vor fünf Minuten fertig und musst keinen Dienst am Laufen halten.

Einrichtung: Fahre openplate-core hoch (siehe sync.md und topologies.md), und setze INSTANCE_MODE=managed in der openplate-App. Richte den Core-Server mit UPSTREAM_BASE_URL, UPSTREAM_API_KEY und AI_ADVERTISED_MODEL in .env auf deinen Anbieter aus. Die letzte Zeile ist erforderlich. Ohne Modell scannt die App nicht. Erzeuge die erste Einladung für dich selbst auf dem Server mit ADMIN_TOKEN als Administrator (self-hosting.md enthält den Befehl). Lade von dort aus Personen unter /admin in der App ein und weise jedem Konto ein tägliches Kontingent zu. Wenn auf dem Core-Server E-Mail eingerichtet ist, geht die Einladung per Mail an die Person. Ist keine eingerichtet, zeigt /admin dir den Link, und du verschickst ihn so, wie du ein Passwort verschicken würdest. Bei einem vergessenen Passwort läuft es genauso. Ohne eingerichtete E-Mail fragt dich der Nutzer, und du erstellst den Link zum Zurücksetzen unter Personen in /admin. Jede Person meldet sich an, und ihr Konto bringt die KI-Verbindung bereits mit. Es gibt keinen separaten Schritt und nichts einzufügen. Konten sperren oder wieder aktivieren geschieht in derselben Admin-Ansicht und wird sofort wirksam.

Zwei Dinge solltest du wissen, bevor du dich darauf verlässt. Das Kontingent zählt Anfragen, kein Geld, setze also auch beim Upstream-Schlüssel des Anbieters ein festes Ausgabenlimit: Nur der Anbieter kann Geldflüsse stoppen. Und das Kontingent einer Person wird pro Konto ausdrücklich festgelegt; es gibt keinen unbegrenzten Standardwert.

Synchronisierung und KI-Proxy sind nun derselbe Dienst, daher sieht der Server einer verwalteten Instanz mehr als ein unverwalteter: eine E-Mail-Adresse, Geheimtext, für den er keinen Schlüssel besitzt, und bei einem Scan das Foto, das einmalig gelesen und nicht gespeichert wird. Er sieht einen Tagebucheintrag trotzdem nie im Klartext. Siehe architecture.md für die genaue Übersicht darüber, welche Komponente welche Daten speichert.

Die Alternative: ein geteilter Inferenz-Rechner

Wenn du die Hardware besitzt, ist der andere Weg, sich eine Rechnung zu teilen, gar keine Rechnung zu haben. Betreibe openplate-inference auf einem Rechner zu Hause, und jeder Scan im Haus wird lokal berechnet, ganz ohne Cloud-Anbieter. Siehe topologies.md für die Kosten an Hardware und Betriebsaufwand: Es ist ein deutlicher Schritt gegenüber dem Einfügen von fünf Schlüsseln in ein Dashboard.

Dafür gibt es ebenfalls Schlüssel pro Person, wenn auch gröbere. API_KEYS auf dem Inferenz-Container ist eine kommagetrennte Liste akzeptierter Bearer-Schlüssel:

-e API_KEYS="opk_alex_...,opk_sam_...,opk_robin_..."

Gib jeder Person einen Eintrag aus dieser Liste, und jede fügt ihren Schlüssel in openplate unter Einstellungen → KI → OpenAI-kompatibel ein, zusammen mit der Basis-URL der Instanz (zum Beispiel http://openplate.example.lan:8300/v1) und dem Modell openplate-plate-1. Entfernst du einen Schlüssel aus der Liste und startest neu, widerrufst du den Zugang genau dieser Person.

Zwei ehrliche Einschränkungen im Vergleich zu Anbieter-Unterschlüsseln:

• Es gibt kein Ausgaben- oder Ratenlimit pro Schlüssel. Die Liste ist nur eine Erlaubnisliste, nicht mehr. Das reicht aus, wenn die Ressource deine eigene ungenutzte GPU ist und an einer Anfrage kein Geld hängt.
• Du musst die Schlüssel selbst erzeugen und verteilen. Jede beliebige Zeichenkette funktioniert (openssl rand -base64 24); es gibt kein Dashboard und keinen Verbrauchsbericht pro Person: Du erhältst die Protokolle des Containers.

Vollständige Liste der Variablen: openplate-inference docs/configuration.md.

Nutze für diesen Zweck nicht die Abkürzung über die von der Instanz bereitgestellte KI. Setzt du DEFAULT_INFERENCE_API_KEY bei openplate, verbindet sich jede Person mit einem Fingertipp und ohne Schlüssel, aber dieser Schlüssel ist im HTML der Seite eingebettet und über den Seitenquelltext für jeden lesbar, der die App aufrufen kann. Damit hast du wieder einen gemeinsamen Zugang mit genau dem Problem, von dem du ausgegangen bist. Für ein LAN oder Tailnet, in dem du jedem Zugriffsberechtigten vertraust, ist das in Ordnung, sonst nirgends. Siehe configuration.md.

Konten für die Familie

Sync und eine verwaltete Instanz geben jeder Person ein Konto auf dem von dir betriebenen openplate-core-Dienst.

• Nutze Einladungen. Das erste Konto erstellst du für dich selbst auf dem Server (self-hosting.md enthält den Befehl). Lade danach jede Person über /admin in der App ein.
• Lass OPEN_SIGNUP ausgeschaltet. Damit kann jeder, der die Adresse findet, ein Konto anfordern. Eine Familie hat dafür keine Verwendung.
• E-Mail ist optional. Ohne E-Mail zeigt /admin jeden Einladungs- und Zurücksetzungs-Link an, und du gibst ihn selbst weiter. self-hosting.md erklärt beide Wege und wie du E-Mail einrichtest, falls du es möchtest.