Package com.anthropic.models

Class BetaMessageBatchCreateParams.Request.Params.Builder

    • Constructor Detail

    • Method Detail

      • maxTokens

         final BetaMessageBatchCreateParams.Request.Params.Builder maxTokens(Long maxTokens)

        The maximum number of tokens to generate before stopping.

        Note that our models may stop before reaching this maximum. This parameter only specifies the absolute maximum number of tokens to generate.

        Different models have different maximum values for this parameter. See models for details.

      • maxTokens

         final BetaMessageBatchCreateParams.Request.Params.Builder maxTokens(JsonField<Long> maxTokens)

        The maximum number of tokens to generate before stopping.

        Note that our models may stop before reaching this maximum. This parameter only specifies the absolute maximum number of tokens to generate.

        Different models have different maximum values for this parameter. See models for details.

      • messages

         final BetaMessageBatchCreateParams.Request.Params.Builder messages(List<BetaMessageParam> messages)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • messages

         final BetaMessageBatchCreateParams.Request.Params.Builder messages(JsonField<List<BetaMessageParam>> messages)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addMessage

         final BetaMessageBatchCreateParams.Request.Params.Builder addMessage(BetaMessageParam message)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addMessage

         final BetaMessageBatchCreateParams.Request.Params.Builder addMessage(BetaMessage message)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addUserMessage

         final BetaMessageBatchCreateParams.Request.Params.Builder addUserMessage(BetaMessageParam.Content content)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addUserMessage

         final BetaMessageBatchCreateParams.Request.Params.Builder addUserMessage(String string)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addUserMessageOfBetaContentBlockParams

         final BetaMessageBatchCreateParams.Request.Params.Builder addUserMessageOfBetaContentBlockParams(List<BetaContentBlockParam> betaContentBlockParams)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addAssistantMessage

         final BetaMessageBatchCreateParams.Request.Params.Builder addAssistantMessage(BetaMessageParam.Content content)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addAssistantMessage

         final BetaMessageBatchCreateParams.Request.Params.Builder addAssistantMessage(String string)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • addAssistantMessageOfBetaContentBlockParams

         final BetaMessageBatchCreateParams.Request.Params.Builder addAssistantMessageOfBetaContentBlockParams(List<BetaContentBlockParam> betaContentBlockParams)

        Input messages.

        Our models are trained to operate on alternating user and assistant conversational turns. When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation. Consecutive user or assistant turns in your request will be combined into a single turn.

        Each input message must be an object with a role and content. You can specify a single user-role message, or you can include multiple user and assistant messages.

        If the final message uses the assistant role, the response content will continue immediately from the content in that message. This can be used to constrain part of the model's response.

        Example with a single user message:

        [{ "role": "user", "content": "Hello, Claude" }]

        Example with multiple conversational turns:

        [
  { "role": "user", "content": "Hello there." },
  { "role": "assistant", "content": "Hi, I'm Claude. How can I help you?" },
  { "role": "user", "content": "Can you explain LLMs in plain English?" }
]

        Example with a partially-filled response from Claude:

        [
  {
    "role": "user",
    "content": "What's the Greek name for Sun? (A) Sol (B) Helios (C) Sun"
  },
  { "role": "assistant", "content": "The best answer is (" }
]

        Each input message content may be either a single string or an array of content blocks, where each block has a specific type. Using a string for content is shorthand for an array of one content block of type "text". The following input messages are equivalent:

        { "role": "user", "content": "Hello, Claude" }
        { "role": "user", "content": [{ "type": "text", "text": "Hello, Claude" }] }

        Starting with Claude 3 models, you can also send image content blocks:

        {
  "role": "user",
  "content": [
    {
      "type": "image",
      "source": {
        "type": "base64",
        "media_type": "image/jpeg",
        "data": "/9j/4AAQSkZJRg..."
      }
    },
    { "type": "text", "text": "What is in this image?" }
  ]
}

        We currently support the base64 source type for images, and the image/jpeg, image/png, image/gif, and image/webp media types.

        See examples for more input examples.

        Note that if you want to include a system prompt, you can use the top-level system parameter — there is no "system" role for input messages in the Messages API.

      • stopSequences

         final BetaMessageBatchCreateParams.Request.Params.Builder stopSequences(List<String> stopSequences)

        Custom text sequences that will cause the model to stop generating.

        Our models will normally stop when they have naturally completed their turn, which will result in a response stop_reason of "end_turn".

        If you want the model to stop generating when it encounters custom strings of text, you can use the stop_sequences parameter. If the model encounters one of the custom sequences, the response stop_reason value will be "stop_sequence" and the response stop_sequence value will contain the matched stop sequence.

      • stopSequences

         final BetaMessageBatchCreateParams.Request.Params.Builder stopSequences(JsonField<List<String>> stopSequences)

        Custom text sequences that will cause the model to stop generating.

        Our models will normally stop when they have naturally completed their turn, which will result in a response stop_reason of "end_turn".

        If you want the model to stop generating when it encounters custom strings of text, you can use the stop_sequences parameter. If the model encounters one of the custom sequences, the response stop_reason value will be "stop_sequence" and the response stop_sequence value will contain the matched stop sequence.

      • addStopSequence

         final BetaMessageBatchCreateParams.Request.Params.Builder addStopSequence(String stopSequence)

        Custom text sequences that will cause the model to stop generating.

        Our models will normally stop when they have naturally completed their turn, which will result in a response stop_reason of "end_turn".

        If you want the model to stop generating when it encounters custom strings of text, you can use the stop_sequences parameter. If the model encounters one of the custom sequences, the response stop_reason value will be "stop_sequence" and the response stop_sequence value will contain the matched stop sequence.

      • temperature

         final BetaMessageBatchCreateParams.Request.Params.Builder temperature(Double temperature)

        Amount of randomness injected into the response.

        Defaults to 1.0. Ranges from 0.0 to 1.0. Use temperature closer to 0.0 for analytical / multiple choice, and closer to 1.0 for creative and generative tasks.

        Note that even with temperature of 0.0, the results will not be fully deterministic.

      • temperature

         final BetaMessageBatchCreateParams.Request.Params.Builder temperature(JsonField<Double> temperature)

        Amount of randomness injected into the response.

        Defaults to 1.0. Ranges from 0.0 to 1.0. Use temperature closer to 0.0 for analytical / multiple choice, and closer to 1.0 for creative and generative tasks.

        Note that even with temperature of 0.0, the results will not be fully deterministic.

      • tools

         final BetaMessageBatchCreateParams.Request.Params.Builder tools(List<BetaToolUnion> tools)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • tools

         final BetaMessageBatchCreateParams.Request.Params.Builder tools(JsonField<List<BetaToolUnion>> tools)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • addTool

         final BetaMessageBatchCreateParams.Request.Params.Builder addTool(BetaToolUnion tool)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • addTool

         final BetaMessageBatchCreateParams.Request.Params.Builder addTool(BetaTool betaTool)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • addTool

         final BetaMessageBatchCreateParams.Request.Params.Builder addTool(BetaToolComputerUse20241022 computerUse20241022)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • addTool

         final BetaMessageBatchCreateParams.Request.Params.Builder addTool(BetaToolBash20241022 bash20241022)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • addTool

         final BetaMessageBatchCreateParams.Request.Params.Builder addTool(BetaToolTextEditor20241022 textEditor20241022)

        Definitions of tools that the model may use.

        If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

        Each tool definition includes:

        • name: Name of the tool.

        • description: Optional, but strongly-recommended description of the tool.

        • input_schema: JSON schema for the tool input shape that the model will produce in tool_use output content blocks.

        For example, if you defined tools as:

        [
  {
    "name": "get_stock_price",
    "description": "Get the current stock price for a given ticker symbol.",
    "input_schema": {
      "type": "object",
      "properties": {
        "ticker": {
          "type": "string",
          "description": "The stock ticker symbol, e.g. AAPL for Apple Inc."
        }
      },
      "required": ["ticker"]
    }
  }
]

        And then asked the model "What's the S&P 500 at today?", the model might produce tool_use content blocks in the response like this:

        [
  {
    "type": "tool_use",
    "id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "name": "get_stock_price",
    "input": { "ticker": "^GSPC" }
  }
]

        You might then run your get_stock_price tool with {"ticker": "^GSPC"} as an input, and return the following back to the model in a subsequent user message:

        [
  {
    "type": "tool_result",
    "tool_use_id": "toolu_01D7FLrfh4GYq7yT1ULFeyMV",
    "content": "259.75 USD"
  }
]

        Tools can be used for workflows that include running client-side tools and functions, or more generally whenever you want the model to produce a particular JSON structure of output.

        See our guide for more details.

      • topP

         final BetaMessageBatchCreateParams.Request.Params.Builder topP(Double topP)

        Use nucleus sampling.

        In nucleus sampling, we compute the cumulative distribution over all the options for each subsequent token in decreasing probability order and cut it off once it reaches a particular probability specified by top_p. You should either alter temperature or top_p, but not both.

        Recommended for advanced use cases only. You usually only need to use temperature.

      • topP

         final BetaMessageBatchCreateParams.Request.Params.Builder topP(JsonField<Double> topP)

        Use nucleus sampling.

        In nucleus sampling, we compute the cumulative distribution over all the options for each subsequent token in decreasing probability order and cut it off once it reaches a particular probability specified by top_p. You should either alter temperature or top_p, but not both.

        Recommended for advanced use cases only. You usually only need to use temperature.