Module anthropic
Summary
The anthropic module implements the Anthropic-specific protocol layer within the network stack, bridging higher-level HTTP and client modules with the Anthropic Messages API. It owns the complete lifecycle of an API interaction: constructing endpoint URLs and headers from environment variables (such as ANTHROPIC_API_KEY), building JSON request bodies (including system prompts, messages, and tool definitions), parsing raw response payloads to extract text, tool arguments, and structured outputs, and validating outgoing requests against protocol constraints. Internal helpers handle the formatting of text blocks, role messages, and tool‑use/tool‑result blocks as required by the Anthropic schema.
The module’s public interface exposes three asynchronous call templates (call_llm_async, call_completion_async, call_structured_async) that drive the full request/response loop on a given kota::event_loop. It also provides schema utilities (function_tool, response_format) for defining tool‑callable functions and structured‑output models, together with protocol‑level parsing functions (parse_response, parse_response_text, parse_tool_arguments, text_from_response) that allow callers to decompose responses into the high‑level structures defined in the protocol module. In addition, the module maintains constants for default parameters (e.g., kDefaultMaxTokens) and environment variable names, ensuring that credential and configuration discovery remains self‑contained.
Imports
Dependency Diagram
Types
clore::net::anthropic::detail::Protocol
Declaration: network/anthropic.cppm:654
Definition: network/anthropic.cppm:654
Declaration: Namespace clore::net::anthropic::detail
The struct clore::net::anthropic::detail::Protocol is a stateless collection of static member functions that encapsulate the Anthropic-specific protocol logic. Internally, it coordinates credential retrieval via read_environment, which reads environment variables using clore::net::detail::read_credentials with predefined environment key names. The build_url function constructs the messages endpoint by calling clore::net::anthropic::protocol::build_messages_url using the api_base from the environment config. Headers are built in build_headers to include Content-Type, the x-api-key from the environment, and a fixed anthropic-version header. The JSON request body is delegated to the corresponding protocol::build_request_json function. Response parsing in parse_response first checks for an empty body (returning a LLMError), then attempts to parse via clore::net::anthropic::protocol::parse_response; if parsing succeeds but the HTTP status is >= 400, an error is returned with the status code; if parsing fails, the raw response error or a formatted HTTP error is returned. The provider_name function returns the string "Anthropic". All member functions are static, meaning Protocol acts as a pure policy type with no instance state; invariants are enforced by the delegation to shared protocol functions and the error‑handling logic in parse_response.
Invariants
- All methods are static and stateless
- Environment config must be valid before calling
build_url,build_headers, orbuild_request_json parse_responseexpects a non-empty body or handles empty body with an error- Provider name is always
"Anthropic"
Key Members
read_environmentbuild_urlbuild_headersbuild_request_jsonparse_responseprovider_name
Usage Patterns
- Used as a policy or adapter for the Anthropic provider in generic request workflows
- Methods are called sequentially:
read_environment, thenbuild_url,build_headers,build_request_json, and finallyparse_response - Likely substituable with other provider-specific
Protocolstructs via template or duck typing
Member Functions
clore::net::anthropic::detail::Protocol::build_headers
Declaration: network/anthropic.cppm:667
Definition: network/anthropic.cppm:667
Declaration: Namespace clore::net::anthropic::detail
Implementation
static auto build_headers(const clore::net::detail::EnvironmentConfig& environment)
-> std::vector<kota::http::header> {
return std::vector<kota::http::header>{
kota::http::header{
.name = "Content-Type",
.value = "application/json; charset=utf-8",
},
kota::http::header{
.name = "x-api-key",
.value = environment.api_key,
},
kota::http::header{
.name = "anthropic-version",
.value = std::string(kAnthropicVersion),
},
};
}clore::net::anthropic::detail::Protocol::build_request_json
Declaration: network/anthropic.cppm:685
Definition: network/anthropic.cppm:685
Declaration: Namespace clore::net::anthropic::detail
Implementation
static auto build_request_json(const CompletionRequest& request)
-> std::expected<std::string, LLMError> {
return clore::net::anthropic::protocol::build_request_json(request);
}clore::net::anthropic::detail::Protocol::build_url
Declaration: network/anthropic.cppm:663
Definition: network/anthropic.cppm:663
Declaration: Namespace clore::net::anthropic::detail
Implementation
static auto build_url(const clore::net::detail::EnvironmentConfig& environment) -> std::string {
return clore::net::anthropic::protocol::build_messages_url(environment.api_base);
}clore::net::anthropic::detail::Protocol::parse_response
Declaration: network/anthropic.cppm:690
Definition: network/anthropic.cppm:690
Declaration: Namespace clore::net::anthropic::detail
Implementation
static auto parse_response(const clore::net::detail::RawHttpResponse& raw_response)
-> std::expected<CompletionResponse, LLMError> {
if(raw_response.body.empty()) {
return std::unexpected(LLMError("empty response from Anthropic"));
}
auto parsed = clore::net::anthropic::protocol::parse_response(raw_response.body);
if(!parsed.has_value()) {
if(raw_response.http_status >= 400) {
return std::unexpected(
LLMError(std::format("Anthropic request failed with HTTP {}: {}",
raw_response.http_status,
raw_response.body)));
}
return std::unexpected(std::move(parsed.error()));
}
if(raw_response.http_status >= 400) {
return std::unexpected(LLMError(
std::format("Anthropic request failed with HTTP {}", raw_response.http_status)));
}
return std::move(*parsed);
}clore::net::anthropic::detail::Protocol::provider_name
Declaration: network/anthropic.cppm:713
Definition: network/anthropic.cppm:713
Declaration: Namespace clore::net::anthropic::detail
Implementation
static auto provider_name() -> std::string_view {
return "Anthropic";
}clore::net::anthropic::detail::Protocol::read_environment
Declaration: network/anthropic.cppm:655
Definition: network/anthropic.cppm:655
Declaration: Namespace clore::net::anthropic::detail
Implementation
static auto read_environment()
-> std::expected<clore::net::detail::EnvironmentConfig, LLMError> {
return clore::net::detail::read_credentials(clore::net::detail::CredentialEnv{
.base_url_env = kAnthropicBaseUrlEnv,
.api_key_env = kAnthropicApiKeyEnv,
});
}Variables
clore::net::anthropic::detail::kAnthropicApiKeyEnv
Declaration: network/anthropic.cppm:651
Declaration: Namespace clore::net::anthropic::detail
This constant is used to look up the Anthropic API key from the process environment, typically by being passed to functions that read environment variables. It is part of the configuration logic alongside similar constants like kAnthropicBaseUrlEnv.
Mutation
No mutation is evident from the extracted code.
Usage Patterns
- used as environment variable name to retrieve Anthropic API key
clore::net::anthropic::detail::kAnthropicBaseUrlEnv
Declaration: network/anthropic.cppm:650
Declaration: Namespace clore::net::anthropic::detail
This variable is intended to be used as the key to read the base URL from the environment during initialization of the Anthropic client. It is declared constexpr and is not mutated.
Mutation
No mutation is evident from the extracted code.
clore::net::anthropic::detail::kAnthropicVersion
Declaration: network/anthropic.cppm:652
Declaration: Namespace clore::net::anthropic::detail
This variable serves as a version identifier for the Anthropic API. It is defined as a compile-time constant and is not modified after initialization. Its value is used to indicate the API version in requests.
Mutation
No mutation is evident from the extracted code.
clore::net::anthropic::protocol::detail::kDefaultMaxTokens
Declaration: network/anthropic.cppm:23
Declaration: Namespace clore::net::anthropic::protocol::detail
Serves as the default maximum number of tokens for requests in the Anthropic protocol. It is referenced in build_request_json to provide a fallback value when no explicit limit is specified.
Mutation
No mutation is evident from the extracted code.
Usage Patterns
- used as default argument in
build_request_json
Functions
clore::net::anthropic::call_completion_async
Declaration: network/anthropic.cppm:722
Definition: network/anthropic.cppm:764
Declaration: Namespace clore::net::anthropic
This function is a coroutine that delegates to the generic clore::net::call_completion_async template parameterized with clore::net::anthropic::detail::Protocol. It moves the provided CompletionRequest and passes a pointer to the kota::event_loop, then unwraps the result via or_fail() to yield a kota::task<CompletionResponse, LLMError>. The internal control flow depends entirely on the generic call_completion_async, which uses the Protocol type to read environment variables (via Protocol::read_environment), build HTTP headers and URL (using Protocol::build_headers and Protocol::build_url), construct the JSON request body (through Protocol::build_request_json), perform the async HTTP call, and parse the response (via Protocol::parse_response). All Anthropic-specific logic — such as message formatting, tool handling, schema instruction generation, and response parsing — is encapsulated within the Protocol class and its associated functions in clore::net::anthropic::detail and clore::net::anthropic::protocol. This wrapper thus provides a clean, type‑specific entry point without exposing the generic infrastructure.
Side Effects
- Initiates an asynchronous network request to the Anthropic API via the underlying
clore::net::call_completion_asyncspecialization. - Moves from the
requestparameter.
Reads From
request: theCompletionRequestobject (moved)loop: reference to the event loop
Usage Patterns
- Used to start an async completion call and obtain a task that can be awaited.
- Typically called from event-loop-driven code that needs to query an AI model.
clore::net::anthropic::call_llm_async
Declaration: network/anthropic.cppm:732
Definition: network/anthropic.cppm:782
Declaration: Namespace clore::net::anthropic
The implementation of clore::net::anthropic::call_llm_async is a thin coroutine adapter that delegates the core request lifecycle to the generic clore::net::call_llm_async template, instantiated with detail::Protocol. Inside, it forwards the model, system_prompt, prompt, and a pointer to the provided kota::event_loop reference, then applies .or_fail() on the returned kota::task to convert any error into the LLMError domain. This design keeps the Anthropic-specific glue (protocol encoding, header construction, URL building, and response parsing) entirely within detail::Protocol, while call_llm_async itself remains stateless and acts as the entry point for high-level LLM completion calls that expect a plain text response.
Side Effects
- Initiates an asynchronous HTTP request to an LLM API via the underlying
clore::net::call_llm_asyncfunction.
Reads From
- model
system_prompt- prompt
- loop
detail::Protocol(compile-time parameter)
Writes To
- The returned
kota::task<std::string, LLMError>object that will eventually contain the response or error.
Usage Patterns
- Await the returned task to obtain the LLM response.
- Call from an async context with an active
kota::event_loop.
clore::net::anthropic::call_llm_async
Declaration: network/anthropic.cppm:726
Definition: network/anthropic.cppm:771
Declaration: Namespace clore::net::anthropic
The implementation of clore::net::anthropic::call_llm_async acts as a thin, protocol‑specific adapter that delegates all core logic to the generic asynchronous LLM invocation template clore::net::call_llm_async<clore::net::anthropic::detail::Protocol>. Inside the coroutine, it passes the provided model and system_prompt strings, moves the PromptRequest object, and supplies the event loop pointer. The generic template handles the construction of HTTP headers, request body, and URL using the Protocol type’s methods (such as build_headers, build_request_json, and build_url), performs the asynchronous network call, and parses the response via Protocol::parse_response. The result of or_fail() unwraps the kota::task into a std::string on success or a LLMError on failure, which is then returned to the caller via co_return co_await. The only dependencies are the detail::Protocol struct (which encapsulates Anthropic‑specific API details like environment variable reads and JSON schema construction) and the generic clore::net::call_llm_async infrastructure.
Side Effects
- Performs asynchronous network I/O via the underlying HTTP client.
- Moves the
requestargument, transferring ownership.
Reads From
- model parameter
system_promptparameter- request parameter
- loop parameter
Writes To
- Initiates a network request that writes data to the network.
- Returns a
kota::taskobject that will be populated with the result.
Usage Patterns
- Called by other async functions to obtain an LLM response.
- Used with
kota::event_loopfor asynchronous execution.
clore::net::anthropic::call_structured_async
Declaration: network/anthropic.cppm:739
Definition: network/anthropic.cppm:794
Declaration: Namespace clore::net::anthropic
The implementation delegates to the generic clore::net::call_structured_async template, passing clore::net::anthropic::detail::Protocol as the protocol type and the supplied model, system_prompt, prompt, and a pointer to the kota::event_loop. The result of the coroutine is then unwrapped by calling .or_fail(), which converts the expected kota::task<T, LLMError> into a kota::task<T, LLMError> that will rethrow or return the error. This single‑step orchestration relies on detail::Protocol to provide all Anthropic‑specific request building (URL, headers, request JSON, schema instruction formatting) and response parsing (text extraction, tool call detection, argument parsing) that the generic call_structured_async uses internally to complete the structured output flow.
Side Effects
- Performs network I/O to Anthropic API
- Allocates coroutine frame and task objects
- Suspends and resumes coroutine execution
- May propagate
LLMErroron failure
Reads From
modelsystem_promptpromptloop
Writes To
- Returns a
kota::task<T, LLMError>object representing the asynchronous result
Usage Patterns
- Called to perform structured async LLM interactions with Anthropic
- Acts as a type-safe wrapper binding
detail::Protocol - Used in coroutine contexts where
co_awaitis applied
clore::net::anthropic::protocol::append_tool_outputs
Declaration: network/anthropic.cppm:209
Definition: network/anthropic.cppm:628
Declaration: Namespace clore::net::anthropic::protocol
The implementation of clore::net::anthropic::protocol::append_tool_outputs is a thin delegation wrapper. It receives three parameters: a span of history messages, a CompletionResponse object, and a span of ToolOutput entries. The function immediately forwards these arguments to the generic clore::net::protocol::append_tool_outputs function, which performs the actual work of appending tool outputs into the message history. No additional validation, transformation, or Anthropic‑specific logic is added at this level; the function exists solely to provide a convenience entry point within the clore::net::anthropic::protocol namespace that matches the public interface contract for that module.
The internal control flow consists only of a single call to the shared generic protocol function. Dependencies are limited to the types Message, CompletionResponse, and ToolOutput (all defined elsewhere), and the target function from the clore::net::protocol namespace. The actual algorithm for constructing a tool‑result message block and inserting it into the history list is implemented in that generic routine, which this wrapper invokes unchanged.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
historyresponseoutputs
Writes To
- return value of type
std::expected<std::vector<Message>, LLMError>
Usage Patterns
- Appending tool outputs to a conversation history
- Converting a completion response and tool outputs into an updated message list
clore::net::anthropic::protocol::build_messages_url
Declaration: network/anthropic.cppm:201
Definition: network/anthropic.cppm:224
Declaration: Namespace clore::net::anthropic::protocol
Implementation: Implementation
The function first normalizes the input api_base by removing any trailing forward slash characters. It then checks whether the resulting string already ends with the path segment /v1. If it does, the function delegates to clore::net::detail::append_url_path to directly append "messages" to the base URL. Otherwise, it appends the full path "v1/messages" using the same utility, ensuring the final URL correctly points to the Anthropic Messages API endpoint. The algorithm relies on clore::net::detail::append_url_path to handle path concatenation, which manages proper slash insertion between path components.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
api_baseparameter
Writes To
- returned
std::string
Usage Patterns
- Called by
clore::net::anthropic::detail::Protocol::build_url
clore::net::anthropic::protocol::build_request_json
Declaration: network/anthropic.cppm:203
Definition: network/anthropic.cppm:235
Declaration: Namespace clore::net::anthropic::protocol
The function first validates a CompletionRequest via detail::validate_request. It then constructs a JSON root object, inserting model and max_tokens (using detail::kDefaultMaxTokens). Messages are iterated: inside a std::visit, each message type is handled separately. SystemMessage content is accumulated into a string system_text via detail::append_text_with_gap. For UserMessage and AssistantMessage, detail::make_role_message produces a role‑labeled JSON object; AssistantToolCallMessage builds a content array combining a text block (detail::make_text_block) and tool‑use blocks (detail::make_tool_use_block). The default case handles tool‑result messages by calling detail::make_tool_result_block and wrapping it in a user‑role object. Non‑system messages that yield valid objects are appended to the messages array. After messages, an optional response_format trigger a call to detail::format_schema_instruction whose result is appended to system_text; if system_text is non‑empty it is inserted as a "system" field. The messages array is then inserted. Tools are serialized into a "tools" array, each containing name, description, and a cloned input_schema from the tool’s parameters. For tool_choice and parallel tool control, a nested object is built using a second std::visit over ToolChoiceAuto, ToolChoiceRequired, ToolChoiceNone, and a named tool variant; if parallel_tool_calls is explicitly false, disable_parallel_tool_use is added. Finally the root JSON object is serialized via kota::codec::json::to_string and returned as a std::string. The function depends on several internal detail helpers (detail::validate_request, detail::append_text_with_gap, detail::make_role_message, detail::make_text_block, detail::make_tool_use_block, detail::make_tool_result_block, detail::format_schema_instruction) and on clore::net::detail utilities for JSON object/array construction and field insertion.
Side Effects
- Allocates JSON objects and strings via container operations
- Returns ownership of a newly allocated
std::string
Reads From
- Parameter
requestof typeCompletionRequest - Constant
detail::kDefaultMaxTokens - Helper functions from
clore::net::detailandclore::net::anthropic::protocol::detail
Writes To
- Local JSON objects (
root,messages,system_text, etc.) - Returned
std::stringcontaining the serialized JSON
Usage Patterns
- Called to generate the request body for an Anthropic API call
clore::net::anthropic::protocol::detail::append_text_with_gap
Declaration: network/anthropic.cppm:25
Definition: network/anthropic.cppm:25
Declaration: Namespace clore::net::anthropic::protocol::detail
Implementation: Implementation
The function checks whether text is empty and exits immediately if so, avoiding unnecessary work. When text is non‑empty, it inspects target: if target already contains some content, a double newline ("\n\n") separator is appended first, ensuring the new text is visually separated from any prior text. Finally, the content of text is appended to target. No external dependencies beyond the standard library’s std::string and std::string_view are required; the control flow is a straightforward linear sequence with a single conditional branch for the gap insertion.
Side Effects
- Modifies target string by appending text and optionally a gap
Reads From
- Parameter
target(to check emptiness) - Parameter
text(to read content)
Writes To
- Parameter
target(modified in place)
Usage Patterns
- Used in
build_request_jsonto assemble text blocks with gaps
clore::net::anthropic::protocol::detail::format_schema_instruction
Declaration: network/anthropic.cppm:176
Definition: network/anthropic.cppm:176
Declaration: Namespace clore::net::anthropic::protocol::detail
The implementation of clore::net::anthropic::protocol::detail::format_schema_instruction begins by testing whether the provided ResponseFormat object contains an optional schema. When format.schema is absent, the function immediately returns a fixed instruction string that requests a plain JSON object without markdown fences. If a schema is present, the function serializes it to a string using json::to_string. This serialization is fallible; upon failure the function delegates error reporting to clore::net::detail::unexpected_json_error and returns an std::expected containing an LLMError. On success, it constructs the final instruction via std::format, embedding the schema’s name and its JSON representation, appending the same warning about markdown fences. The logic is thus a straightforward linear chain: optionality check, serialization attempt, and formatted string construction.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
- The
ResponseFormatparameterformat(specificallyformat.schemaandformat.name) - The
std::expectedreturned byjson::to_string
Usage Patterns
- Generates instruction string for structured output in Anthropic API requests
- Called when constructing messages that require a JSON schema response format
clore::net::anthropic::protocol::detail::make_role_message
Declaration: network/anthropic.cppm:154
Definition: network/anthropic.cppm:154
Declaration: Namespace clore::net::anthropic::protocol::detail
The function clore::net::anthropic::protocol::detail::make_role_message constructs a JSON object representing a single chat message for the Anthropic protocol. It first creates an empty object using clore::net::detail::make_empty_object, attaching a descriptive error message for failure cases. If that step fails, the error is propagated immediately. Otherwise, it inserts the "role" field via clore::net::detail::insert_string_field, checking the result for errors. After both fields are set, the provided content array (a json::Array) is moved into the object with message->insert("content", std::move(blocks)). The completed json::Object is returned on success, or a LLMError on any intermediate failure.
The control flow is a linear sequence of dependency‑based operations: object creation, field insertion (with error handling), and unconditional array insertion. The function relies on the utility helpers clore::net::detail::make_empty_object and clore::net::detail::insert_string_field for low‑level JSON manipulation and error reporting. This function is a building block used by higher‑level protocol assembly routines, such as build_request_json.
Side Effects
- Allocates a new
json::Object - Moves the input
blocksarray into the returned object
Reads From
roleparameterblocksparameter
Writes To
- Returned
json::Object - Local variable
message
Usage Patterns
- Used to construct role-based message objects for the Anthropic protocol
- Called when building a request message with a role and content blocks
clore::net::anthropic::protocol::detail::make_role_message
Declaration: network/anthropic.cppm:130
Definition: network/anthropic.cppm:130
Declaration: Namespace clore::net::anthropic::protocol::detail
The function begins by delegating to clore::net::detail::make_empty_object to allocate a new JSON object, propagating any failure immediately as an unexpected LLMError. It then uses clore::net::detail::insert_string_field to add the "role" key, using the role parameter directly; again, a failed insertion short‑circuits the call. For the "content" key, the function first normalizes the input text via clore::net::detail::normalize_utf8, ensuring valid UTF‑8 encoding before embedding the string. The normalized string is then inserted with the same error‑handling pattern. On successful completion, the fully constructed JSON object is returned.
All JSON manipulation dependencies are drawn from clore::net::detail, and the function’s own helpers live in the clore::net::anthropic::protocol::detail namespace. The algorithm is a straightforward sequence of guarded operations, where every step that can fail returns a std::expected and the function unwraps or forwards each error immediately.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
- role parameter
- text parameter
Writes To
- returns a newly constructed
json::Objectwith role and content fields set
Usage Patterns
- called to create a role message object for Anthropic protocol messages
clore::net::anthropic::protocol::detail::make_text_block
Declaration: network/anthropic.cppm:35
Definition: network/anthropic.cppm:35
Declaration: Namespace clore::net::anthropic::protocol::detail
The function clore::net::anthropic::protocol::detail::make_text_block constructs a JSON object representing a text content block for the Anthropic API. It begins by calling clore::net::detail::make_empty_object to allocate a fresh json::Object, propagating any failure as a std::unexpected error. On success, it inserts the literal string "text" into the "type" field via clore::net::detail::insert_string_field, again forwarding errors immediately. The supplied input text is then normalized using clore::net::detail::normalize_utf8 to ensure well‑formed UTF‑8, and the normalized result is stored in the "text" field. If any insertion step fails, the function returns an LLMError wrapped in std::unexpected; otherwise it returns the completed json::Object block. The entire operation follows an early‑return pattern on error, relying on the helper utilities make_empty_object, insert_string_field, and normalize_utf8 from the clore::net::detail namespace.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
textparameter (std::string_view)
Usage Patterns
- Constructing a text content block for an Anthropic API message array
clore::net::anthropic::protocol::detail::make_tool_result_block
Declaration: network/anthropic.cppm:98
Definition: network/anthropic.cppm:98
Declaration: Namespace clore::net::anthropic::protocol::detail
The function constructs a JSON object representing a tool result block by first creating an empty object via clore::net::detail::make_empty_object; if that call fails, it immediately returns the propagated error. It then inserts three fields sequentially using clore::net::detail::insert_string_field: the literal "type" set to "tool_result", the "tool_use_id" from the input message.tool_call_id, and a "content" field. For the content, it normalizes message.content as UTF-8 via clore::net::detail::normalize_utf8 before insertion. Each insertion step is guarded by an if that checks the returned std::expected; if any insertion fails, the function returns the corresponding LLMError early. On success, the fully populated JSON object is returned.
Internally, the function relies entirely on the utility layer in clore::net::detail for JSON construction (make_empty_object, insert_string_field) and text normalization (normalize_utf8). It does not perform any looping or branching beyond the three successive error checks, making its control flow a linear chain of fallible steps with early exit on the first error.
Side Effects
- Allocates a
json::Objectand may allocate a normalized UTF-8 string for the content field. - Returns a
json::Objectby value, transferring ownership of the allocated object.
Reads From
- The
messageparameter of typeconst ToolResultMessage&: specificallymessage.tool_call_idandmessage.content. - The result of
clore::net::detail::normalize_utf8(message.content, ...).
Writes To
- The temporary
json::Objectblockviaclore::net::detail::insert_string_fieldcalls (modifies the object in place). - The return value of type
std::expected<json::Object, LLMError>(by move or unexpected error).
Usage Patterns
- Used when constructing a tool result message to be sent to the Anthropic API.
- Expected to be called from higher-level protocol message building functions.
clore::net::anthropic::protocol::detail::make_tool_use_block
Declaration: network/anthropic.cppm:58
Definition: network/anthropic.cppm:58
Declaration: Namespace clore::net::anthropic::protocol::detail
The function constructs a JSON object representing a tool use block for the Anthropic protocol. It first validates that the incoming tool call’s arguments member is a JSON object; if not, it returns an LLMError describing the invalid input. The function then creates an empty JSON object via clore::net::detail::make_empty_object, propagates any error upward, and sequentially inserts three string fields – "type" set to "tool_use", "id" from call.id, and "name" from call.name – using clore::net::detail::insert_string_field. Each insertion is checked for failure and the error is forwarded if it occurs. Finally, the tool call’s arguments object is cloned via clore::net::detail::clone_value and inserted under the key "input". The completed JSON object is returned on success, or a std::unexpected error is propagated at the first failure point.
Side Effects
- allocates a
json::Object - clones a
json::Value - inserts fields into the JSON object
Reads From
call.argumentscall.idcall.name
Writes To
- local
json::Objectblock - returned
json::Object
Usage Patterns
- used to create a
tool_useblock for Anthropic protocol requests
clore::net::anthropic::protocol::detail::parse_json_text
Declaration: network/anthropic.cppm:171
Definition: network/anthropic.cppm:171
Declaration: Namespace clore::net::anthropic::protocol::detail
The implementation of parse_json_text is a thin delegation wrapper. It forwards both the raw JSON string (raw) and a contextual description (context) directly to clore::net::detail::parse_json_object, which performs the actual parsing of a JSON object. The function solely relies on that lower‑level parser; it has no additional validation, error transformation, or control flow of its own. The return type std::expected<json::Object, LLMError> is inherited from the underlying call, enabling callers to handle parse failures via the expected interface.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
rawcontext
Usage Patterns
- Used internally to parse JSON text in Anthropic protocol implementation
clore::net::anthropic::protocol::detail::validate_request
Declaration: network/anthropic.cppm:193
Definition: network/anthropic.cppm:193
Declaration: Namespace clore::net::anthropic::protocol::detail
The implementation of clore::net::anthropic::protocol::detail::validate_request is a thin wrapper that immediately delegates all validation logic to clore::net::detail::validate_completion_request. The call passes the request argument along with two boolean flags—both set to false—which likely control whether certain validation passes (such as tool‑use or streaming constraints) are applied. This design centralises common request validation in the clore::net::detail namespace, allowing the Anthropic‑specific layer to reuse the same checks while disabling any protocol‑dependent features that are not relevant for the Anthropic completion path. No additional branching, error handling, or data transformation occurs within the function itself; the entire internal control flow is inherited from the shared validator.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
requestparameter- fields of
CompletionRequest(accessed via callee)
Usage Patterns
- Called before sending a completion request to Anthropic API
- Used in request construction and validation pipelines
clore::net::anthropic::protocol::parse_response
Declaration: network/anthropic.cppm:205
Definition: network/anthropic.cppm:460
Declaration: Namespace clore::net::anthropic::protocol
The function first parses the raw JSON into a json::Value using detail::parse_json_text and wraps the result in a clore::net::detail::ObjectView for structured field access. If the payload contains an "error" object, the function extracts the "message" field and returns an LLMError. Next, it validates mandatory top-level fields: "id" and "model" are required as strings, and "stop_reason" defaults to "end_turn" but is validated when present; a "max_tokens" stop reason causes an early error return. The "content" array is then iterated block by block. For each "text" block, the text content is appended to either refusal (if stop_reason == "refusal") or text; "tool_use" blocks require "id", "name", and "input" – the input is cloned via clore::net::detail::clone_object, serialized to a JSON string using kota::codec::json::to_string, and then parsed back into a kota::codec::json::Value to produce a ToolCall inside output.tool_calls. After processing all blocks, non‑empty text or refusal are assigned to the AssistantOutput, and a CompletionResponse is constructed containing id, model, the assembled message, and the raw JSON string.
Side Effects
- Allocates memory for strings and vectors in the returned
CompletionResponse - Allocates memory for error messages in
LLMError - Moves ownership of parsed JSON values and strings
Reads From
- Input parameter
json_text(astd::string_view)
Writes To
- Return value of type
std::expected<CompletionResponse, LLMError>
Usage Patterns
- Called to deserialize an Anthropic API response string into a structured object
- Used in error handling to detect API errors or truncation
- Consumed by higher-level protocol functions that need a
CompletionResponse
clore::net::anthropic::protocol::parse_response_text
Declaration: network/anthropic.cppm:215
Definition: network/anthropic.cppm:636
Declaration: Namespace clore::net::anthropic::protocol
The implementation of clore::net::anthropic::protocol::parse_response_text is a thin delegation wrapper. The internal control flow consists solely of forwarding the incoming CompletionResponse parameter to the generic base function clore::net::protocol::parse_response_text<T>, which performs the actual parsing. No Anthropic-specific logic or error handling is introduced at this level; the function relies entirely on the base protocol layer to extract and convert the response’s text content into the requested type T. Its primary dependency is the template function clore::net::protocol::parse_response_text, which must be instantiated with the same type T to satisfy the std::expected<T, LLMError> return. This design centralises parsing in the shared protocol module and avoids duplicating logic across provider‑specific implementations.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
- response parameter of type
const CompletionResponse&
Usage Patterns
- Called when parsing a text response from the Anthropic API
- Used to convert raw API response to a typed
expectedresult
clore::net::anthropic::protocol::parse_tool_arguments
Declaration: network/anthropic.cppm:218
Definition: network/anthropic.cppm:641
Declaration: Namespace clore::net::anthropic::protocol
The implementation of clore::net::anthropic::protocol::parse_tool_arguments is a thin forwarding function that delegates immediately to clore::net::protocol::parse_tool_arguments<T>, passing the received call parameter of type ToolCall. No additional Anthropic‑specific logic or transformation is applied at this level. The algorithm consists solely of calling the generic protocol‑level function and returning its std::expected<T, LLMError> result. Control flow is linear: argument reception, single delegation, return. The only external dependency is the common protocol layer function clore::net::protocol::parse_tool_arguments, which contains the actual JSON parsing and schema‑driven extraction logic (e.g., using detail::parse_json_text and related helpers). The template parameter T is inferred from the caller and dictates the expected output type.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
callparameter (const ToolCall&)
Usage Patterns
- Used to deserialize tool call arguments into a strongly typed object
clore::net::anthropic::protocol::text_from_response
Declaration: network/anthropic.cppm:207
Definition: network/anthropic.cppm:623
Declaration: Namespace clore::net::anthropic::protocol
The function clore::net::anthropic::protocol::text_from_response simply delegates to clore::net::protocol::text_from_response with the given response. It acts as a thin adapter within the Anthropic protocol layer, forwarding the response object to the generic protocol helper. No additional parsing, transformation, or branching occurs inside this function; all extraction logic resides in the called routine.
Internally, the function’s control flow is a single call expression, with the return value passed directly back to the caller. The only dependency is the generic clore::net::protocol::text_from_response function, which is expected to handle the concrete message structure of Anthropic responses. Any error handling or text extraction is performed by that underlying implementation, not within this wrapper.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
- the
responseparameter of typeCompletionResponse
Usage Patterns
- Used to retrieve the textual content from a
CompletionResponse.
clore::net::anthropic::schema::function_tool
Declaration: network/anthropic.cppm:755
Definition: network/anthropic.cppm:755
Declaration: Namespace clore::net::anthropic::schema
The implementation of clore::net::anthropic::schema::function_tool is a thin forwarding wrapper. It receives name and description as std::string values, moves them into clore::net::schema::function_tool<T>, and returns the std::expected result directly. No additional validation, transformation, or branching occurs within this function; all logic is delegated to the generic schema layer. The only dependency is the template function clore::net::schema::function_tool<T>, which must be defined elsewhere in the codebase. This design keeps the Anthropic-specific entry point consistent with the common schema interface, allowing tool definitions to be constructed through a single code path.
Side Effects
No observable side effects are evident from the extracted code.
Reads From
nameparameterdescriptionparameter
Usage Patterns
- Used to construct a
FunctionToolDefinitionfor a specific typeT - Called with name and description strings to create a tool definition for the Anthropic API
clore::net::anthropic::schema::response_format
Declaration: network/anthropic.cppm:750
Definition: network/anthropic.cppm:750
Declaration: Namespace clore::net::anthropic::schema
The implementation of clore::net::anthropic::schema::response_format is a thin forwarding layer that delegates to the generic template function clore::net::schema::response_format<T>(). It performs no additional validation, transformation, or intermediate processing; the function simply returns the result of that underlying call. The internal control flow consists of a single return statement wrapping the dependent invocation. The primary dependency is on the clore::net::schema module, which provides the actual algorithm for computing the response format. No branching, loops, or side effects occur within this function.
Side Effects
No observable side effects are evident from the extracted code.
Usage Patterns
- Obtain a response format for the specified type T in the Anthropic context
Internal Structure
The anthropic module is decomposed into several internal namespaces that separate protocol-level message construction (clore::net::anthropic::protocol) from provider-specific configuration and networking logic (clore::net::anthropic::detail). The protocol namespace contains public functions for building and parsing Anthropic API payloads (e.g., build_request_json, parse_response, text_from_response), while its detail sub‑namespace exposes low‑level helpers (e.g., make_text_block, make_role_message, validate_request) used by the higher‑level routines. The detail namespace at module level houses the Protocol struct, which encapsulates environment‑based API key and base‑URL discovery, URL construction, header assembly, and response parsing, providing a single provider‑specific implementation for the generic HTTP and async layers.
The module imports client, http, protocol, provider, schema, and support as its main dependencies, indicating that it builds on top of generic LLM types and transport abstractions to realise Anthropic‑specific serialization, endpoint management, and schema generation (e.g., function_tool and response_format in the schema namespace). The public async call interfaces (call_llm_async, call_completion_async, call_structured_async) rely on the Protocol struct for configuration and on the http module for actual network dispatch, while the internal helpers handle the fine‑grained construction of message blocks, tool‑call containers, and response text extraction.