Seed 2.0 Code is ByteDance Seed’s coding-oriented member of the Seed2.0 lineup. It works on written requirements, source code and development context to produce implementations, explanations and proposed tool operations. The maker’s documented Code profile combines deep reasoning, text generation, multimodal understanding and tool use. It remains a separate choice from the general-purpose Pro, Lite and Mini models, so a coding assignment should use the Code edition’s own conversation and tool format.
Prepare the task as an engineering brief: describe the behaviour, the existing interfaces, the code that matters and the constraints that must survive the change. Include a representative input or a clear reproduction of the failure. For a bug, ask the model to trace that input through the relevant conditions before proposing a correction. For a feature, describe the visible states and the final artifact, such as a changed function, a component or a coordinated patch across named files.
An illustrative request is: “Update this form so that validation explains the missing field and preserves the user’s input. Keep the existing field names and return the changed component with a description of its states.” A repository-level brief should also identify the boundaries between modules and any existing behaviour that is intentionally retained. This gives the coding model a concrete target rather than a broad instruction to improve a codebase.
The Seed2.0 family is designed around multi-step instruction execution and cycles of planning, action and reflection. A coding application supplies the functions for inspecting files, running commands or obtaining other observations. The model proposes an operation; the application performs it and returns the actual result. Use that result to diagnose an error or revise the implementation. A proposed test command and a successful test result are different artifacts.
For a visual interface assignment, pair the text requirements with a readable mockup or screenshot in a supported multimodal workflow. State whether the image represents the current state or the intended result, and identify which layout details matter. Ask for code tied to the visible design and behavioural requirements, then use the rendered interface as feedback for subsequent work.
The manufacturer’s published Code reference profile has a 256K context and a combined output allowance of up to 128K tokens including reasoning. A context budget also contains source files, conversation and tool observations; it is not a promise that a requested amount of final code will fit independently. Keep file names and relevant boundaries visible, and reserve space for the final implementation and its explanation. The applicable request format determines the exact input and completion controls.
Seed2.0’s report identifies long-horizon context integration and repository-level delivery as continuing challenges. Define completion in terms of the requested behaviour and observed validation. A useful handoff contains the code artifact, the assumptions it uses, the evidence obtained from tools and any unresolved dependency. When information is missing, have the model identify what it needs rather than invent a library contract, a file or a successful execution.
", "aboutText": "Seed 2.0 Code is ByteDance Seed’s coding-oriented member of the Seed2.0 lineup. It works on written requirements, source code and development context to produce implementations, explanations and proposed tool operations. The maker’s documented Code profile combines deep reasoning, text generation, multimodal understanding and tool use. It remains a separate choice from the general-purpose Pro, Lite and Mini models, so a coding assignment should use the Code edition’s own conversation and tool format.\n\n### From a development request to a code artifact\n\nPrepare the task as an engineering brief: describe the behaviour, the existing interfaces, the code that matters and the constraints that must survive the change. Include a representative input or a clear reproduction of the failure. For a bug, ask the model to trace that input through the relevant conditions before proposing a correction. For a feature, describe the visible states and the final artifact, such as a changed function, a component or a coordinated patch across named files.\n\nAn illustrative request is: “Update this form so that validation explains the missing field and preserves the user’s input. Keep the existing field names and return the changed component with a description of its states.” A repository-level brief should also identify the boundaries between modules and any existing behaviour that is intentionally retained. This gives the coding model a concrete target rather than a broad instruction to improve a codebase.\n\n### Tools, observations and iterative work\n\nThe Seed2.0 family is designed around multi-step instruction execution and cycles of planning, action and reflection. A coding application supplies the functions for inspecting files, running commands or obtaining other observations. The model proposes an operation; the application performs it and returns the actual result. Use that result to diagnose an error or revise the implementation. A proposed test command and a successful test result are different artifacts.\n\nFor a visual interface assignment, pair the text requirements with a readable mockup or screenshot in a supported multimodal workflow. State whether the image represents the current state or the intended result, and identify which layout details matter. Ask for code tied to the visible design and behavioural requirements, then use the rendered interface as feedback for subsequent work.\n\n### Context and completion\n\nThe manufacturer’s published Code reference profile has a 256K context and a combined output allowance of up to 128K tokens including reasoning. A context budget also contains source files, conversation and tool observations; it is not a promise that a requested amount of final code will fit independently. Keep file names and relevant boundaries visible, and reserve space for the final implementation and its explanation. The applicable request format determines the exact input and completion controls.\n\nSeed2.0’s report identifies long-horizon context integration and repository-level delivery as continuing challenges. Define completion in terms of the requested behaviour and observed validation. A useful handoff contains the code artifact, the assumptions it uses, the evidence obtained from tools and any unresolved dependency. When information is missing, have the model identify what it needs rather than invent a library contract, a file or a successful execution.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Repair a zero-price formatter\n\nFix this Python function without changing the treatment of None: def price_label(value): return 'Unavailable' if not value else f'${value:.2f}'. A price of 0 must display '$0.00'. Return the corrected function, explain the failing condition and provide three assert statements covering None, 0 and 12.5.Corrected Python function, one brief explanation and three executable assertions.Zero must produce $0.00 while None still produces Unavailable.bytedance-seed/seed-2.0-codeSeed 2.0 Code focuses the Seed2.0 family on software engineering: understanding requirements, generating or editing code and working through tool-assisted development tasks. Supply the relevant source, observed behaviour and desired result to obtain a focused implementation and explanation.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Seed 2.0 Code is ByteDance Seed’s coding-oriented member of the Seed2.0 lineup. It works on written requirements, source code and development context to produce implementations, explanations and proposed tool operations. The maker’s documented Code profile combines deep reasoning, text generation, multimodal understanding and tool use. It remains a separate choice from the general-purpose Pro, Lite and Mini models, so a coding assignment should use the Code edition’s own conversation and tool format.
Prepare the task as an engineering brief: describe the behaviour, the existing interfaces, the code that matters and the constraints that must survive the change. Include a representative input or a clear reproduction of the failure. For a bug, ask the model to trace that input through the relevant conditions before proposing a correction. For a feature, describe the visible states and the final artifact, such as a changed function, a component or a coordinated patch across named files.
An illustrative request is: “Update this form so that validation explains the missing field and preserves the user’s input. Keep the existing field names and return the changed component with a description of its states.” A repository-level brief should also identify the boundaries between modules and any existing behaviour that is intentionally retained. This gives the coding model a concrete target rather than a broad instruction to improve a codebase.
The Seed2.0 family is designed around multi-step instruction execution and cycles of planning, action and reflection. A coding application supplies the functions for inspecting files, running commands or obtaining other observations. The model proposes an operation; the application performs it and returns the actual result. Use that result to diagnose an error or revise the implementation. A proposed test command and a successful test result are different artifacts.
For a visual interface assignment, pair the text requirements with a readable mockup or screenshot in a supported multimodal workflow. State whether the image represents the current state or the intended result, and identify which layout details matter. Ask for code tied to the visible design and behavioural requirements, then use the rendered interface as feedback for subsequent work.
The manufacturer’s published Code reference profile has a 256K context and a combined output allowance of up to 128K tokens including reasoning. A context budget also contains source files, conversation and tool observations; it is not a promise that a requested amount of final code will fit independently. Keep file names and relevant boundaries visible, and reserve space for the final implementation and its explanation. The applicable request format determines the exact input and completion controls.
Seed2.0’s report identifies long-horizon context integration and repository-level delivery as continuing challenges. Define completion in terms of the requested behaviour and observed validation. A useful handoff contains the code artifact, the assumptions it uses, the evidence obtained from tools and any unresolved dependency. When information is missing, have the model identify what it needs rather than invent a library contract, a file or a successful execution.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits bytedance-seed/seed-2.0-code | 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.001 / 1K tokens Output · Output tokens $0.006 / 1K tokens Input · Cache read — / 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 including128,000 | Charge Input · Input tokens $0.001 / 1K tokens Output · Output tokens $0.006 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 2 | Rate schedule— | Context tokens, more than128,000 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.002 / 1K tokens Output · Output tokens $0.012 / 1K tokens Input · Cache read — / 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": "bytedance-seed/seed-2.0-code", "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='bytedance-seed/seed-2.0-code',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='bytedance-seed/seed-2.0-code',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 bytedance-seed/seed-2.0-code
Use the method paths shown above.
bytedance-seed/seed-2.0-codeSeed 2.0 Code focuses the Seed2.0 family on software engineering: understanding requirements, generating or editing code and working through tool-assisted development tasks. Supply the relevant source, observed behaviour and desired result to obtain a focused implementation and explanation.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Seed 2.0 Code is ByteDance Seed’s coding-oriented member of the Seed2.0 lineup. It works on written requirements, source code and development context to produce implementations, explanations and proposed tool operations. The maker’s documented Code profile combines deep reasoning, text generation, multimodal understanding and tool use. It remains a separate choice from the general-purpose Pro, Lite and Mini models, so a coding assignment should use the Code edition’s own conversation and tool format.
Prepare the task as an engineering brief: describe the behaviour, the existing interfaces, the code that matters and the constraints that must survive the change. Include a representative input or a clear reproduction of the failure. For a bug, ask the model to trace that input through the relevant conditions before proposing a correction. For a feature, describe the visible states and the final artifact, such as a changed function, a component or a coordinated patch across named files.
An illustrative request is: “Update this form so that validation explains the missing field and preserves the user’s input. Keep the existing field names and return the changed component with a description of its states.” A repository-level brief should also identify the boundaries between modules and any existing behaviour that is intentionally retained. This gives the coding model a concrete target rather than a broad instruction to improve a codebase.
The Seed2.0 family is designed around multi-step instruction execution and cycles of planning, action and reflection. A coding application supplies the functions for inspecting files, running commands or obtaining other observations. The model proposes an operation; the application performs it and returns the actual result. Use that result to diagnose an error or revise the implementation. A proposed test command and a successful test result are different artifacts.
For a visual interface assignment, pair the text requirements with a readable mockup or screenshot in a supported multimodal workflow. State whether the image represents the current state or the intended result, and identify which layout details matter. Ask for code tied to the visible design and behavioural requirements, then use the rendered interface as feedback for subsequent work.
The manufacturer’s published Code reference profile has a 256K context and a combined output allowance of up to 128K tokens including reasoning. A context budget also contains source files, conversation and tool observations; it is not a promise that a requested amount of final code will fit independently. Keep file names and relevant boundaries visible, and reserve space for the final implementation and its explanation. The applicable request format determines the exact input and completion controls.
Seed2.0’s report identifies long-horizon context integration and repository-level delivery as continuing challenges. Define completion in terms of the requested behaviour and observed validation. A useful handoff contains the code artifact, the assumptions it uses, the evidence obtained from tools and any unresolved dependency. When information is missing, have the model identify what it needs rather than invent a library contract, a file or a successful execution.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits bytedance-seed/seed-2.0-code | 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.001 / 1K tokens Output · Output tokens $0.006 / 1K tokens Input · Cache read — / 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 including128,000 | Charge Input · Input tokens $0.001 / 1K tokens Output · Output tokens $0.006 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 2 | Rate schedule— | Context tokens, more than128,000 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.002 / 1K tokens Output · Output tokens $0.012 / 1K tokens Input · Cache read — / 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": "bytedance-seed/seed-2.0-code",\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': 'bytedance-seed/seed-2.0-code', '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': 'bytedance-seed/seed-2.0-code', '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 bytedance-seed/seed-2.0-code
Use the method paths shown above.
Technical example in English
Repair a zero-price formatter\n\nFix this Python function without changing the treatment of None: def price_label(value): return 'Unavailable' if not value else f'${value:.2f}'. A price of 0 must display '$0.00'. Return the corrected function, explain the failing condition and provide three assert statements covering None, 0 and 12.5.Corrected Python function, one brief explanation and three executable assertions.Zero must produce $0.00 while None still produces Unavailable.