Muse Spark 1.2 is a coding-focused update to Meta's Muse Spark 1.1, with an emphasis on multimodal understanding and visual reasoning. The maker's demonstrations connect images and video with digital artifacts such as web pages and games, while its model table lists a 1,048,576-token context and text output. This entry concerns Standard 1.2, distinct from Contributor 1.2 and later 1.3.
Visual coding
The release describes translating visual layout, hierarchy and style into working code and then inspecting the resulting artifact through tools. For a useful task, supply the image or clip together with the behavior to implement. A screenshot can show appearance but may leave interactions unspecified, so name the controls, states and expected response to user actions that the result should include.
Ask for the visible structure, the proposed implementation and the assumptions separately. For example, a page-reconstruction task can require the named sections and visual relationships shown in the reference, then request the code for one defined interaction. Rendering and exercising that code require the connected environment; the resulting screenshot or execution feedback can become input for the next correction.
The maker identifies chart understanding and visual reasoning beyond code generation. Preserve the axes, units and labels in a chart and request the observation supporting each conclusion. For a diagram, identify the relationship to explain and the source labels to retain. For a document image, distinguish transcription of the visible wording from a summary or interpretation.
Spatial and audio-visual workflows
The 1.2 announcement also discusses a specialized robotics variant and a two-level planning/action system. Those are distinct experimental components: a high-level model reasons about the scene and subtasks, while a separate vision-language-action policy performs low-level actions. The Standard text-output model should not be described as a robotic actuator simply because the family release contains that demonstration.
For the Standard version, the model table documents text, images, video, audio and PDFs as inputs. An audio-visual task can ask for the event or spoken condition relevant to a question and return an ordered account of the supporting material. Identify the relevant segment and the form of the answer rather than asking for an undirected summary of every modality.
The maker's examples combine video understanding, dense captioning and tool-assisted inspection. A practical workflow can compare a demonstration with its written procedure, request the visible matches and differences and then prepare a text result for a later application step. Generated prose, code and structured findings are the documented output; image or speech generation belongs to separately named components.
Reasoning settings and context
Muse Spark reasons internally before producing visible text. The documented effort levels applicable to 1.2 are minimal, low, medium, high and xhigh. Max belongs to Standard 1.3, and none is not a supported way to disable reasoning. When no effort is specified, the model uses a model-determined level.
The 1,048,576-token context can retain related source material and conversation, but the goal and final artifact still need to be defined. For a long document task, identify the question, label each source and keep its location beside extracted information. Reasoning and visible answer tokens share the output budget, so reserve enough space for the explanation or code the task actually needs.
Raw internal reasoning is not exposed as ordinary text. The maker's chat interface also does not carry a readable private trace across turns for external callers; preserve the visible messages, sources and returned tool outcomes needed by a follow-up. Log probabilities are unsupported, so the model does not supply that feature as a confidence measure for its conclusions.
Tools and structured artifacts
The application describes developer functions, the model generates the proposed calls and arguments, and the application executes them and returns the result for each call. The model can then inspect the actual feedback and choose the next step. The release's emphasis on examining both visual inputs and generated artifacts depends on those tools being part of the environment.
Structured output can constrain the text to a defined JSON schema. A visual extraction record can contain the source image, object or label, observed value and interpretation. A coding review can identify the affected symbol, mismatch and proposed change. The maker's strict mode requires a plain-object root, all listed properties required and extra properties disabled; recursive schemas are rejected.
Define the artifact's correctness in practical terms: which source details it must preserve, how an interaction should behave and what returned feedback would establish that behavior. The sources read do not provide independent maximum input or output-token capacities beyond the model context. Preserve the Standard 1.2 edition and the difference between a proposed text artifact and the execution or rendering result used to inspect it.
", "aboutText": "Muse Spark 1.2 is a coding-focused update to Meta's Muse Spark 1.1, with an emphasis on multimodal understanding and visual reasoning. The maker's demonstrations connect images and video with digital artifacts such as web pages and games, while its model table lists a 1,048,576-token context and text output. This entry concerns Standard 1.2, distinct from Contributor 1.2 and later 1.3.\n\nVisual coding\n\nThe release describes translating visual layout, hierarchy and style into working code and then inspecting the resulting artifact through tools. For a useful task, supply the image or clip together with the behavior to implement. A screenshot can show appearance but may leave interactions unspecified, so name the controls, states and expected response to user actions that the result should include.\n\nAsk for the visible structure, the proposed implementation and the assumptions separately. For example, a page-reconstruction task can require the named sections and visual relationships shown in the reference, then request the code for one defined interaction. Rendering and exercising that code require the connected environment; the resulting screenshot or execution feedback can become input for the next correction.\n\nThe maker identifies chart understanding and visual reasoning beyond code generation. Preserve the axes, units and labels in a chart and request the observation supporting each conclusion. For a diagram, identify the relationship to explain and the source labels to retain. For a document image, distinguish transcription of the visible wording from a summary or interpretation.\n\nSpatial and audio-visual workflows\n\nThe 1.2 announcement also discusses a specialized robotics variant and a two-level planning/action system. Those are distinct experimental components: a high-level model reasons about the scene and subtasks, while a separate vision-language-action policy performs low-level actions. The Standard text-output model should not be described as a robotic actuator simply because the family release contains that demonstration.\n\nFor the Standard version, the model table documents text, images, video, audio and PDFs as inputs. An audio-visual task can ask for the event or spoken condition relevant to a question and return an ordered account of the supporting material. Identify the relevant segment and the form of the answer rather than asking for an undirected summary of every modality.\n\nThe maker's examples combine video understanding, dense captioning and tool-assisted inspection. A practical workflow can compare a demonstration with its written procedure, request the visible matches and differences and then prepare a text result for a later application step. Generated prose, code and structured findings are the documented output; image or speech generation belongs to separately named components.\n\nReasoning settings and context\n\nMuse Spark reasons internally before producing visible text. The documented effort levels applicable to 1.2 are minimal, low, medium, high and xhigh. Max belongs to Standard 1.3, and none is not a supported way to disable reasoning. When no effort is specified, the model uses a model-determined level.\n\nThe 1,048,576-token context can retain related source material and conversation, but the goal and final artifact still need to be defined. For a long document task, identify the question, label each source and keep its location beside extracted information. Reasoning and visible answer tokens share the output budget, so reserve enough space for the explanation or code the task actually needs.\n\nRaw internal reasoning is not exposed as ordinary text. The maker's chat interface also does not carry a readable private trace across turns for external callers; preserve the visible messages, sources and returned tool outcomes needed by a follow-up. Log probabilities are unsupported, so the model does not supply that feature as a confidence measure for its conclusions.\n\nTools and structured artifacts\n\nThe application describes developer functions, the model generates the proposed calls and arguments, and the application executes them and returns the result for each call. The model can then inspect the actual feedback and choose the next step. The release's emphasis on examining both visual inputs and generated artifacts depends on those tools being part of the environment.\n\nStructured output can constrain the text to a defined JSON schema. A visual extraction record can contain the source image, object or label, observed value and interpretation. A coding review can identify the affected symbol, mismatch and proposed change. The maker's strict mode requires a plain-object root, all listed properties required and extra properties disabled; recursive schemas are rejected.\n\nDefine the artifact's correctness in practical terms: which source details it must preserve, how an interaction should behave and what returned feedback would establish that behavior. The sources read do not provide independent maximum input or output-token capacities beyond the model context. Preserve the Standard 1.2 edition and the difference between a proposed text artifact and the execution or rendering result used to inspect it.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
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 is Meta's multimodal reasoning model with a focus on visual coding, charts and audio-visual understanding. It can turn supplied images or video into proposed web and game code through connected tools, with text output and a 1,048,576-token maker context.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Muse Spark 1.2 is a coding-focused update to Meta's Muse Spark 1.1, with an emphasis on multimodal understanding and visual reasoning. The maker's demonstrations connect images and video with digital artifacts such as web pages and games, while its model table lists a 1,048,576-token context and text output. This entry concerns Standard 1.2, distinct from Contributor 1.2 and later 1.3.
Visual coding
The release describes translating visual layout, hierarchy and style into working code and then inspecting the resulting artifact through tools. For a useful task, supply the image or clip together with the behavior to implement. A screenshot can show appearance but may leave interactions unspecified, so name the controls, states and expected response to user actions that the result should include.
Ask for the visible structure, the proposed implementation and the assumptions separately. For example, a page-reconstruction task can require the named sections and visual relationships shown in the reference, then request the code for one defined interaction. Rendering and exercising that code require the connected environment; the resulting screenshot or execution feedback can become input for the next correction.
The maker identifies chart understanding and visual reasoning beyond code generation. Preserve the axes, units and labels in a chart and request the observation supporting each conclusion. For a diagram, identify the relationship to explain and the source labels to retain. For a document image, distinguish transcription of the visible wording from a summary or interpretation.
Spatial and audio-visual workflows
The 1.2 announcement also discusses a specialized robotics variant and a two-level planning/action system. Those are distinct experimental components: a high-level model reasons about the scene and subtasks, while a separate vision-language-action policy performs low-level actions. The Standard text-output model should not be described as a robotic actuator simply because the family release contains that demonstration.
For the Standard version, the model table documents text, images, video, audio and PDFs as inputs. An audio-visual task can ask for the event or spoken condition relevant to a question and return an ordered account of the supporting material. Identify the relevant segment and the form of the answer rather than asking for an undirected summary of every modality.
The maker's examples combine video understanding, dense captioning and tool-assisted inspection. A practical workflow can compare a demonstration with its written procedure, request the visible matches and differences and then prepare a text result for a later application step. Generated prose, code and structured findings are the documented output; image or speech generation belongs to separately named components.
Reasoning settings and context
Muse Spark reasons internally before producing visible text. The documented effort levels applicable to 1.2 are minimal, low, medium, high and xhigh. Max belongs to Standard 1.3, and none is not a supported way to disable reasoning. When no effort is specified, the model uses a model-determined level.
The 1,048,576-token context can retain related source material and conversation, but the goal and final artifact still need to be defined. For a long document task, identify the question, label each source and keep its location beside extracted information. Reasoning and visible answer tokens share the output budget, so reserve enough space for the explanation or code the task actually needs.
Raw internal reasoning is not exposed as ordinary text. The maker's chat interface also does not carry a readable private trace across turns for external callers; preserve the visible messages, sources and returned tool outcomes needed by a follow-up. Log probabilities are unsupported, so the model does not supply that feature as a confidence measure for its conclusions.
Tools and structured artifacts
The application describes developer functions, the model generates the proposed calls and arguments, and the application executes them and returns the result for each call. The model can then inspect the actual feedback and choose the next step. The release's emphasis on examining both visual inputs and generated artifacts depends on those tools being part of the environment.
Structured output can constrain the text to a defined JSON schema. A visual extraction record can contain the source image, object or label, observed value and interpretation. A coding review can identify the affected symbol, mismatch and proposed change. The maker's strict mode requires a plain-object root, all listed properties required and extra properties disabled; recursive schemas are rejected.
Define the artifact's correctness in practical terms: which source details it must preserve, how an interaction should behave and what returned feedback would establish that behavior. The sources read do not provide independent maximum input or output-token capacities beyond the model context. Preserve the Standard 1.2 edition and the difference between a proposed text artifact and the execution or rendering result used to inspect it.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits meta/muse-spark-1.2 | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits Examples: system, user, assistant, tool, function Conditions: These roles are explicitly represented by Source compatibility types; the exact model role set remains model-specific. Model-specific | Default— |
Fieldmessages[].content | Typestring|content_part[]|null | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_calls | Typetool_call[] | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_call_id | Typestring | RequirementOptional | Values & limits Applies when: role=tool; use actual returned ID | Default— |
Fieldmessages[].name | Typestring | RequirementOptional | Values & limits | Default— |
Fieldmessages[].reasoning_content | Typestring | RequirementOptional | Values & limits Applies when: Round-trip actual returned reasoning where this model uses it | Default— |
Fieldmessages[].reasoning_details | Typeobject|array | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmax_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldmax_completion_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Fieldstream_options.include_usage | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtop_p | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldstop | Typestring|string[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools | Typefunction_tool[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools[].type | Typestring | RequirementOptional | Values & limits function Model-specific | Default— |
Fieldtools[].function.name | Typestring | RequirementRequired | Values & limits Applies when: function tool supplied | Default— |
Fieldtools[].function.description | Typestring | RequirementOptional | Values & limits | Default— |
Fieldtools[].function.parameters | TypeJSON_schema | RequirementOptional | Values & limits | Default— |
Fieldtool_choice | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldparallel_tool_calls | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldresponse_format | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning_effort | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldservice_tier | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldinstructions | Typestring | RequirementOptional | Values & limits Compatibility field | Default— |
Fieldfunctions | Typefunction[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldfunction_call | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldprompt_cache_options | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmodalities | Typestring[] | RequirementOptional | Values & limits text | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options is rejected on this Ultra text route | Default— |
Fieldcache_control.ttl | Typestring | RequirementOptional | Values & limits Conditions: 1h is rejected in actual prompt-cache locations | Default— |
Text · UTF8 text
messages[].content
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages |
Parametermaterial_types | Contracttext |
Parametermessages | Contractmessage array with role/content shape |
Parameterfile_material | Contractactual UTF-8 document inserted as literal text; no file ID inferred |
Parameteroptional_controls | Contractstream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametercontrol_scope | Contractmodel-specific; user function tools differ from hosted tools |
Parameteroutput_modalities | Contracttext |
Parameterhosted_operations | Contractfalse |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous_or_streamed
Send exact model ID with messages.
Context length is not an output cap.
A text file may supply literal text; image/audio/file-object inputs need exact binding.
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Context tokens, more than | Context tokens, up to and including | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Context tokens, more than— | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.0025 / 1K tokens Output · Output tokens $0.0085 / 1K tokens Input · Cache read $0.0003 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 1 | Rate schedule— | Context tokens, more than0 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.0025 / 1K tokens Output · Output tokens $0.0085 / 1K tokens Input · Cache read $0.0003 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
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 or SSE
Keep every complete returned response, file and content part.
Keep every choice and its content/tool calls/reasoning. In SSE assemble deltas by choice/tool index, retain the final finish reason and usage.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldchoices[].index | Typeinteger |
Fieldchoices[].message.content | Typestring|null |
Fieldchoices[].message.tool_calls | Typetool_call[] |
Fieldchoices[].message.reasoning_content | Typestring |
Fieldchoices[].message.reasoning_details | Typeobject|array |
Fieldchoices[].finish_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra meta/muse-spark-1.2
Use the method paths shown above.
meta/muse-spark-1.2Muse Spark 1.2 is Meta's multimodal reasoning model with a focus on visual coding, charts and audio-visual understanding. It can turn supplied images or video into proposed web and game code through connected tools, with text output and a 1,048,576-token maker context.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Muse Spark 1.2 is a coding-focused update to Meta's Muse Spark 1.1, with an emphasis on multimodal understanding and visual reasoning. The maker's demonstrations connect images and video with digital artifacts such as web pages and games, while its model table lists a 1,048,576-token context and text output. This entry concerns Standard 1.2, distinct from Contributor 1.2 and later 1.3.
Visual coding
The release describes translating visual layout, hierarchy and style into working code and then inspecting the resulting artifact through tools. For a useful task, supply the image or clip together with the behavior to implement. A screenshot can show appearance but may leave interactions unspecified, so name the controls, states and expected response to user actions that the result should include.
Ask for the visible structure, the proposed implementation and the assumptions separately. For example, a page-reconstruction task can require the named sections and visual relationships shown in the reference, then request the code for one defined interaction. Rendering and exercising that code require the connected environment; the resulting screenshot or execution feedback can become input for the next correction.
The maker identifies chart understanding and visual reasoning beyond code generation. Preserve the axes, units and labels in a chart and request the observation supporting each conclusion. For a diagram, identify the relationship to explain and the source labels to retain. For a document image, distinguish transcription of the visible wording from a summary or interpretation.
Spatial and audio-visual workflows
The 1.2 announcement also discusses a specialized robotics variant and a two-level planning/action system. Those are distinct experimental components: a high-level model reasons about the scene and subtasks, while a separate vision-language-action policy performs low-level actions. The Standard text-output model should not be described as a robotic actuator simply because the family release contains that demonstration.
For the Standard version, the model table documents text, images, video, audio and PDFs as inputs. An audio-visual task can ask for the event or spoken condition relevant to a question and return an ordered account of the supporting material. Identify the relevant segment and the form of the answer rather than asking for an undirected summary of every modality.
The maker's examples combine video understanding, dense captioning and tool-assisted inspection. A practical workflow can compare a demonstration with its written procedure, request the visible matches and differences and then prepare a text result for a later application step. Generated prose, code and structured findings are the documented output; image or speech generation belongs to separately named components.
Reasoning settings and context
Muse Spark reasons internally before producing visible text. The documented effort levels applicable to 1.2 are minimal, low, medium, high and xhigh. Max belongs to Standard 1.3, and none is not a supported way to disable reasoning. When no effort is specified, the model uses a model-determined level.
The 1,048,576-token context can retain related source material and conversation, but the goal and final artifact still need to be defined. For a long document task, identify the question, label each source and keep its location beside extracted information. Reasoning and visible answer tokens share the output budget, so reserve enough space for the explanation or code the task actually needs.
Raw internal reasoning is not exposed as ordinary text. The maker's chat interface also does not carry a readable private trace across turns for external callers; preserve the visible messages, sources and returned tool outcomes needed by a follow-up. Log probabilities are unsupported, so the model does not supply that feature as a confidence measure for its conclusions.
Tools and structured artifacts
The application describes developer functions, the model generates the proposed calls and arguments, and the application executes them and returns the result for each call. The model can then inspect the actual feedback and choose the next step. The release's emphasis on examining both visual inputs and generated artifacts depends on those tools being part of the environment.
Structured output can constrain the text to a defined JSON schema. A visual extraction record can contain the source image, object or label, observed value and interpretation. A coding review can identify the affected symbol, mismatch and proposed change. The maker's strict mode requires a plain-object root, all listed properties required and extra properties disabled; recursive schemas are rejected.
Define the artifact's correctness in practical terms: which source details it must preserve, how an interaction should behave and what returned feedback would establish that behavior. The sources read do not provide independent maximum input or output-token capacities beyond the model context. Preserve the Standard 1.2 edition and the difference between a proposed text artifact and the execution or rendering result used to inspect it.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits meta/muse-spark-1.2 | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits user, assistant | Default— |
Fieldmessages[].content | Typestring | RequirementRequired | Values & limits | Default— |
Fieldmax_tokens | Typeinteger | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Text · UTF-8 text
messages[].content string
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages, max_tokens |
Parameteroptional_controls | Contractstream |
Parametermaterial_types | Contracttext |
Parametertext_file_material | ContractRead the actual UTF-8 document and put its text in the indicated input or message content string. |
Lifecycle: synchronous_or_streamed
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Context tokens, more than | Context tokens, up to and including | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Context tokens, more than— | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.0025 / 1K tokens Output · Output tokens $0.0085 / 1K tokens Input · Cache read $0.0003 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 1 | Rate schedule— | Context tokens, more than0 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.0025 / 1K tokens Output · Output tokens $0.0085 / 1K tokens Input · Cache read $0.0003 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
{\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 or SSE
Keep every complete returned response, file and content part.
Keep all content blocks, thinking signatures and actual tool-use IDs. Assemble all SSE block deltas; a first text block is not the complete output.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldid | Typestring |
Fieldmodel | Typestring |
Fieldcontent[] | Typetext|thinking|tool_use|other content block |
Fieldstop_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra meta/muse-spark-1.2
Use the method paths shown above.
Technical example in English
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.