Jev erkennt jetzt Fotos: Vom Rücksendecheck zur Fundstelle des Schadens
Jevs experimentelle Bildfunktion macht Fotos zu typisierten Bewertungen und Begrenzungsrahmen. Verfolge einen Rücksendeablauf mit einer Tasse, lerne die Präsenzprüfung kennen und bereite einen sicheren ersten Prototyp vor.
Eigene Erläuterungsgrafik: Ein Foto wird eingegeben, getrennte Bewertungen und Koordinaten kommen zurück; anschließend prüft ein Mensch den vorgeschlagenen Schaden. Sie veranschaulicht einen Ablauf, kein aufgezeichnetes Modellergebnis.
Ein Kunde fotografiert eine angeschlagene Tasse. Das Supportwerkzeug muss drei verschiedene Fragen beantworten: Ist die Tasse zu sehen? Zeigt das Bild einen Schaden? Und wohin soll der Prüfer blicken? Ein flüssig formulierter Absatz über Keramik ist nicht das nützlichste Zwischenergebnis.
Am 14. Oktober 2026 kündigte TypeSafe AI experimentelle Bildunterstützung für Jev zusammen mit Jev 1.14.0 und einem neuen Ausgabetyp box an. Bilder funktionieren sowohl mit Jev 1.13 als auch mit 1.14; Box erfordert Version 1.14. TypeSafe bezeichnet diese Funktionen als experimentell und rät ausdrücklich davon ab, sie bereits für Produktionsautomatisierung zu empfehlen. Offizielle Ankündigung
Die nützliche Neuerung ist enger gefasst als ein universeller multimodaler Assistent: Ein Foto kann zu einer typisierten Entscheidung oder zu einer Position innerhalb eines Programms werden. So verändert das einen Rücksendeablauf, das akzeptiert die Schnittstelle, und so baust du einen vorsichtigen Prototyp, ohne ein Rechteck mit einem Beweis zu verwechseln.
Kurzfassung:
- Jev bietet jetzt einen experimentellen Weg zum Verständnis einzelner Standbilder, nicht zur Bilderzeugung.
- Frage zuerst, ob ein Zielobjekt vorhanden ist, bevor du seiner vorgeschlagenen Position vertraust.
- Bewahre Originalfoto und menschliche Prüfung. Lass den Code Koordinaten, Berechtigungen und Folgen validieren.
Ein Foto kann eine Entscheidung statt einer Beschreibung hervorbringen
Jev war ursprünglich für begrenzte Antworten interessant: eine vorgegebene Option auswählen, anhand beschriebener Stufen bewerten oder eine Ja/Nein-Aussage prüfen. Unser früherer Leitfaden zu Jevs Entscheidungsmodell erläutert diese Grundlage. Die Neuerung: Diese Fragen erhalten visuelle Belege und eine Möglichkeit, räumliche Koordinaten zurückzugeben.
Für eine Rücksendeoberfläche verändert das die Aufgabenverteilung. Das Modell kann vorschlagen, dass ein Schaden sichtbar ist; Anwendungscode kann den Vorschlag neben dem eingereichten Foto anzeigen. Keiner der Schritte belegt, wann der Schaden entstanden ist, ob das Foto zu dieser Bestellung gehört oder ob eine Rückerstattung genehmigt ist. Das sind getrennte Fragen, für die jeweils andere Belege nötig sind.
| Ein- oder Ausgabe | Was die dokumentierte Schnittstelle unterstützt | Was deine Anwendung bereitstellen muss |
|---|---|---|
| Fotoeingabe | Experimentelle PNG-/JPEG-Standbilder | Erlaubnis zur Bildverarbeitung und Vorbereitung vor dem Upload |
| Audioeingabe | Keine native Audioeingabe | Anderswo erzeugtes Transkript oder strukturierte Felder |
| Videoeingabe | Keine native Eingabe von Videodateien | Ausgewählte Einzelbilder oder extrahierter Text, kein hochgeladenes Video |
| Dokumenteingabe | Text/JSON; eine gescannte Seite kann als Bild behandelt werden | PDF-/DOCX-Parsing oder Rendern der Seiten außerhalb von Jev |
| Ausgabe | Festgelegte Labels, Scores, Wahrscheinlichkeiten und Box-Koordinaten | Darstellung, Zuschnitt, Dokumenterstellung und jede geschäftliche Aktion |
Diese Grenzen gehen aus der Modellreferenz, dem API-Anfragevertrag und dem bildfähigen SDK hervor. Ein Ordner mit PDFs wird nicht allein deshalb zu einer Dokumentverarbeitungspipeline, weil manche Seiten Bilder enthalten. Ebenso belegen mehrere extrahierte Einzelbilder weder natives Videoverständnis noch den Zugriff auf die Tonspur eines Clips.
Unser Fazit: Interessant ist eine kleine, überprüfbare Bewertung, die an Belege gebunden ist. Sie ist keine neue Erlaubnis, alle nachgelagerten Schritte zu automatisieren.
Drei offizielle Beispiele machen aus demselben Foto unterschiedliche Aufgaben
TypeSafes JavaScript-Dokumentation enthält drei konkrete Einstiegsmuster. Es sind veröffentlichte Codebeispiele, keine Berichte über Produktiveinsätze bei Kunden oder gemessene Ergebnisse. Betrachte sie als Muster für einen Prototyp, nicht als Versprechen zur Genauigkeit deiner Fotos.
Das erste Beispiel kombiniert eine Meldung über eine beschädigte Tasse mit einem Produktfoto und fragt einen Noul nach dem Schaden und einen Score nach dessen Stärke. In einer Support-Warteschlange könnte eine Anpassung mutmaßliche Schäden zur genaueren Prüfung nach oben sortieren. Ein Prüfer sollte weiterhin das vollständige Foto, die Beschreibung des Kunden und eine Möglichkeit sehen, den Vorschlag abzulehnen.
Das zweite Beispiel vergleicht ein hochgeladenes Verkäuferfoto mit einem Katalogbild. Es fragt, ob beide dasselbe Produkt zeigen, und klassifiziert die Bildqualität, etwa Unschärfe, Beschnitt und produktfremde Inhalte. Für einen Marktplatz ergibt sich daraus eine sinnvolle Trennung: Identitätsabgleich und Bildqualität müssen nicht in dieselbe Freigabeentscheidung einfließen. Ein klares Bild des falschen Produkts sollte nicht allein deshalb bestehen, weil es professionell aussieht.
Das dritte Beispiel bittet Box, den beschädigten Bereich zu lokalisieren. Das Ergebnis könnte einem Prüfer eine Einblendung oder einen vorgeschlagenen Ausschnitt anzeigen. Bewahre daneben das unbeschnittene Original auf: Die Aufmerksamkeit auf einen kleineren Bereich zu lenken hilft bei der Prüfung, kann aber auch Kontext verbergen, der die Bedeutung verändert.
Folge den offiziellen Beispielen zu Schadensbewertung, Katalogvergleich und Schadenslokalisierung. Unser vorgeschlagener Rücksendeablauf ergänzt diese Muster um Schutzmaßnahmen der Anwendung; er ist kein Bericht über einen durchgeführten Versuch.
Ein Rahmen kann nicht erkennen, dass es nichts zu finden gibt
Das entscheidende Detail im Box-Vertrag von TypeSafe: Für ein nicht vorhandenes Zielobjekt gibt es keine eigene Ausgabe. Eine Box-Frage gibt vier Kanten zurück, selbst wenn das gesuchte Objekt fehlt. Ein Rahmen um eine unbeschädigte Tasse kann daher für sich genommen nicht belegen, dass ein Schaden existiert.
Frage einen separaten Noul, ob das gesuchte Objekt vorhanden ist. Unterscheide in diesem Ablauf, ob die Tasse sichtbar ist und ob ein Schaden sichtbar ist. Eine positive Antwort zur Tasse reicht nicht aus, um eine Schadensmarkierung freizugeben. Ignoriere den vorgeschlagenen Schadensrahmen, bis die für deine geprüften Regeln relevanten Präsenzprüfungen bestanden sind.
Diese Präsenzprüfung ist ein vorgeschaltetes Tor, keine Garantie gegen Fehler. Beide Bewertungen können gleichzeitig falsch sein. Eine helle Spiegelung kann wie eine Absplitterung wirken, während ein echter Riss auf einer gemusterten Glasur untergeht. Teste vor der Festlegung von Schwellenwerten Fotos ohne Tasse, unbeschädigte Tassen, mehrdeutige Spiegelungen, mehrere Objekte und deutlich sichtbare Schäden.
Originalgrafik zum Entscheidungsablauf: Ein gültiges Rechteck ist erst nutzbar, wenn die Präsenzprüfung bestanden wurde. Bei fehlgeschlagenen oder unsicheren Prüfungen bleibt das Originalfoto für die menschliche Prüfung erhalten; es wird nicht automatisch abgelehnt.
Betrachte das Rechteck als Zeiger, nicht als Urteil.
Behandle Koordinaten als Geometrie und prüfe dann ihre Bedeutung
Box gibt left, right, top und bottom als Anteile der Bildabmessungen zurück, gemessen ab der linken oberen Ecke. Die Werte liegen zwischen 0 und 1, wobei left < right und top < bottom gelten muss. Eine Frage liefert eine Box, keine Liste von Objekterkennungen. Vertrag zur Box-Antwort
Für ein beispielhaft vorbereitetes Bild mit 1200 x 900 Pixeln entsprechen linke Kante 0.20, obere Kante 0.30, rechte Kante 0.60 und untere Kante 0.70 den Pixelpositionen 240, 270, 720, 630. Das ist eine Rechenillustration, keine Jev-Antwort. Zuschnitt-APIs erwarten häufig links, oben, rechts, unten. Ordne daher benannte Felder bewusst zu, statt dich auf die Reihenfolge von JSON-Eigenschaften zu verlassen.
Prüfe vor jeder Darstellung, dass Werte endlich, innerhalb der Grenzen und korrekt angeordnet sind. Kontrolliere danach, ob der Bereich tatsächlich den Schaden bezeichnet. Wenn du ein Foto skalierst, drehst, auffüllst oder kachelst, bewahre die Transformation auf, mit der du Koordinaten zurückprojizieren kannst; andernfalls kann ein plausibler Rahmen auf die falschen Pixel zeigen.
Bereite das Bild vor der Anfrage vor, nicht erst nach einem Fehler
Die offiziellen Bildgrenzen sind genau und inklusive. Ein Bild außerhalb der Vorgaben wird abgelehnt, statt automatisch skaliert zu werden; ein einziges abgelehntes Bild lässt die gesamte Anfrage fehlschlagen.
| Einschränkung | Veröffentlichte Grenze |
|---|---|
| Format | PNG- oder JPEG-Standbild; animiertes PNG wird abgelehnt |
| Einzeldatei | 16 MiB, gegebenenfalls nach Base64-Dekodierung gemessen |
| Jede Abmessung | 280 bis 1568 Pixel |
| Gesamtzahl Pixel | 78.400 bis 2.458.624 |
| Anfragekörper | 32 MiB einschließlich JSON und Upload-Rahmendaten |
| Gemeinsam verarbeitete Bilder | 32 MiB |
| Erweiterte Anfrage | 32 MiB, nachdem Bildreferenzen ersetzt wurden |
Wiederholte Referenzen werden in der erweiterten Anfrage erneut gezählt. Dateigröße, Abmessungen und Kontextlänge sind getrennte Prüfungen. Bildgrenzen
Originalgrafik zu den Vorgaben nach TypeSafes Bilddokumentation, geprüft am 18. Oktober 2026. Grenzen für Einzeldatei, verarbeitete Bilder, erweiterte Anfrage und Anfragekörper gelten unabhängig voneinander.
TypeSafe weist außerdem an, die Pixel vor dem Senden aufrecht zu drehen: Die API entfernt Metadaten und wendet die EXIF-Ausrichtung nicht an. Konvertiere nicht unterstützte Formate vorab. Hinweise zur Vorbereitung
Bereite für einen Prototyp eine eindeutig benannte Kopie eines eigenen Fotos vor und lass das Original unverändert. Prüfe Abmessungen lokal und sieh dir genau die Kopie an, die gesendet werden soll. Ein schmaler Zuschnitt muss eventuell aufgefüllt werden, um die Mindestabmessung zu erfüllen; dokumentiere diese Auffüllung, bevor du Koordinaten auswertest.
Fixiere Version 1.14 und aktiviere den experimentellen Schalter ausdrücklich
Am 18. Oktober ordnet die veröffentlichte Alias-Tabelle jev-latest der Version jev-1.13.0 und jev-preview der Version jev-1.14.0 zu. Verwende für ein Box-Beispiel ausdrücklich jev-1.14.0, statt anzunehmen, dass „latest“ die neueste Vorschau meint. Modell-Aliase
Das folgende Verfahren erstellt ein lokales Beispiel, das nur der Prüfung dient. Der letzte Befehl sendet eine kostenpflichtige Inferenzanfrage, die das SDK erneut versuchen kann; er genehmigt weder eine Rücksendung noch ändert er ein Konto. Verwende ein bereitgestelltes Foto, das dir gehört und auf dem keine Personen, Versandetiketten, Adressen oder privaten Dokumente zu sehen sind.
-
Verschaffe dir Zugang und wähle die richtige Organisation. TypeSafe zufolge ist für die Anmeldung keine Wartelistenfreigabe mehr erforderlich. Erstelle einen API-Schlüssel in der Konsole und prüfe vor dem Testen die Credits der Organisation. Kontozugriff, Credit-Einstellungen
-
Verwende Node.js 22 oder neuer. Die JavaScript-SDK-Version mit Bildunterstützung heißt
0.7.0und ist auf den 14. Oktober datiert. Durch die feste Version ist die Clientabhängigkeit dieses Beispiels eindeutig. SDK-Änderungsprotokoll
node --version
mkdir jev-photo-check
cd jev-photo-check
npm init -y
npm install @typesafe-ai/[email protected]
- Lege einen nur für die Sitzung gültigen Schlüssel fest. Verwende in Windows PowerShell den ersten Block und in macOS- oder Linux-Bash/Zsh den zweiten. Ersetze den Platzhalter lokal und übernimm keinen echten Schlüssel ins Repository.
$env:TYPESAFE_API_KEY = "your-api-key"
export TYPESAFE_API_KEY="your-api-key"
- Bereite
owned-mug.jpgvor und erstelleinspect-return.mjs. Diese eigene Anpassung verwendet die dokumentierten SDK-Helfer. Der experimentelle Header wird konfiguriert, bevor irgendeine Bildanfrage erfolgt. Die beiden Wahrscheinlichkeitsschwellen unten sind beispielhafte Anwendungsregeln, keine Empfehlungen von TypeSafe. Jedes Ergebnis muss weiterhin von einem Menschen geprüft werden. SDK-Verwendung
import { readFile } from "node:fs/promises";
import { box, image, noul, TypeSafeClient } from "@typesafe-ai/sdk";
if (!process.env.TYPESAFE_API_KEY) {
throw new Error("Set TYPESAFE_API_KEY before choosing to run this example.");
}
const client = new TypeSafeClient({
defaultHeaders: { "TypeSafe-Danger-Zone-Images": "true" },
});
const photo = image(await readFile("owned-mug.jpg"));
const response = await client.systemOne({
model: "jev-1.14.0",
state: { photo },
questions: {
mugVisible: noul("Is a mug clearly visible in `photo`?"),
damageVisible: noul("Is physical damage clearly visible on the mug in `photo`?"),
damageRegion: box("The physically damaged area of the mug in `photo`"),
},
});
const { mugVisible, damageVisible, damageRegion } = response.answers;
const edges = damageRegion.box;
const coordinates = [edges.left, edges.top, edges.right, edges.bottom];
const validBox = coordinates.every(
(value) => Number.isFinite(value) && value >= 0 && value <= 1,
) && edges.left < edges.right && edges.top < edges.bottom;
const presencePasses = [mugVisible.noul, damageVisible.noul].every(
(value) => Number.isFinite(value) && value >= 0.95 && value <= 1,
);
console.log({
model: response.model,
usage: response.usage,
humanReviewRequired: true,
suggestedBox: presencePasses && validBox ? edges : null,
});
- Führe es erst aus, wenn du bereit bist, das Bild zu senden und Nutzungskosten zu verursachen. Unter allen drei Betriebssystemen lautet der Befehl
node inspect-return.mjs. Eine Ausnahme odersuggestedBox: nullsollte das Originalfoto für die Prüfung verfügbar lassen, nicht automatisch wiederholte Einsendungen auslösen.
Die Fragen werden zwar gemeinsam in einer Anfrage gestellt, aber der Rahmen wird ignoriert, sofern das Anwendungstor nicht passiert wird. Die Berechnung eines ungenutzten Rahmens spart dadurch keine Kosten. In einem späteren Entwurf kann die Lokalisierung als zweite Anfrage erst nach den Präsenzprüfungen erfolgen. Das bedeutet einen zusätzlichen Roundtrip, vermeidet aber unnötige Lokalisierungsaufrufe.
Ein niedriger Tokenpreis ist kein Preis pro Foto
Der veröffentlichte Tarif für beide Versionen beträgt 0,042 US-Dollar pro Million Eingabetokens; Ausgabetokens sind kostenlos. Das heißt: 10 Millionen abgerechnete Eingabetokens kosten zum angegebenen Tarif 0,42 US-Dollar. Es heißt nicht, dass zehn Millionen Bilder so viel kosten. Veröffentlichte Preise
Bilder werden als Eingabetokens zum Texttarif berechnet, ohne separate Bildgebühr. TypeSafe hat in der Dokumentation noch keine Formel zur Schätzung von Bildtokens veröffentlicht. Verwende zum Budgetieren einer genehmigten Auswertung usage.input_tokens aus der Antwort, statt Kosten pro Foto zu erfinden. Abrechnung von Bildern
Berücksichtige im Budget fehlgeschlagene Versuche, Wiederholungen, Vorverarbeitung, Speicherung und Zeit der Reviewer. Halte Kosten- und Qualitätsmessungen zusammen: Ein Bruchteil eines Cents Ersparnis ist nutzlos, wenn ein zu enger Zuschnitt jeden Prüfer zwingt, das Original erneut zu öffnen. Vergleiche die vollständige Prüfaufgabe mit einem einfachen manuellen Ausgangsverfahren.
Plane für Unsicherheit, Datenschutz und einen stark ausgelasteten Dienst
Ein Noul gibt eine Wahrscheinlichkeit ohne separates Feld confidence zurück. Choice und Score enthalten Verteilungen sowie daraus abgeleitete Konfidenzwerte. Diese Werte beschreiben die Unsicherheit des Modells; sie sind kein pauschales Richtigkeitszertifikat. Dokumentation zu Konfidenz
Validiere den Prüfschritt im Tassenablauf anhand zurückgehaltener Fotos mit abgestimmten Labels. Gruppiere ähnliche Ausgaben und vergleiche sie mit der beobachteten Korrektheit, um die Kalibrierung für deine Aufgabe zu prüfen. Miss übersehene Schäden getrennt von Fehlalarmen, und unterscheide einen falsch platzierten Rahmen von einer falschen Rückerstattungsentscheidung. Überprüfe die Schwellenwerte erneut, wenn du Modell, Beleuchtung, Produktkategorie oder Aufnahmeverfahren änderst.
Behandle nicht jedes Foto, das die Prüfung nicht besteht, als Beleg gegen einen Kunden. Das Bild kann unzureichend sein, weil die Kamera schlecht ist, der Gegenstand reflektiert oder der Defekt einen anderen Blickwinkel erfordert. Ein brauchbarer Prüfstatus bietet die Möglichkeit für ein weiteres Foto oder eine manuelle Begutachtung, ohne dass die Unsicherheit des Modells zum Verschulden des Kunden wird.
TypeSafe erklärt, dass Kundenanfragen und -antworten nicht zum Trainieren von Jev verwendet werden. Das Hilfezentrum führt außerdem aus, dass die Verarbeitung Dienstbereitstellung, Abrechnung, Missbrauchsprävention und Telemetrie umfassen kann; die Aufbewahrung hängt von Datenart, Vereinbarungen und gegebenenfalls einer Vereinbarung zur Null-Daten-Aufbewahrung ab. Keine Trainingsnutzung bedeutet nicht keine Speicherung. Richtlinie zum Umgang mit Daten
Die öffentliche Statusseite des Dienstes nennt die US-Region und die Regionen us-east-1, us-east-2 und us-west-2. Teams mit regionalen Anforderungen an die Datenresidenz sollten den Verarbeitungsstandort klären, bevor sie Kundenfotos hochladen. Der Zugang zu einer Konsole ist keine Vereinbarung zur Datenresidenz.
Begrenze die Daten vor dem Upload auf das Nötigste. Schneide ein Adressetikett in einer vorbereiteten Kopie weg, wenn es nicht gebraucht wird, beschränke den Zugriff auf Originale und schreibe weder Bilder noch Geheimnisse in Routineprotokolle. Lege die Aufbewahrung deiner eigenen Prüfdatensätze unabhängig von den Richtlinien des Anbieters fest.
Organisationslimits gelten für Anfragen und Tokens pro Sekunde. Die API dokumentiert 429 für Ratenbegrenzung und 529 für Überlastung; fehlerhafte oder zu große Eingaben müssen korrigiert werden und sollten nicht unverändert erneut gesendet werden. Ratenbegrenzungen, API-Fehler
Die Wiederholungsrichtlinie des JavaScript-SDK sieht standardmäßig zwei Wiederholungen vor und berücksichtigt unterstützte Verzögerungs-Header. Ergänze keine unbegrenzte äußere Wiederholungsschleife. Setze ein Zeitbudget, erhalte einen aussagekräftigen Fehlerstatus und halte jede spätere Geschäftsaktion getrennt, damit eine wiederholte Inferenz keine doppelten Rückerstattungen auslöst. Wiederholungsrichtlinie
Diese Fragen solltest du vor deinem ersten Foto-Workflow beantworten
Bearbeitet oder erzeugt Jev das Rücksendefoto?
Nein. Das Bild dient als Beleg für eine Bewertung oder einen vorgeschlagenen Bereich. Deine Anwendung zeichnet mit gewöhnlichem Bildverarbeitungscode eine Einblendung oder erstellt einen Ausschnitt. Bewahre die unveränderte Quelle separat auf; ein brauchbares Rechteck ersetzt den Originalbeleg nicht.
Warum ist im Beispiel Version 1.14 festgelegt und nicht „latest“?
Die veröffentlichte Alias-Tabelle ordnet jev-latest derzeit Version 1.13 zu, während Box Version 1.14 erfordert. Die Festlegung auf jev-1.14.0 macht diese Abhängigkeit ausdrücklich. Prüfe vor einem Versionswechsel die Release-Hinweise und deinen Testsatz, statt anzunehmen, ein Aliaswechsel erhalte das Verhalten.
Kann eine hohe Schadenswahrscheinlichkeit eine Rückerstattung auslösen?
Nicht sicher allein auf Basis dieses Belegs. Die Wahrscheinlichkeit bezieht sich auf die Frage zum eingereichten Bild. Sie authentifiziert weder die Bestellung noch stellt sie Verantwortung fest oder wendet deine Rückerstattungsrichtlinien an. Beginne mit Unterstützung bei der Prüfung, validiere repräsentative Beispiele und behalte für folgenreiche Aktionen eine menschliche Entscheidung bei.
Bedeutet kostenlose Ausgabe, dass eine Bildanfrage nichts kostet?
Nein. Eingabetokens einschließlich Bildtokens werden abgerechnet. Der veröffentlichte Tarif ist kein Preis pro Foto, weil die Formel zur Schätzung von Bildtokens nicht dokumentiert ist. Prüfe bei einem genehmigten Pilotversuch die gemeldete Nutzung und beziehe Wiederholungen sowie Prüfzeit in die Gesamtkosten ein.
Kann ich direkt ein Produktvideo oder PDF senden?
Nicht über die dokumentierte Schnittstelle für Standbilder. Deine Anwendung muss zuerst geeignete Einzelbilder, Text oder gerenderte Seiten extrahieren und dafür die erforderliche Verarbeitungserlaubnis haben. Bei einem extrahierten Einzelbild gehen zeitliche und Audioinformationen verloren. Stelle daher nur Fragen, die sich mit den bereitgestellten Belegen beantworten lassen.
Fazit: Lenke die Aufmerksamkeit, bevor du Entscheidungsbefugnis delegierst
Jevs Bildvorschau macht einen praktischen Vorschlag: Visuelle Belege werden in kleine Antworten verwandelt, die Software prüfen kann. Ein Rücksendewerkzeug für Tassen kann diesen Vorschlag testen, indem es Vorhandensein, Schaden, Position und Prüfung voneinander trennt. Das wertvollste erste Ergebnis ist keine autonome Rückerstattung, sondern eine besser belegte Entscheidung, die ein Prüfer mit weniger Suchaufwand treffen kann.
Daran solltest du den Nutzen messen: Hilft der vorgeschlagene Bereich einer Person, den ursprünglichen Beleg zu verstehen, auch wenn das Modell falsch liegt?
Quellen und Umfang
Primärquellen, geprüft am 18. Oktober 2026: TypeSafes Ankündigung vom 14. Oktober, Modelle und Preise, Bildgrenzen und Abrechnung, Box-Vertrag, JavaScript-Beispiele und SDK-Versionshinweise. Weitere Quellen zu Richtlinien und Zuverlässigkeit sind neben den jeweiligen Aussagen verlinkt. Der durchgearbeitete Ablauf und die Diagramme dienen der Erläuterung; sie sind kein praktischer Benchmark. Für diesen Artikel wurde kein kostenpflichtiger Modellaufruf durchgeführt. Die Diagramme sind Originalgrafiken, keine kopierten Medien des Anbieters.
Bewahre die Quelle neben dem Schluss auf
Für deine eigene Modellrecherche solltest du Originalquellen von den daraus gezogenen Schlussfolgerungen getrennt aufbewahren. Erstelle ein Telli.sh-Konto, um Recherchematerial und abgeleitete Notizen samt unverändertem Quellenkontext zu organisieren.