prompt contains neither a knowledge cutoff nor the current date.
Images and audio enter user messages as the placeholder tokens <|image|> and <|audio|>, which at tokenization time expand into the structure markers and content codes of Section 2.1.1 and Section 2.1.2. The literals <image> and <audio> are aliases: the tokenizer maps them to the same identifiers, so existing datasets that use these literals tokenize correctly without conversion.
Tool outputs are enclosed by the tokens <|tool_output_start|> and <|tool_output_end|>, new in this release, which repurpose two reserved identifiers of the Apertus 1.0 vocabulary. During training the delimiters identify tool outputs so that they are excluded from the loss: the model conditions on them without learning to generate them. Explicit tokens are necessary because the raw bracket characters that previously enclosed tool results cannot be masked reliably at the token level; brackets merge into hundreds of vocabulary tokens. The assistant emits tool calls as a JSON array between <|tools_prefix|> and <|tools_suffix|>: each call is an object that maps the tool name to its arguments, and parallel calls are elements of the same array. The outputs of parallel calls return between the tool-output delimiters, separated by commas. The tool declaration in the developer message is unchanged from Apertus 1.0: available tools render as TypeScript-style type declarations, and a conversation without tools declares them as disabled.
In thinking mode the model reasons between <|inner_prefix|> and <|inner_suffix|> before its visible answer. Thinking is off by default and enabled per request through the chat template. The two delimiters are deliberately not marked as special tokens, so they survive detokenization and downstream code can parse the reasoning span out of the decoded text. The literals <think> and </think> alias to the same identifiers. The two surface forms repeatedly confuse downstream tooling during development, with training data, reinforcement-learning parsers, and serving stacks latching onto different renderings; the token identifiers, not the rendered strings, are canonical. The template itself supports tool calls inside the thinking span; that the launch serving integrations expose tool calling and thinking only separately is a serving limitation, not a format constraint. Figure 8 shows a rendered conversation that exercises the full format: the default system prompt, the developer message with the deliberation flag and a tool declaration, and an assistant turn that thinks, calls the tool, and answers after the tool output returns.
Rendered conversation with thinking enabled and one tool declared
<|system_start|>You are Apertus 1.5 Omni, a multimodal assistant
developed by the Swiss AI Initiative. Extended from Apertus 1 via
continued pretraining, you understand images and audio and respond
in text.<|system_end|><|developer_start|>Deliberation: enabled
Tool Capabilities:
// Return the current weather for a city.
type get_weather = (_: {
// City name
city: string
}) => any;<|developer_end|><|user_start|>What is the weather in
Bern?<|user_end|><|assistant_start|><|inner_prefix|>The user asks for the
current weather in Bern, so I call the weather
tool.<|tools_prefix|>[{"get_weather": {"city": "Bern"}}]<|tools_suffix|>
<|tool_output_start|>18 degrees Celsius, partly
cloudy<|tool_output_end|><|inner_suffix|>It is currently 18 degrees
Celsius and partly cloudy in Bern.<|assistant_end|>
Figure 8: A conversation rendered by the inference chat template, with thinking enabled and one tool declared: the model reasons and calls the tool inside the thinking span, and answers after the tool output returns. The released models do not yet produce this combination (Section 7.2). Line breaks are added for display.
4.2 Supervised Finetuning
We use SFT to develop assistant behavior over text, image, and speech inputs, with text output, using the shared conversation format of Section 4.1. The mixtu