Ember-1 is Fireworks Research’s specialised model built on Kimi K3. Its defining change is training that shortens unnecessary reasoning while preserving useful analysis for coding and agent workloads. The producer positions it for repeated, tool-guided tasks where long reasoning traces can accumulate across a conversation. Its documented profile supports text generation, image input and function calling; the resulting answer, code or proposed operation is text.
The manufacturer developed Ember-1 with task-focused training across a broad set of workloads. This is a trained model distinction rather than simply selecting a lower reasoning-effort setting on its base. It should retain its own identity when comparing results with Kimi K3: the goal is a more economical reasoning trajectory, not an assumption that every original setting, capability or future update is identical.
For a software task, provide the relevant code, the observed failure, the behaviour you want and the contracts that must remain stable. Ask for a focused implementation and an explanation tied to the actual source. A practical brief is: “Trace this failing input, identify the first incorrect condition and return the corrected function with the evidence that justifies the change.” Keep the final artifact explicit even when the task requires several observations.
The producer’s use cases include coding assistants and agents that alternate between model decisions and tool results. Supply function descriptions and argument schemas suited to the job. The model can propose a file inspection, a calculation or another available operation; the application performs it and returns the actual observation. Use that result in the next turn rather than allowing a proposed action to stand in for execution.
For a longer task, retain the relevant failure, correction and verification observations in a concise record. Request the completed code or analytical result separately from intermediate discussion. Shorter reasoning is useful only if the output still meets the task’s required behaviour and includes the evidence needed to review it.
Ember-1’s maker catalogue supports image input. A visual coding task can combine a screenshot with requirements and source code, asking for an explanation or implementation grounded in what is visible. Label each image and distinguish the current state from the intended result. Make important text readable and ask the answer to identify the visible detail supporting a finding.
The producer lists a context on the order of one million tokens. This is a source-capacity profile, not an independent promise of that many answer tokens. The prompt, source material, tool history and generated reasoning share the applicable request budget. Organise a large repository or document collection around the actual question and reserve room for the result.
A useful deliverable is a focused patch, an evidence-backed explanation or a completed comparison against stated criteria. For a fact that depends on current information, supply an authoritative passage or an appropriate lookup tool. The model’s shorter reasoning direction does not make missing evidence available, execute a function or validate code independently. Check the resulting artifact against the requirements and the observations returned by the surrounding workflow.
", "aboutText": "Ember-1 is Fireworks Research’s specialised model built on Kimi K3. Its defining change is training that shortens unnecessary reasoning while preserving useful analysis for coding and agent workloads. The producer positions it for repeated, tool-guided tasks where long reasoning traces can accumulate across a conversation. Its documented profile supports text generation, image input and function calling; the resulting answer, code or proposed operation is text.\n\n### What the training changes\n\nThe manufacturer developed Ember-1 with task-focused training across a broad set of workloads. This is a trained model distinction rather than simply selecting a lower reasoning-effort setting on its base. It should retain its own identity when comparing results with Kimi K3: the goal is a more economical reasoning trajectory, not an assumption that every original setting, capability or future update is identical.\n\nFor a software task, provide the relevant code, the observed failure, the behaviour you want and the contracts that must remain stable. Ask for a focused implementation and an explanation tied to the actual source. A practical brief is: “Trace this failing input, identify the first incorrect condition and return the corrected function with the evidence that justifies the change.” Keep the final artifact explicit even when the task requires several observations.\n\n### Coding and agent workloads\n\nThe producer’s use cases include coding assistants and agents that alternate between model decisions and tool results. Supply function descriptions and argument schemas suited to the job. The model can propose a file inspection, a calculation or another available operation; the application performs it and returns the actual observation. Use that result in the next turn rather than allowing a proposed action to stand in for execution.\n\nFor a longer task, retain the relevant failure, correction and verification observations in a concise record. Request the completed code or analytical result separately from intermediate discussion. Shorter reasoning is useful only if the output still meets the task’s required behaviour and includes the evidence needed to review it.\n\n### Images and long source material\n\nEmber-1’s maker catalogue supports image input. A visual coding task can combine a screenshot with requirements and source code, asking for an explanation or implementation grounded in what is visible. Label each image and distinguish the current state from the intended result. Make important text readable and ask the answer to identify the visible detail supporting a finding.\n\nThe producer lists a context on the order of one million tokens. This is a source-capacity profile, not an independent promise of that many answer tokens. The prompt, source material, tool history and generated reasoning share the applicable request budget. Organise a large repository or document collection around the actual question and reserve room for the result.\n\n### Reviewable outputs\n\nA useful deliverable is a focused patch, an evidence-backed explanation or a completed comparison against stated criteria. For a fact that depends on current information, supply an authoritative passage or an appropriate lookup tool. The model’s shorter reasoning direction does not make missing evidence available, execute a function or validate code independently. Check the resulting artifact against the requirements and the observations returned by the surrounding workflow.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Fix an inclusive upper-bound error\n\nFind the bug in this Python function: def allowed(age):\n return age > 18 and age < 65\nThe rule permits ages 18 through 65 inclusive. Return the corrected function, explain the boundary error and write tests for ages 17, 18, 65 and 66. Treat the supplied rule as authoritative.A minimal corrected function, a boundary explanation and four executable test cases.Check that both endpoints are accepted and both adjacent out-of-range values are rejected.fireworks/ember-1Ember-1 is Fireworks Research’s Kimi K3-based model trained to shorten unnecessary reasoning for coding and agent tasks. Its maker profile supports text and image input, text generation and function calling, making it useful for focused development work and source-guided analysis.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Ember-1 is Fireworks Research’s specialised model built on Kimi K3. Its defining change is training that shortens unnecessary reasoning while preserving useful analysis for coding and agent workloads. The producer positions it for repeated, tool-guided tasks where long reasoning traces can accumulate across a conversation. Its documented profile supports text generation, image input and function calling; the resulting answer, code or proposed operation is text.
The manufacturer developed Ember-1 with task-focused training across a broad set of workloads. This is a trained model distinction rather than simply selecting a lower reasoning-effort setting on its base. It should retain its own identity when comparing results with Kimi K3: the goal is a more economical reasoning trajectory, not an assumption that every original setting, capability or future update is identical.
For a software task, provide the relevant code, the observed failure, the behaviour you want and the contracts that must remain stable. Ask for a focused implementation and an explanation tied to the actual source. A practical brief is: “Trace this failing input, identify the first incorrect condition and return the corrected function with the evidence that justifies the change.” Keep the final artifact explicit even when the task requires several observations.
The producer’s use cases include coding assistants and agents that alternate between model decisions and tool results. Supply function descriptions and argument schemas suited to the job. The model can propose a file inspection, a calculation or another available operation; the application performs it and returns the actual observation. Use that result in the next turn rather than allowing a proposed action to stand in for execution.
For a longer task, retain the relevant failure, correction and verification observations in a concise record. Request the completed code or analytical result separately from intermediate discussion. Shorter reasoning is useful only if the output still meets the task’s required behaviour and includes the evidence needed to review it.
Ember-1’s maker catalogue supports image input. A visual coding task can combine a screenshot with requirements and source code, asking for an explanation or implementation grounded in what is visible. Label each image and distinguish the current state from the intended result. Make important text readable and ask the answer to identify the visible detail supporting a finding.
The producer lists a context on the order of one million tokens. This is a source-capacity profile, not an independent promise of that many answer tokens. The prompt, source material, tool history and generated reasoning share the applicable request budget. Organise a large repository or document collection around the actual question and reserve room for the result.
A useful deliverable is a focused patch, an evidence-backed explanation or a completed comparison against stated criteria. For a fact that depends on current information, supply an authoritative passage or an appropriate lookup tool. The model’s shorter reasoning direction does not make missing evidence available, execute a function or validate code independently. Check the resulting artifact against the requirements and the observations returned by the surrounding workflow.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits fireworks/ember-1 | 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.006 / 1K tokens Output · Output tokens $0.03 / 1K tokens Input · Cache read $0.0006 / 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.006 / 1K tokens Output · Output tokens $0.03 / 1K tokens Input · Cache read $0.0006 / 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": "fireworks/ember-1", "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='fireworks/ember-1',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='fireworks/ember-1',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 fireworks/ember-1
Use the method paths shown above.
fireworks/ember-1Ember-1 is Fireworks Research’s Kimi K3-based model trained to shorten unnecessary reasoning for coding and agent tasks. Its maker profile supports text and image input, text generation and function calling, making it useful for focused development work and source-guided analysis.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Ember-1 is Fireworks Research’s specialised model built on Kimi K3. Its defining change is training that shortens unnecessary reasoning while preserving useful analysis for coding and agent workloads. The producer positions it for repeated, tool-guided tasks where long reasoning traces can accumulate across a conversation. Its documented profile supports text generation, image input and function calling; the resulting answer, code or proposed operation is text.
The manufacturer developed Ember-1 with task-focused training across a broad set of workloads. This is a trained model distinction rather than simply selecting a lower reasoning-effort setting on its base. It should retain its own identity when comparing results with Kimi K3: the goal is a more economical reasoning trajectory, not an assumption that every original setting, capability or future update is identical.
For a software task, provide the relevant code, the observed failure, the behaviour you want and the contracts that must remain stable. Ask for a focused implementation and an explanation tied to the actual source. A practical brief is: “Trace this failing input, identify the first incorrect condition and return the corrected function with the evidence that justifies the change.” Keep the final artifact explicit even when the task requires several observations.
The producer’s use cases include coding assistants and agents that alternate between model decisions and tool results. Supply function descriptions and argument schemas suited to the job. The model can propose a file inspection, a calculation or another available operation; the application performs it and returns the actual observation. Use that result in the next turn rather than allowing a proposed action to stand in for execution.
For a longer task, retain the relevant failure, correction and verification observations in a concise record. Request the completed code or analytical result separately from intermediate discussion. Shorter reasoning is useful only if the output still meets the task’s required behaviour and includes the evidence needed to review it.
Ember-1’s maker catalogue supports image input. A visual coding task can combine a screenshot with requirements and source code, asking for an explanation or implementation grounded in what is visible. Label each image and distinguish the current state from the intended result. Make important text readable and ask the answer to identify the visible detail supporting a finding.
The producer lists a context on the order of one million tokens. This is a source-capacity profile, not an independent promise of that many answer tokens. The prompt, source material, tool history and generated reasoning share the applicable request budget. Organise a large repository or document collection around the actual question and reserve room for the result.
A useful deliverable is a focused patch, an evidence-backed explanation or a completed comparison against stated criteria. For a fact that depends on current information, supply an authoritative passage or an appropriate lookup tool. The model’s shorter reasoning direction does not make missing evidence available, execute a function or validate code independently. Check the resulting artifact against the requirements and the observations returned by the surrounding workflow.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits fireworks/ember-1 | 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.006 / 1K tokens Output · Output tokens $0.03 / 1K tokens Input · Cache read $0.0006 / 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.006 / 1K tokens Output · Output tokens $0.03 / 1K tokens Input · Cache read $0.0006 / 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": "fireworks/ember-1",\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': 'fireworks/ember-1', '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': 'fireworks/ember-1', '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 fireworks/ember-1
Use the method paths shown above.
Technical example in English
Fix an inclusive upper-bound error\n\nFind the bug in this Python function: def allowed(age):\n return age > 18 and age < 65\nThe rule permits ages 18 through 65 inclusive. Return the corrected function, explain the boundary error and write tests for ages 17, 18, 65 and 66. Treat the supplied rule as authoritative.A minimal corrected function, a boundary explanation and four executable test cases.Check that both endpoints are accepted and both adjacent out-of-range values are rejected.