Muse Spark 1.2 ist eine auf Programmierung ausgerichtete Aktualisierung von Metas Muse Spark 1.1 mit Schwerpunkt auf multimodalem Verständnis und visuellem Reasoning. Die Demonstrationen des Herstellers verbinden Bilder und Video mit digitalen Artefakten wie Webseiten und Spielen; die Modelltabelle nennt einen Kontext von 1.048.576 Token und Textausgabe. Dieser Eintrag betrifft Standard 1.2, getrennt von Contributor 1.2 und dem späteren 1.3.
Visuell gestützte Programmierung
Die Veröffentlichung beschreibt die Übertragung von visuellem Layout, Hierarchie und Stil in funktionierenden Code und die anschließende Prüfung des resultierenden Artefakts mit Werkzeugen. Stellen Sie für eine nützliche Aufgabe das Bild oder den Clip zusammen mit dem zu implementierenden Verhalten bereit. Ein Screenshot kann das Erscheinungsbild zeigen, Interaktionen aber offenlassen; benennen Sie daher die Bedienelemente, Zustände und erwarteten Reaktionen auf Nutzeraktionen, die das Ergebnis enthalten soll.
Fordern Sie sichtbare Struktur, vorgeschlagene Implementierung und Annahmen getrennt an. Eine Seitenrekonstruktion kann beispielsweise die benannten Abschnitte und visuellen Beziehungen der Referenz verlangen und danach den Code für eine definierte Interaktion anfordern. Rendern und Ausprobieren dieses Codes benötigen die angebundene Umgebung; der resultierende Screenshot oder die Ausführungsrückmeldung können als Eingabe für die nächste Korrektur dienen.
Der Hersteller nennt über die Codegenerierung hinaus Diagrammverständnis und visuelles Reasoning. Bewahren Sie Achsen, Einheiten und Beschriftungen eines Diagramms und fordern Sie die jede Schlussfolgerung stützende Beobachtung an. Benennen Sie bei einer schematischen Darstellung den zu erklärenden Zusammenhang und die zu erhaltenden Quellenkennzeichnungen. Unterscheiden Sie bei einem Dokumentbild die Transkription des sichtbaren Wortlauts von einer Zusammenfassung oder Interpretation.
Räumliche und audiovisuelle Abläufe
Die Ankündigung von 1.2 behandelt auch eine spezialisierte Robotikvariante und ein zweistufiges Planungs-/Aktionssystem. Das sind eigenständige experimentelle Komponenten: Ein übergeordnetes Modell beurteilt Szene und Teilaufgaben, während eine separate Vision-Language-Action-Policy die untergeordneten Aktionen ausführt. Das Standardmodell mit Textausgabe sollte nicht als Roboteraktor beschrieben werden, nur weil die Familienveröffentlichung diese Demonstration enthält.
Für die Standardversion dokumentiert die Modelltabelle Text, Bilder, Video, Audio und PDFs als Eingaben. Eine audiovisuelle Aufgabe kann nach dem für eine Frage relevanten Ereignis oder der gesprochenen Bedingung fragen und eine geordnete Darstellung des belegenden Materials liefern. Benennen Sie den relevanten Ausschnitt und die Antwortform, statt eine ungerichtete Zusammenfassung jeder Modalität zu verlangen.
Die Herstellerbeispiele verbinden Videoverständnis, dichte Bildbeschreibungen und werkzeuggestützte Untersuchung. Ein praktischer Ablauf kann eine Demonstration mit ihrem schriftlichen Verfahren vergleichen, sichtbare Übereinstimmungen und Unterschiede anfordern und anschließend ein Textergebnis für einen späteren Anwendungsschritt vorbereiten. Erzeugter Fließtext, Code und strukturierte Befunde sind die dokumentierte Ausgabe; Bild- oder Spracherzeugung gehört zu gesondert benannten Komponenten.
Reasoning-Einstellungen und Kontext
Muse Spark betreibt vor der sichtbaren Textausgabe internes Reasoning. Die für 1.2 geltenden dokumentierten Aufwandsstufen sind minimal, low, medium, high und xhigh. Max gehört zu Standard 1.3, und none ist kein unterstützter Weg zum Abschalten von Reasoning. Wird kein Aufwand angegeben, verwendet das Modell eine selbst bestimmte Stufe.
Der Kontext von 1.048.576 Token kann zusammengehöriges Ausgangsmaterial und Gespräche bewahren; Ziel und fertiges Artefakt müssen dennoch definiert werden. Benennen Sie bei einer langen Dokumentaufgabe die Frage, kennzeichnen Sie jede Quelle und behalten Sie ihre Position neben extrahierten Informationen bei. Reasoning-Token und sichtbare Antworttoken teilen sich das Ausgabebudget; reservieren Sie daher ausreichend Platz für die tatsächlich benötigte Erklärung oder den Code.
Rohes internes Reasoning wird nicht als gewöhnlicher Text offengelegt. Auch die Chatschnittstelle des Herstellers trägt für externe Aufrufer keine lesbare private Spur über Gesprächsrunden hinweg weiter; bewahren Sie die sichtbaren Nachrichten, Quellen und zurückgegebenen Werkzeugergebnisse, die eine Folgeanfrage benötigt. Log-Wahrscheinlichkeiten werden nicht unterstützt; das Modell stellt diese Funktion daher nicht als Vertrauensmaß für seine Schlussfolgerungen bereit.
Werkzeuge und strukturierte Artefakte
Die Anwendung beschreibt Entwicklerfunktionen, das Modell erzeugt vorgeschlagene Aufrufe und Argumente, und die Anwendung führt sie aus und gibt das Ergebnis für jeden Aufruf zurück. Das Modell kann dann die tatsächlichen Rückmeldungen prüfen und den nächsten Schritt wählen. Der Schwerpunkt der Veröffentlichung auf der Untersuchung visueller Eingaben und erzeugter Artefakte setzt voraus, dass diese Werkzeuge Teil der Umgebung sind.
Strukturierte Ausgabe kann den Text auf ein definiertes JSON-Schema beschränken. Ein Datensatz zur visuellen Extraktion kann Quellbild, Gegenstand oder Beschriftung, beobachteten Wert und Interpretation enthalten. Eine Codebegutachtung kann betroffenes Symbol, Abweichung und vorgeschlagene Änderung benennen. Der strikte Modus des Herstellers verlangt ein einfaches Objekt als Wurzel, alle angeführten Eigenschaften als Pflichtfelder und den Ausschluss zusätzlicher Eigenschaften; rekursive Schemata werden zurückgewiesen.
Definieren Sie die Korrektheit des Artefakts praktisch: welche Quelldetails es bewahren muss, wie sich eine Interaktion verhalten soll und welche zurückgegebenen Rückmeldungen dieses Verhalten belegen würden. Die gelesenen Quellen nennen über den Modellkontext hinaus keine unabhängigen maximalen Eingabe- oder Ausgabetokenkapazitäten. Bewahren Sie die Ausgabe Standard 1.2 und den Unterschied zwischen einem vorgeschlagenen Textartefakt und dem zur Prüfung verwendeten Ausführungs- oder Render-Ergebnis.
", "aboutText": "Muse Spark 1.2 ist eine auf Programmierung ausgerichtete Aktualisierung von Metas Muse Spark 1.1 mit Schwerpunkt auf multimodalem Verständnis und visuellem Reasoning. Die Demonstrationen des Herstellers verbinden Bilder und Video mit digitalen Artefakten wie Webseiten und Spielen; die Modelltabelle nennt einen Kontext von 1.048.576 Token und Textausgabe. Dieser Eintrag betrifft Standard 1.2, getrennt von Contributor 1.2 und dem späteren 1.3.\n\nVisuell gestützte Programmierung\n\nDie Veröffentlichung beschreibt die Übertragung von visuellem Layout, Hierarchie und Stil in funktionierenden Code und die anschließende Prüfung des resultierenden Artefakts mit Werkzeugen. Stellen Sie für eine nützliche Aufgabe das Bild oder den Clip zusammen mit dem zu implementierenden Verhalten bereit. Ein Screenshot kann das Erscheinungsbild zeigen, Interaktionen aber offenlassen; benennen Sie daher die Bedienelemente, Zustände und erwarteten Reaktionen auf Nutzeraktionen, die das Ergebnis enthalten soll.\n\nFordern Sie sichtbare Struktur, vorgeschlagene Implementierung und Annahmen getrennt an. Eine Seitenrekonstruktion kann beispielsweise die benannten Abschnitte und visuellen Beziehungen der Referenz verlangen und danach den Code für eine definierte Interaktion anfordern. Rendern und Ausprobieren dieses Codes benötigen die angebundene Umgebung; der resultierende Screenshot oder die Ausführungsrückmeldung können als Eingabe für die nächste Korrektur dienen.\n\nDer Hersteller nennt über die Codegenerierung hinaus Diagrammverständnis und visuelles Reasoning. Bewahren Sie Achsen, Einheiten und Beschriftungen eines Diagramms und fordern Sie die jede Schlussfolgerung stützende Beobachtung an. Benennen Sie bei einer schematischen Darstellung den zu erklärenden Zusammenhang und die zu erhaltenden Quellenkennzeichnungen. Unterscheiden Sie bei einem Dokumentbild die Transkription des sichtbaren Wortlauts von einer Zusammenfassung oder Interpretation.\n\nRäumliche und audiovisuelle Abläufe\n\nDie Ankündigung von 1.2 behandelt auch eine spezialisierte Robotikvariante und ein zweistufiges Planungs-/Aktionssystem. Das sind eigenständige experimentelle Komponenten: Ein übergeordnetes Modell beurteilt Szene und Teilaufgaben, während eine separate Vision-Language-Action-Policy die untergeordneten Aktionen ausführt. Das Standardmodell mit Textausgabe sollte nicht als Roboteraktor beschrieben werden, nur weil die Familienveröffentlichung diese Demonstration enthält.\n\nFür die Standardversion dokumentiert die Modelltabelle Text, Bilder, Video, Audio und PDFs als Eingaben. Eine audiovisuelle Aufgabe kann nach dem für eine Frage relevanten Ereignis oder der gesprochenen Bedingung fragen und eine geordnete Darstellung des belegenden Materials liefern. Benennen Sie den relevanten Ausschnitt und die Antwortform, statt eine ungerichtete Zusammenfassung jeder Modalität zu verlangen.\n\nDie Herstellerbeispiele verbinden Videoverständnis, dichte Bildbeschreibungen und werkzeuggestützte Untersuchung. Ein praktischer Ablauf kann eine Demonstration mit ihrem schriftlichen Verfahren vergleichen, sichtbare Übereinstimmungen und Unterschiede anfordern und anschließend ein Textergebnis für einen späteren Anwendungsschritt vorbereiten. Erzeugter Fließtext, Code und strukturierte Befunde sind die dokumentierte Ausgabe; Bild- oder Spracherzeugung gehört zu gesondert benannten Komponenten.\n\nReasoning-Einstellungen und Kontext\n\nMuse Spark betreibt vor der sichtbaren Textausgabe internes Reasoning. Die für 1.2 geltenden dokumentierten Aufwandsstufen sind minimal, low, medium, high und xhigh. Max gehört zu Standard 1.3, und none ist kein unterstützter Weg zum Abschalten von Reasoning. Wird kein Aufwand angegeben, verwendet das Modell eine selbst bestimmte Stufe.\n\nDer Kontext von 1.048.576 Token kann zusammengehöriges Ausgangsmaterial und Gespräche bewahren; Ziel und fertiges Artefakt müssen dennoch definiert werden. Benennen Sie bei einer langen Dokumentaufgabe die Frage, kennzeichnen Sie jede Quelle und behalten Sie ihre Position neben extrahierten Informationen bei. Reasoning-Token und sichtbare Antworttoken teilen sich das Ausgabebudget; reservieren Sie daher ausreichend Platz für die tatsächlich benötigte Erklärung oder den Code.\n\nRohes internes Reasoning wird nicht als gewöhnlicher Text offengelegt. Auch die Chatschnittstelle des Herstellers trägt für externe Aufrufer keine lesbare private Spur über Gesprächsrunden hinweg weiter; bewahren Sie die sichtbaren Nachrichten, Quellen und zurückgegebenen Werkzeugergebnisse, die eine Folgeanfrage benötigt. Log-Wahrscheinlichkeiten werden nicht unterstützt; das Modell stellt diese Funktion daher nicht als Vertrauensmaß für seine Schlussfolgerungen bereit.\n\nWerkzeuge und strukturierte Artefakte\n\nDie Anwendung beschreibt Entwicklerfunktionen, das Modell erzeugt vorgeschlagene Aufrufe und Argumente, und die Anwendung führt sie aus und gibt das Ergebnis für jeden Aufruf zurück. Das Modell kann dann die tatsächlichen Rückmeldungen prüfen und den nächsten Schritt wählen. Der Schwerpunkt der Veröffentlichung auf der Untersuchung visueller Eingaben und erzeugter Artefakte setzt voraus, dass diese Werkzeuge Teil der Umgebung sind.\n\nStrukturierte Ausgabe kann den Text auf ein definiertes JSON-Schema beschränken. Ein Datensatz zur visuellen Extraktion kann Quellbild, Gegenstand oder Beschriftung, beobachteten Wert und Interpretation enthalten. Eine Codebegutachtung kann betroffenes Symbol, Abweichung und vorgeschlagene Änderung benennen. Der strikte Modus des Herstellers verlangt ein einfaches Objekt als Wurzel, alle angeführten Eigenschaften als Pflichtfelder und den Ausschluss zusätzlicher Eigenschaften; rekursive Schemata werden zurückgewiesen.\n\nDefinieren Sie die Korrektheit des Artefakts praktisch: welche Quelldetails es bewahren muss, wie sich eine Interaktion verhalten soll und welche zurückgegebenen Rückmeldungen dieses Verhalten belegen würden. Die gelesenen Quellen nennen über den Modellkontext hinaus keine unabhängigen maximalen Eingabe- oder Ausgabetokenkapazitäten. Bewahren Sie die Ausgabe Standard 1.2 und den Unterschied zwischen einem vorgeschlagenen Textartefakt und dem zur Prüfung verwendeten Ausführungs- oder Render-Ergebnis.", "editorialOverlay": { "copy_fields": { "practical_html": "Technisches Beispiel auf Englisch
Implement a specified responsive layout\n\nDraft semantic HTML and CSS for a product comparison section with a title, introduction and three feature columns. At narrow widths, stack the columns in the same reading order. Each column needs a heading and three bullet points. Use the placeholder copy supplied in your code and explain the breakpoint choice; return source only, without claiming a rendered result.A bounded HTML/CSS section and a short explanation of stacking behavior and reading order.At the proposed narrow breakpoint, the DOM order and visual order match and no horizontal overflow is introduced.meta/muse-spark-1.2Muse Spark 1.2 ist Metas multimodales Reasoning-Modell mit Schwerpunkt auf visuell gestützter Programmierung, Diagrammen und audiovisuellem Verständnis. Es kann bereitgestellte Bilder oder Videos über angebundene Werkzeuge in vorgeschlagenen Web- und Spielecode überführen, mit Textausgabe und einem Herstellerkontext von 1.048.576 Token.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Muse Spark 1.2 ist eine auf Programmierung ausgerichtete Aktualisierung von Metas Muse Spark 1.1 mit Schwerpunkt auf multimodalem Verständnis und visuellem Reasoning. Die Demonstrationen des Herstellers verbinden Bilder und Video mit digitalen Artefakten wie Webseiten und Spielen; die Modelltabelle nennt einen Kontext von 1.048.576 Token und Textausgabe. Dieser Eintrag betrifft Standard 1.2, getrennt von Contributor 1.2 und dem späteren 1.3.
Visuell gestützte Programmierung
Die Veröffentlichung beschreibt die Übertragung von visuellem Layout, Hierarchie und Stil in funktionierenden Code und die anschließende Prüfung des resultierenden Artefakts mit Werkzeugen. Stellen Sie für eine nützliche Aufgabe das Bild oder den Clip zusammen mit dem zu implementierenden Verhalten bereit. Ein Screenshot kann das Erscheinungsbild zeigen, Interaktionen aber offenlassen; benennen Sie daher die Bedienelemente, Zustände und erwarteten Reaktionen auf Nutzeraktionen, die das Ergebnis enthalten soll.
Fordern Sie sichtbare Struktur, vorgeschlagene Implementierung und Annahmen getrennt an. Eine Seitenrekonstruktion kann beispielsweise die benannten Abschnitte und visuellen Beziehungen der Referenz verlangen und danach den Code für eine definierte Interaktion anfordern. Rendern und Ausprobieren dieses Codes benötigen die angebundene Umgebung; der resultierende Screenshot oder die Ausführungsrückmeldung können als Eingabe für die nächste Korrektur dienen.
Der Hersteller nennt über die Codegenerierung hinaus Diagrammverständnis und visuelles Reasoning. Bewahren Sie Achsen, Einheiten und Beschriftungen eines Diagramms und fordern Sie die jede Schlussfolgerung stützende Beobachtung an. Benennen Sie bei einer schematischen Darstellung den zu erklärenden Zusammenhang und die zu erhaltenden Quellenkennzeichnungen. Unterscheiden Sie bei einem Dokumentbild die Transkription des sichtbaren Wortlauts von einer Zusammenfassung oder Interpretation.
Räumliche und audiovisuelle Abläufe
Die Ankündigung von 1.2 behandelt auch eine spezialisierte Robotikvariante und ein zweistufiges Planungs-/Aktionssystem. Das sind eigenständige experimentelle Komponenten: Ein übergeordnetes Modell beurteilt Szene und Teilaufgaben, während eine separate Vision-Language-Action-Policy die untergeordneten Aktionen ausführt. Das Standardmodell mit Textausgabe sollte nicht als Roboteraktor beschrieben werden, nur weil die Familienveröffentlichung diese Demonstration enthält.
Für die Standardversion dokumentiert die Modelltabelle Text, Bilder, Video, Audio und PDFs als Eingaben. Eine audiovisuelle Aufgabe kann nach dem für eine Frage relevanten Ereignis oder der gesprochenen Bedingung fragen und eine geordnete Darstellung des belegenden Materials liefern. Benennen Sie den relevanten Ausschnitt und die Antwortform, statt eine ungerichtete Zusammenfassung jeder Modalität zu verlangen.
Die Herstellerbeispiele verbinden Videoverständnis, dichte Bildbeschreibungen und werkzeuggestützte Untersuchung. Ein praktischer Ablauf kann eine Demonstration mit ihrem schriftlichen Verfahren vergleichen, sichtbare Übereinstimmungen und Unterschiede anfordern und anschließend ein Textergebnis für einen späteren Anwendungsschritt vorbereiten. Erzeugter Fließtext, Code und strukturierte Befunde sind die dokumentierte Ausgabe; Bild- oder Spracherzeugung gehört zu gesondert benannten Komponenten.
Reasoning-Einstellungen und Kontext
Muse Spark betreibt vor der sichtbaren Textausgabe internes Reasoning. Die für 1.2 geltenden dokumentierten Aufwandsstufen sind minimal, low, medium, high und xhigh. Max gehört zu Standard 1.3, und none ist kein unterstützter Weg zum Abschalten von Reasoning. Wird kein Aufwand angegeben, verwendet das Modell eine selbst bestimmte Stufe.
Der Kontext von 1.048.576 Token kann zusammengehöriges Ausgangsmaterial und Gespräche bewahren; Ziel und fertiges Artefakt müssen dennoch definiert werden. Benennen Sie bei einer langen Dokumentaufgabe die Frage, kennzeichnen Sie jede Quelle und behalten Sie ihre Position neben extrahierten Informationen bei. Reasoning-Token und sichtbare Antworttoken teilen sich das Ausgabebudget; reservieren Sie daher ausreichend Platz für die tatsächlich benötigte Erklärung oder den Code.
Rohes internes Reasoning wird nicht als gewöhnlicher Text offengelegt. Auch die Chatschnittstelle des Herstellers trägt für externe Aufrufer keine lesbare private Spur über Gesprächsrunden hinweg weiter; bewahren Sie die sichtbaren Nachrichten, Quellen und zurückgegebenen Werkzeugergebnisse, die eine Folgeanfrage benötigt. Log-Wahrscheinlichkeiten werden nicht unterstützt; das Modell stellt diese Funktion daher nicht als Vertrauensmaß für seine Schlussfolgerungen bereit.
Werkzeuge und strukturierte Artefakte
Die Anwendung beschreibt Entwicklerfunktionen, das Modell erzeugt vorgeschlagene Aufrufe und Argumente, und die Anwendung führt sie aus und gibt das Ergebnis für jeden Aufruf zurück. Das Modell kann dann die tatsächlichen Rückmeldungen prüfen und den nächsten Schritt wählen. Der Schwerpunkt der Veröffentlichung auf der Untersuchung visueller Eingaben und erzeugter Artefakte setzt voraus, dass diese Werkzeuge Teil der Umgebung sind.
Strukturierte Ausgabe kann den Text auf ein definiertes JSON-Schema beschränken. Ein Datensatz zur visuellen Extraktion kann Quellbild, Gegenstand oder Beschriftung, beobachteten Wert und Interpretation enthalten. Eine Codebegutachtung kann betroffenes Symbol, Abweichung und vorgeschlagene Änderung benennen. Der strikte Modus des Herstellers verlangt ein einfaches Objekt als Wurzel, alle angeführten Eigenschaften als Pflichtfelder und den Ausschluss zusätzlicher Eigenschaften; rekursive Schemata werden zurückgewiesen.
Definieren Sie die Korrektheit des Artefakts praktisch: welche Quelldetails es bewahren muss, wie sich eine Interaktion verhalten soll und welche zurückgegebenen Rückmeldungen dieses Verhalten belegen würden. Die gelesenen Quellen nennen über den Modellkontext hinaus keine unabhängigen maximalen Eingabe- oder Ausgabetokenkapazitäten. Bewahren Sie die Ausgabe Standard 1.2 und den Unterschied zwischen einem vorgeschlagenen Textartefakt und dem zur Prüfung verwendeten Ausführungs- oder Render-Ergebnis.
POST /v1/chat/completionstexttext| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits meta/muse-spark-1.2 | Standard— |
Feldmessages | Typmessage[] | AnforderungErforderlich | Werte und Limits Mindestanzahl Elemente: 1 | Standard— |
Feldmessages[].role | Typstring | AnforderungErforderlich | Werte und Limits Beispiele: system, user, assistant, tool, function Bedingungen: Diese Rollen sind in den Kompatibilitätstypen des Quellcodes ausdrücklich dargestellt; der genaue Rollenumfang bleibt modellspezifisch. Modellabhängig | Standard— |
Feldmessages[].content | Typstring|content_part[]|null | AnforderungOptional | Werte und Limits | Standard— |
Feldmessages[].tool_calls | Typtool_call[] | AnforderungOptional | Werte und Limits | Standard— |
Feldmessages[].tool_call_id | Typstring | AnforderungOptional | Werte und Limits Gilt, wenn: role=tool; die tatsächlich zurückgegebene ID verwenden | Standard— |
Feldmessages[].name | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldmessages[].reasoning_content | Typstring | AnforderungOptional | Werte und Limits Gilt, wenn: Tatsächlich zurückgegebene Reasoning-Daten erneut übermitteln, sofern dieses Modell sie verwendet | Standard— |
Feldmessages[].reasoning_details | Typobject|array | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldmax_tokens | Typinteger | AnforderungOptional | Werte und Limits Minimum: 1 Modellabhängig | Standard— |
Feldmax_completion_tokens | Typinteger | AnforderungOptional | Werte und Limits Minimum: 1 Modellabhängig | Standard— |
Feldstream | Typboolean | AnforderungOptional | Werte und Limits | Standardfalse |
Feldstream_options.include_usage | Typboolean | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtemperature | Typnumber | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtop_p | Typnumber | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldstop | Typstring|string[] | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtools | Typfunction_tool[] | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldtools[].type | Typstring | AnforderungOptional | Werte und Limits function Modellabhängig | Standard— |
Feldtools[].function.name | Typstring | AnforderungErforderlich | Werte und Limits Gilt, wenn: Funktionswerkzeug bereitgestellt | Standard— |
Feldtools[].function.description | Typstring | AnforderungOptional | Werte und Limits | Standard— |
Feldtools[].function.parameters | TypJSON_schema | AnforderungOptional | Werte und Limits | Standard— |
Feldtool_choice | Typstring|object | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldparallel_tool_calls | Typboolean | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldresponse_format | Typobject | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldreasoning_effort | Typstring | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldreasoning | Typobject | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldservice_tier | Typstring | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldinstructions | Typstring | AnforderungOptional | Werte und Limits Kompatibilitätsfeld | Standard— |
Feldfunctions | Typfunction[] | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldfunction_call | Typstring|object | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldprompt_cache_options | Typobject | AnforderungOptional | Werte und Limits Modellabhängig | Standard— |
Feldmodalities | Typstring[] | AnforderungOptional | Werte und Limits text | Standard— |
Feldprovider | Typobject | AnforderungOptional | Werte und Limits Bedingungen: provider.options wird auf dieser Ultra-Textroute abgelehnt | Standard— |
Feldcache_control.ttl | Typstring | AnforderungOptional | Werte und Limits Bedingungen: 1h wird in den tatsächlichen Prompt-Cache-Feldern abgelehnt | Standard— |
Text · UTF8-Text
messages[].content
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, messages |
Parametermaterial_types | Vertragtext |
Parametermessages | VertragNachrichtenarray mit role/content-Struktur |
Parameterfile_material | VertragTatsächliches UTF-8-Dokument als wörtlicher Text eingefügt; keine Datei-ID abgeleitet |
Parameteroptional_controls | Vertragstream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametercontrol_scope | VertragModellspezifisch; benutzerseitige Funktionswerkzeuge unterscheiden sich von gehosteten Werkzeugen |
Parameteroutput_modalities | Vertragtext |
Parameterhosted_operations | Vertragfalse |
Parametermultimodal_input_binding | Vertragnull |
Lebenszyklus: synchronous_or_streamed
Die genaue Modell-ID zusammen mit messages senden.
Die Kontextlänge ist keine Ausgabeobergrenze.
Eine Textdatei kann wörtlichen Text liefern; Bild-, Audio- und Dateiobjekteingaben benötigen eine exakte Zuordnung.
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.0025 / 1K Tokens Ausgabe · Ausgabetoken $0.0085 / 1K Tokens Eingabe · Cache lesen $0.0003 / 1K Tokens Eingabe · In Cache schreiben — / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.0025 / 1K Tokens Ausgabe · Ausgabetoken $0.0085 / 1K Tokens Eingabe · Cache lesen $0.0003 / 1K Tokens Eingabe · In Cache schreiben — / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "meta/muse-spark-1.2", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='meta/muse-spark-1.2',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='meta/muse-spark-1.2',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson oder SSE
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Alle Antwortvarianten mit ihren Inhalten, Werkzeugaufrufen und Reasoning-Daten beibehalten. In SSE die Deltas nach Varianten- und Werkzeugindex zusammensetzen; endgültigen Beendigungsgrund und Verbrauchsdaten beibehalten.
Anfrage- und Antwort-IDs sowie Header beibehalten. Eine allgemeine URL zum Abrufen von Textaufträgen wird nicht angegeben.
| Feld | Typ |
|---|---|
Feldchoices[].index | Typinteger |
Feldchoices[].message.content | Typstring|null |
Feldchoices[].message.tool_calls | Typtool_call[] |
Feldchoices[].message.reasoning_content | Typstring |
Feldchoices[].message.reasoning_details | Typobject|array |
Feldchoices[].finish_reason | Typstring|null |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra meta/muse-spark-1.2
Verwenden Sie die oben angezeigten Methodenpfade.
meta/muse-spark-1.2Muse Spark 1.2 ist Metas multimodales Reasoning-Modell mit Schwerpunkt auf visuell gestützter Programmierung, Diagrammen und audiovisuellem Verständnis. Es kann bereitgestellte Bilder oder Videos über angebundene Werkzeuge in vorgeschlagenen Web- und Spielecode überführen, mit Textausgabe und einem Herstellerkontext von 1.048.576 Token.
Diese Beschreibung erläutert die Fähigkeiten des Modells. Die über Ailoot verfügbaren Eingaben, Ausgaben und Optionen sind unten für die ausgewählte Methode aufgeführt.
Muse Spark 1.2 ist eine auf Programmierung ausgerichtete Aktualisierung von Metas Muse Spark 1.1 mit Schwerpunkt auf multimodalem Verständnis und visuellem Reasoning. Die Demonstrationen des Herstellers verbinden Bilder und Video mit digitalen Artefakten wie Webseiten und Spielen; die Modelltabelle nennt einen Kontext von 1.048.576 Token und Textausgabe. Dieser Eintrag betrifft Standard 1.2, getrennt von Contributor 1.2 und dem späteren 1.3.
Visuell gestützte Programmierung
Die Veröffentlichung beschreibt die Übertragung von visuellem Layout, Hierarchie und Stil in funktionierenden Code und die anschließende Prüfung des resultierenden Artefakts mit Werkzeugen. Stellen Sie für eine nützliche Aufgabe das Bild oder den Clip zusammen mit dem zu implementierenden Verhalten bereit. Ein Screenshot kann das Erscheinungsbild zeigen, Interaktionen aber offenlassen; benennen Sie daher die Bedienelemente, Zustände und erwarteten Reaktionen auf Nutzeraktionen, die das Ergebnis enthalten soll.
Fordern Sie sichtbare Struktur, vorgeschlagene Implementierung und Annahmen getrennt an. Eine Seitenrekonstruktion kann beispielsweise die benannten Abschnitte und visuellen Beziehungen der Referenz verlangen und danach den Code für eine definierte Interaktion anfordern. Rendern und Ausprobieren dieses Codes benötigen die angebundene Umgebung; der resultierende Screenshot oder die Ausführungsrückmeldung können als Eingabe für die nächste Korrektur dienen.
Der Hersteller nennt über die Codegenerierung hinaus Diagrammverständnis und visuelles Reasoning. Bewahren Sie Achsen, Einheiten und Beschriftungen eines Diagramms und fordern Sie die jede Schlussfolgerung stützende Beobachtung an. Benennen Sie bei einer schematischen Darstellung den zu erklärenden Zusammenhang und die zu erhaltenden Quellenkennzeichnungen. Unterscheiden Sie bei einem Dokumentbild die Transkription des sichtbaren Wortlauts von einer Zusammenfassung oder Interpretation.
Räumliche und audiovisuelle Abläufe
Die Ankündigung von 1.2 behandelt auch eine spezialisierte Robotikvariante und ein zweistufiges Planungs-/Aktionssystem. Das sind eigenständige experimentelle Komponenten: Ein übergeordnetes Modell beurteilt Szene und Teilaufgaben, während eine separate Vision-Language-Action-Policy die untergeordneten Aktionen ausführt. Das Standardmodell mit Textausgabe sollte nicht als Roboteraktor beschrieben werden, nur weil die Familienveröffentlichung diese Demonstration enthält.
Für die Standardversion dokumentiert die Modelltabelle Text, Bilder, Video, Audio und PDFs als Eingaben. Eine audiovisuelle Aufgabe kann nach dem für eine Frage relevanten Ereignis oder der gesprochenen Bedingung fragen und eine geordnete Darstellung des belegenden Materials liefern. Benennen Sie den relevanten Ausschnitt und die Antwortform, statt eine ungerichtete Zusammenfassung jeder Modalität zu verlangen.
Die Herstellerbeispiele verbinden Videoverständnis, dichte Bildbeschreibungen und werkzeuggestützte Untersuchung. Ein praktischer Ablauf kann eine Demonstration mit ihrem schriftlichen Verfahren vergleichen, sichtbare Übereinstimmungen und Unterschiede anfordern und anschließend ein Textergebnis für einen späteren Anwendungsschritt vorbereiten. Erzeugter Fließtext, Code und strukturierte Befunde sind die dokumentierte Ausgabe; Bild- oder Spracherzeugung gehört zu gesondert benannten Komponenten.
Reasoning-Einstellungen und Kontext
Muse Spark betreibt vor der sichtbaren Textausgabe internes Reasoning. Die für 1.2 geltenden dokumentierten Aufwandsstufen sind minimal, low, medium, high und xhigh. Max gehört zu Standard 1.3, und none ist kein unterstützter Weg zum Abschalten von Reasoning. Wird kein Aufwand angegeben, verwendet das Modell eine selbst bestimmte Stufe.
Der Kontext von 1.048.576 Token kann zusammengehöriges Ausgangsmaterial und Gespräche bewahren; Ziel und fertiges Artefakt müssen dennoch definiert werden. Benennen Sie bei einer langen Dokumentaufgabe die Frage, kennzeichnen Sie jede Quelle und behalten Sie ihre Position neben extrahierten Informationen bei. Reasoning-Token und sichtbare Antworttoken teilen sich das Ausgabebudget; reservieren Sie daher ausreichend Platz für die tatsächlich benötigte Erklärung oder den Code.
Rohes internes Reasoning wird nicht als gewöhnlicher Text offengelegt. Auch die Chatschnittstelle des Herstellers trägt für externe Aufrufer keine lesbare private Spur über Gesprächsrunden hinweg weiter; bewahren Sie die sichtbaren Nachrichten, Quellen und zurückgegebenen Werkzeugergebnisse, die eine Folgeanfrage benötigt. Log-Wahrscheinlichkeiten werden nicht unterstützt; das Modell stellt diese Funktion daher nicht als Vertrauensmaß für seine Schlussfolgerungen bereit.
Werkzeuge und strukturierte Artefakte
Die Anwendung beschreibt Entwicklerfunktionen, das Modell erzeugt vorgeschlagene Aufrufe und Argumente, und die Anwendung führt sie aus und gibt das Ergebnis für jeden Aufruf zurück. Das Modell kann dann die tatsächlichen Rückmeldungen prüfen und den nächsten Schritt wählen. Der Schwerpunkt der Veröffentlichung auf der Untersuchung visueller Eingaben und erzeugter Artefakte setzt voraus, dass diese Werkzeuge Teil der Umgebung sind.
Strukturierte Ausgabe kann den Text auf ein definiertes JSON-Schema beschränken. Ein Datensatz zur visuellen Extraktion kann Quellbild, Gegenstand oder Beschriftung, beobachteten Wert und Interpretation enthalten. Eine Codebegutachtung kann betroffenes Symbol, Abweichung und vorgeschlagene Änderung benennen. Der strikte Modus des Herstellers verlangt ein einfaches Objekt als Wurzel, alle angeführten Eigenschaften als Pflichtfelder und den Ausschluss zusätzlicher Eigenschaften; rekursive Schemata werden zurückgewiesen.
Definieren Sie die Korrektheit des Artefakts praktisch: welche Quelldetails es bewahren muss, wie sich eine Interaktion verhalten soll und welche zurückgegebenen Rückmeldungen dieses Verhalten belegen würden. Die gelesenen Quellen nennen über den Modellkontext hinaus keine unabhängigen maximalen Eingabe- oder Ausgabetokenkapazitäten. Bewahren Sie die Ausgabe Standard 1.2 und den Unterschied zwischen einem vorgeschlagenen Textartefakt und dem zur Prüfung verwendeten Ausführungs- oder Render-Ergebnis.
POST /v1/messagestextjson, sse| Feld | Typ | Anforderung | Werte und Limits | Standard |
|---|---|---|---|---|
Feldmodel | Typstring | AnforderungErforderlich | Werte und Limits meta/muse-spark-1.2 | Standard— |
Feldmessages | Typmessage[] | AnforderungErforderlich | Werte und Limits | Standard— |
Feldmessages[].role | Typstring | AnforderungErforderlich | Werte und Limits user, assistant | Standard— |
Feldmessages[].content | Typstring | AnforderungErforderlich | Werte und Limits | Standard— |
Feldmax_tokens | Typinteger | AnforderungErforderlich | Werte und Limits | Standard— |
Feldstream | Typboolean | AnforderungOptional | Werte und Limits | Standardfalse |
Text · UTF-8-Text
Zeichenfolge messages[].content
| Parameter | Vertrag |
|---|---|
Parametercontent_type | Vertragapplication/json |
Parameterrequired | Vertragmodel, messages, max_tokens |
Parameteroptional_controls | Vertragstream |
Parametermaterial_types | Vertragtext |
Parametertext_file_material | VertragDas tatsächliche UTF-8-Dokument lesen und seinen Text in die angegebene Zeichenfolge für Eingabe oder Nachrichteninhalt einfügen. |
Lebenszyklus: synchronous_or_streamed
Tarifangaben erweitern die Anfrageoptionen nicht. Unterstützte Parameter stehen bei der ausgewählten Methode.
Ordnen Sie jede Gebühr den angezeigten Bedingungen zu. Verwenden Sie für jede Gruppe alternativer Konfigurationen einen Tarif.
| Konfiguration | Tarifstaffel | Kontexttoken, mehr als | Kontexttoken, bis einschließlich | Gebühr |
|---|---|---|---|---|
| KonfigurationBasistarife für Token | TarifstaffelGrundtarif | Kontexttoken, mehr als— | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.0025 / 1K Tokens Ausgabe · Ausgabetoken $0.0085 / 1K Tokens Eingabe · Cache lesen $0.0003 / 1K Tokens Eingabe · In Cache schreiben — / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
| KonfigurationAnfragelängenstufe 1 | Tarifstaffel— | Kontexttoken, mehr als0 | Kontexttoken, bis einschließlichKeine Obergrenze | Gebühr Eingabe · Eingabetoken $0.0025 / 1K Tokens Ausgabe · Ausgabetoken $0.0085 / 1K Tokens Eingabe · Cache lesen $0.0003 / 1K Tokens Eingabe · In Cache schreiben — / 1K Tokens Eingabe · In Cache schreiben, 1 Stunde — / 1K Tokens |
Ailoot reserviert vor einer Anfrage einen geschätzten Betrag. Nach dem Ergebnis rechnet Ailoot die endgültige Gebühr anhand des gemessenen Verbrauchs ab. Bei Streaming erfolgt die Abrechnung anhand des abschließenden Verbrauchsdatensatzes. So funktionieren Reservierung und Abrechnung →
{\n "model": "meta/muse-spark-1.2",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'meta/muse-spark-1.2', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'meta/muse-spark-1.2', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON oder SSE
Bewahren Sie jede vollständig zurückgegebene Antwort, Datei und jeden Inhaltsteil auf.
Alle Inhaltsblöcke, Thinking-Signaturen und tatsächlichen Werkzeugaufruf-IDs beibehalten. Alle SSE-Blockdeltas zusammensetzen; der erste Textblock ist nicht die vollständige Ausgabe.
Anfrage- und Antwort-IDs sowie Header beibehalten. Eine allgemeine URL zum Abrufen von Textaufträgen wird nicht angegeben.
| Feld | Typ |
|---|---|
Feldid | Typstring |
Feldmodel | Typstring |
Feldcontent[] | Typtext|thinking|tool_use|other content block |
Feldstop_reason | Typstring|null |
Feldusage | Typobject |
| Antwort | Bedingung | Nächster Schritt |
|---|---|---|
Antwort400 · invalid_request_error | BedingungPflichtfelder, Darstellung des Eingabematerials oder Parameterwert ungültig | Nächster SchrittDie angegebenen Felder vor einer neuen Erstellungsanfrage korrigieren. |
Ailoot Ultra meta/muse-spark-1.2
Verwenden Sie die oben angezeigten Methodenpfade.
Technisches Beispiel auf Englisch
Implement a specified responsive layout\n\nDraft semantic HTML and CSS for a product comparison section with a title, introduction and three feature columns. At narrow widths, stack the columns in the same reading order. Each column needs a heading and three bullet points. Use the placeholder copy supplied in your code and explain the breakpoint choice; return source only, without claiming a rendered result.A bounded HTML/CSS section and a short explanation of stacking behavior and reading order.At the proposed narrow breakpoint, the DOM order and visual order match and no horizontal overflow is introduced.