# Anthropic Messages ## OpenAPI Specification ```yaml openapi: 3.0.1 info: title: '' description: '' version: 1.0.0 paths: /v1/messages: post: summary: Anthropic Messages deprecated: false description: > ## Overview The anthropic messages format supports sending a structured list of input messages containing text and/or image content, and the model will generate the next message in the conversation. The Messages API can be used for single queries or stateless multi-turn conversations. This endpoint only supports Claude models. Please view all supported models in [Model List and Pricing](https://api.cometapi.com/pricing). ### Important Notes ⚠️ **Claude Models Only** This endpoint exclusively supports Claude models. For other models (GPT, Gemini, etc.), please use the [Chat Completions](https://apidoc.cometapi.com/chat) endpoint. ⚠️ **Extended Thinking** When using `thinking` parameter, the minimum budget is 1,024 tokens. Extended thinking tokens count towards your `max_tokens` limit. ### Reference Documentation For detailed usage and parameters of this interface, please refer to the [Anthropic Official Documentation](https://docs.anthropic.com/en/api/messages). **Claude API Guides:** - [Prompt Caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching) - Cache prompt prefixes to reduce costs and latency - [Extended Thinking](https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking) - Enable Claude's step-by-step reasoning - [Streaming](https://docs.anthropic.com/en/docs/build-with-claude/streaming) - Stream responses using Server-Sent Events - [Web Fetch Tool](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/web-fetch-tool) - Fetch content from URLs - [Web Search Tool](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/web-search-tool) - Search the web for information tags: - 💬 Text Models parameters: - name: Authorization in: header description: '' required: true example: Bearer {{api-key}} schema: type: string - name: Content-Type in: header description: '' required: true example: application/json schema: type: string - name: anthropic-beta in: header description: '' required: true example: compact-2026-01-12 schema: type: string requestBody: content: application/json: schema: type: object properties: model: type: string description: >- The model that will complete your prompt. See [models](https://docs.claude.com/en/docs/models-overview) for additional details and options. Required string length: `1 - 256` Example: `"claude-sonnet-4-5-20250929"` messages: type: array description: >- 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. 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"`. See [input examples](https://docs.claude.com/en/api/messages-examples). Note that if you want to include a [system prompt](https://docs.claude.com/en/docs/system-prompts), you can use the top-level `system` parameter — there is no `"system"` role for input messages in the Messages API. There is a limit of 100,000 messages in a single request. items: type: string max_tokens: type: integer description: >- 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](https://docs.claude.com/en/docs/models-overview) for details. Required range: `x >= 1` Example: `1024` container: type: object description: |- Container identifier for reuse across requests. Container parameters with skills to be loaded. nullable: true context_management: type: object description: >- Context management configuration. This allows you to control how Claude manages context across multiple requests, such as whether to clear function results or not. x-apidog-orders: [] nullable: true mcp_servers: type: array description: |- MCP servers to be utilized in this request Maximum length: `20` items: type: string metadata: type: object description: An object describing metadata about the request. x-apidog-orders: [] properties: {} service_tier: type: string enum: - auto - standard_only description: >- Determines whether to use priority capacity (if available) or standard capacity for this request. Anthropic offers different levels of service for your API requests. See [service-tiers](https://docs.claude.com/en/api/service-tiers) for details. Available options: `auto`, `standard_only` stop_sequences: type: array items: type: string description: >- 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. stream: type: boolean description: >- Whether to incrementally stream the response using server-sent events. See [streaming](https://docs.claude.com/en/api/messages-streaming) for details. system: type: string description: >- System prompt. A system prompt is a way of providing context and instructions to Claude, such as specifying a particular goal or role. See our [guide to system prompts](https://docs.claude.com/en/docs/system-prompts). Example: ```json [ { "text": "Today's date is 2024-06-01.", "type": "text" } ] ``` Or: `"Today's date is 2023-01-01."` temperature: type: number description: >- 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. Required range: `0 <= x <= 1` Example: `1` thinking: type: object description: >- Configuration for enabling Claude's extended thinking. When enabled, responses include `thinking` content blocks showing Claude's thinking process before the final answer. Requires a minimum budget of 1,024 tokens and counts towards your `max_tokens` limit. See [extended thinking](https://docs.claude.com/en/docs/build-with-claude/extended-thinking) for details. x-apidog-orders: [] properties: {} tool_choice: type: object description: >- How the model should use the provided tools. The model can use a specific tool, any available tool, decide by itself, or not use tools at all. The model will automatically decide whether to use tools. x-apidog-orders: [] properties: {} tools: type: array description: >- 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. There are two types of tools: **client tools** and **server tools**. The behavior described below applies to client tools. For [server tools](https://docs.claude.com/en/docs/agents-and-tools/tool-use/overview#server-tools), see their individual documentation as each has its own behavior (e.g., the [web search tool](https://docs.claude.com/en/docs/agents-and-tools/tool-use/web-search-tool)). Each tool definition includes: - **name**: Name of the tool. - **description**: Optional, but strongly-recommended description of the tool. - **input_schema**: [JSON schema](https://json-schema.org/draft/2020-12) for the tool `input` shape that the model will produce in `tool_use` output content blocks. For example, if you defined `tools` as: ```json [ { "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: ```json [ { "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: ```json [ { "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](https://docs.claude.com/en/docs/tool-use) for more details. Example: ```json { "description": "Get the current weather in a given location", "input_schema": { "properties": { "location": { "description": "The city and state, e.g. San Francisco, CA", "type": "string" }, "unit": { "description": "Unit for the output - one of (celsius, fahrenheit)", "type": "string" } }, "required": ["location"], "type": "object" }, "name": "get_weather" } ``` items: type: string top_k: type: integer description: >- Only sample from the top K options for each subsequent token. Used to remove "long tail" low probability responses. [Learn more technical details here](https://towardsdatascience.com/how-to-sample-from-language-models-682bceb97277). Recommended for advanced use cases only. You usually only need to use `temperature`. Required range: `x >= 0` Example: `5` top_p: type: number description: >- 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`. Required range: `0 <= x <= 1` Example: `0.7` required: - model - messages - max_tokens x-apidog-orders: - model - messages - max_tokens - container - context_management - mcp_servers - metadata - service_tier - stop_sequences - stream - system - temperature - thinking - tool_choice - tools - top_k - top_p examples: '1': value: max_tokens: 1024 system: You are a helpful assistant. messages: - content: Hello, world role: user model: claude-sonnet-4-5-20250929 summary: Default '2': value: model: claude-sonnet-4-5 max_tokens: 1024 system: - type: text text: >- You are an expert software architect and code reviewer. Your role is to analyze code, identify potential issues, suggest improvements, and provide detailed explanations. You must follow these comprehensive guidelines: ## Code Review Principles ### 1. Clean Code Standards - Follow SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) - Ensure proper naming conventions: classes use PascalCase, methods use camelCase, constants use UPPER_SNAKE_CASE - Keep functions small and focused - ideally under 20 lines - Avoid deep nesting - maximum 3 levels of indentation - Use meaningful variable names that describe intent - Remove dead code and commented-out code blocks - Ensure consistent formatting throughout the codebase ### 2. Security Best Practices - Never store sensitive data in plain text - Always validate and sanitize user inputs - Use parameterized queries to prevent SQL injection - Implement proper authentication and authorization checks - Apply the principle of least privilege - Encrypt sensitive data at rest and in transit - Implement rate limiting to prevent abuse - Use secure random number generators for security-sensitive operations - Validate all external data sources - Implement proper error handling without exposing sensitive information ### 3. Performance Optimization - Avoid premature optimization but be aware of obvious performance issues - Use appropriate data structures for the use case - Minimize database queries - use batch operations when possible - Implement caching strategies where appropriate - Avoid memory leaks by properly managing resources - Use lazy loading for expensive operations - Profile code before optimizing - Consider space-time tradeoffs - Use connection pooling for database connections - Implement pagination for large data sets ### 4. Error Handling - Use specific exception types rather than generic exceptions - Never swallow exceptions silently - Log errors with appropriate context and severity levels - Implement graceful degradation - Provide meaningful error messages to users - Use try-with-resources for automatic resource management - Implement circuit breakers for external service calls - Have a consistent error response format for APIs ### 5. Testing Requirements - Write unit tests for all business logic - Aim for at least 80% code coverage - Write integration tests for critical paths - Use meaningful test names that describe the scenario - Follow the Arrange-Act-Assert pattern - Mock external dependencies appropriately - Test edge cases and error scenarios - Keep tests independent and repeatable - Use test fixtures and factories for test data - Write performance tests for critical operations ### 6. Documentation Standards - Document public APIs with clear descriptions - Include examples in documentation - Document complex algorithms and business logic - Keep documentation up to date with code changes - Use self-documenting code when possible - Document assumptions and limitations - Include architecture decision records for significant decisions - Maintain a changelog for version history ### 7. Code Architecture - Follow domain-driven design principles - Implement proper separation of concerns - Use dependency injection for loose coupling - Apply the Repository pattern for data access - Implement the Service layer pattern for business logic - Use DTOs for data transfer between layers - Apply the Factory pattern for object creation - Implement the Observer pattern for event handling - Use the Strategy pattern for algorithm variations - Apply the Decorator pattern for dynamic behavior extension ### 8. API Design - Follow RESTful conventions for HTTP APIs - Use proper HTTP status codes - Implement versioning for APIs - Use consistent naming conventions for endpoints - Implement proper request validation - Use HATEOAS where appropriate - Document APIs with OpenAPI/Swagger - Implement proper rate limiting - Use appropriate content types - Implement pagination and filtering ### 9. Database Design - Normalize data to reduce redundancy - Use appropriate indexes for query optimization - Implement foreign key constraints for data integrity - Use transactions for atomic operations - Implement soft deletes when data history is important - Use database migrations for schema changes - Implement audit trails for sensitive data - Optimize queries with execution plans - Use connection pooling - Implement read replicas for scaling ### 10. DevOps and Deployment - Implement CI/CD pipelines - Use containerization with Docker - Implement infrastructure as code - Use environment-specific configurations - Implement blue-green or canary deployments - Monitor application health and performance - Implement centralized logging - Use secrets management for sensitive configuration - Implement auto-scaling based on load - Have disaster recovery procedures in place ## Code Review Checklist When reviewing code, systematically check for: 1. **Functionality**: Does the code work as intended? 2. **Design**: Is the code well-designed and follows SOLID principles? 3. **Complexity**: Is the code more complex than necessary? 4. **Tests**: Are there appropriate tests with good coverage? 5. **Naming**: Are names clear and descriptive? 6. **Comments**: Are comments necessary, clear, and up to date? 7. **Style**: Does the code follow the style guide? 8. **Documentation**: Is the public API documented? 9. **Security**: Are there any security vulnerabilities? 10. **Performance**: Are there any obvious performance issues? ## Response Format When providing code reviews, structure your response as follows: ### Summary Brief overview of the code and main findings. ### Critical Issues List any bugs, security vulnerabilities, or breaking changes that must be addressed. ### Suggestions List improvements that would enhance code quality but are not critical. ### Questions Any clarifying questions about the implementation. ### Positive Aspects Highlight well-written code or good practices observed. Remember to be constructive, specific, and provide examples when suggesting improvements. # Prompt Caching Test Corpus (Long Context) This appendix is intentionally long and should be preserved verbatim across requests. It provides stable reference material for cache testing and should remain unchanged unless explicitly requested. ## A. Architecture Glossary 1. Bounded Context: a semantic boundary within which a model applies consistently. 2. Aggregate: a cluster of domain objects treated as a unit for data changes. 3. Entity: an object defined by identity rather than attributes. 4. Value Object: an immutable object defined only by its attributes. 5. Repository: a collection-like interface for accessing domain objects. 6. Service Layer: orchestration boundary for business rules. 7. Anti-Corruption Layer: translation boundary between disparate systems. 8. Hexagonal Architecture: ports and adapters isolating domain core. 9. Clean Architecture: layered separation with dependency inversion. 10. CQRS: separation of write and read models. 11. Event Sourcing: persistence via a sequence of immutable events. 12. Saga Pattern: distributed transaction management using compensations. 13. Idempotency: repeated requests produce the same effect. 14. Observability: metrics, logs, and traces for system insight. 15. Backpressure: signaling to slow down producers when consumers are overloaded. 16. Load Shedding: dropping work to keep the system stable. 17. Circuit Breaker: fail-fast guard for unstable dependencies. 18. Bulkhead: isolation to prevent cascading failures. 19. Cache Invalidation: strategy for expiring stale data. 20. Rate Limiting: throttling to protect services. 21. Immutable Data: data that cannot be modified after creation. 22. Deterministic Build: identical inputs produce identical outputs. 23. Feature Flag: runtime switch for enabling features. 24. Blue-Green Deployment: two production environments for safe release. 25. Canary Release: gradual rollout to a subset of users. 26. Multi-Tenant Isolation: ensuring tenants cannot affect each other. 27. Zero Trust: verify explicitly, assume breach. 28. Least Privilege: minimal permissions for tasks. 29. Defense in Depth: layered security controls. 30. Audit Trail: immutable logs for sensitive operations. ## B. Error Taxonomy - ValidationError: input violates schema or rules. - AuthenticationError: identity cannot be verified. - AuthorizationError: insufficient permissions. - ResourceNotFound: requested entity does not exist. - ConflictError: request conflicts with current state. - RateLimitExceeded: too many requests within window. - DependencyTimeout: downstream service timed out. - DependencyUnavailable: downstream service unavailable. - DataIntegrityError: constraint violation or corrupt data. - SerializationError: cannot encode or decode payload. - DeserializationError: cannot decode payload. - BusinessRuleViolation: domain constraint violated. - PaymentDeclined: external payment rejected. - InventoryShortage: insufficient stock. - ConcurrencyError: optimistic locking failed. - ConfigurationError: missing or invalid config. - SecretMissingError: required secret not found. - DiskFullError: storage exhausted. - MemoryPressureError: memory limits exceeded. - UnknownError: unexpected failure. ## C. Security Threat Model (STRIDE Summary) - Spoofing: verify identity using MFA and signed tokens. - Tampering: use integrity checks and signed payloads. - Repudiation: maintain non-repudiation logs with timestamps. - Information Disclosure: enforce encryption and least privilege. - Denial of Service: rate limit and autoscale. - Elevation of Privilege: strict RBAC and audit trails. ## D. Performance Profiling Guide 1. Establish baseline latency and throughput. 2. Identify hot paths with profiler sampling. 3. Separate IO wait from CPU time. 4. Reduce N+1 queries with batching. 5. Cache immutable or infrequently changing data. 6. Avoid large object allocations in tight loops. 7. Use streaming for large payloads. 8. Apply pagination to all collection endpoints. 9. Reduce serialization overhead with compact formats. 10. Precompute expensive derived values if stable. 11. Apply concurrency limits to protect dependencies. 12. Consider data locality and partitioning. 13. Verify GC pauses and tune heap sizes. 14. Add timeouts and retries with jitter. 15. Re-measure after each change. ## E. Code Smells Catalog - Long Method: functions exceeding 20 lines without clear structure. - Large Class: too many responsibilities. - Feature Envy: method uses more of another class than its own. - Data Clump: groups of variables passed together repeatedly. - Primitive Obsession: excessive use of primitive types over value objects. - Shotgun Surgery: one change requires many small edits. - Divergent Change: one class changed for many reasons. - Duplicated Code: identical logic in multiple locations. - Dead Code: unused or unreachable code. - Magic Numbers: unexplained constants. - Inappropriate Intimacy: classes overly dependent on internals. - Refused Bequest: subclass not using base behavior. - Speculative Generality: abstractions without current need. - God Object: one object knows too much or does too much. - Excessive Indirection: too many layers without benefit. - Inconsistent Naming: non-uniform naming scheme. - Deep Nesting: more than three levels. - Temporal Coupling: order-dependent operations hidden in code. - Leaky Abstraction: implementation details exposed. - Mutable State Sprawl: shared state changes without control. - Incomplete Abstraction: missing encapsulation. - Over-logging: noise drowning signals. - Under-logging: missing critical context. - Hidden Side Effects: unexpected mutations. - Implicit Dependencies: relying on globals or ambient state. - Unbounded Collections: in-memory lists without limits. - Poor Error Messages: unclear or missing context. - Silent Failures: swallowed exceptions. - Tight Coupling: hard to replace dependencies. - Unclear Ownership: ambiguous responsibility. ## F. Testing Matrix - Unit: validate pure functions with deterministic inputs. - Integration: verify database, queue, and external API flows. - Contract: ensure API expectations between services. - End-to-End: validate real workflows with real dependencies. - Performance: load, stress, soak, and spike tests. - Security: SAST, DAST, dependency scanning. - Regression: ensure fixed bugs never return. - Accessibility: WCAG checks for UI. - Localization: verify i18n strings and formatting. - Chaos: inject failures to test resilience. ## G. API Review Checklist (Extended) 1. Consistent resource naming using nouns. 2. Use plural collections and singular items. 3. Include pagination metadata (cursor, limit, next). 4. Use standard error format with code and message. 5. Provide deterministic ordering of list responses. 6. Implement idempotency keys for writes. 7. Avoid leaking internal IDs in public APIs when possible. 8. Support filtering and searching with clear syntax. 9. Enforce schema validation on inputs. 10. Provide OpenAPI documentation with examples. 11. Support versioning in URL or header. 12. Return ETags for cache validation. 13. Use 429 for rate limiting with Retry-After. 14. Avoid breaking changes without migration path. 15. Validate file uploads with MIME and size checks. 16. Ensure CORS policy is explicit and minimal. 17. Use consistent date-time formats (ISO 8601). 18. Document all enums and allowed values. 19. Provide stable error codes for clients. 20. Include request IDs in responses. ## H. Data Validation Rules - Required fields must be present and non-empty. - String lengths must be bounded and trimmed. - Numeric fields must have min and max. - Use whitelist validation for enums. - Reject unexpected fields unless explicitly allowed. - Normalize whitespace and Unicode. - Validate email and URL formats using robust parsers. - Validate timestamps for allowed ranges. - Validate money using decimal arithmetic. - Validate lists for size limits. - Validate nested objects recursively. - Reject negative quantities unless business rules allow. ## I. Logging Guidance - Required fields: request_id, user_id, action, status, latency_ms. - Add severity: debug, info, warn, error, critical. - Avoid logging secrets, tokens, or PII. - Use structured JSON logging for parsing. - Correlate logs with trace_id when available. ## J. Reference Snippets (Do Not Execute) Pseudo-usage examples for review only: Example A: - Input: list of items with price and quantity. - Output: total as decimal with 2dp rounding. Example B: - Input: malformed item missing price. - Output: validation error with clear message. Example C: - Input: huge list of items. - Output: linear complexity and streaming safety. ## K. Design Patterns Reference ### Creational Patterns 1. **Singleton**: Ensures a class has only one instance and provides a global point of access to it. Use when exactly one object is needed to coordinate actions across the system. Implementation considerations include thread safety, lazy initialization, and serialization concerns.2. **Factory Method**: Defines an interface for creating an object but lets subclasses decide which class to instantiate. Useful when a class cannot anticipate the class of objects it must create.3. **Abstract Factory**: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Ideal for systems that need to be independent of how products are created.4. **Builder**: Separates the construction of a complex object from its representation, allowing the same construction process to create different representations. Perfect for objects with many optional parameters.5. **Prototype**: Creates new objects by copying an existing object (prototype). Useful when object creation is expensive and similar objects exist.### Structural Patterns1. **Adapter**: Converts the interface of a class into another interface clients expect. Allows classes with incompatible interfaces to work together.2. **Bridge**: Decouples an abstraction from its implementation so that the two can vary independently. Useful when both the abstraction and implementation need to be extended.3. **Composite**: Composes objects into tree structures to represent part-whole hierarchies. Lets clients treat individual objects and compositions uniformly.4. **Decorator**: Attaches additional responsibilities to an object dynamically. Provides a flexible alternative to subclassing for extending functionality.5. **Facade**: Provides a unified interface to a set of interfaces in a subsystem. Defines a higher-level interface that makes the subsystem easier to use.6. **Flyweight**: Uses sharing to support large numbers of fine-grained objects efficiently. Useful when many objects share common state.7. **Proxy**: Provides a surrogate or placeholder for another object to control access to it. Types include virtual proxy, protection proxy, and remote proxy.### Behavioral Patterns1. **Chain of Responsibility**: Avoids coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chains the receiving objects and passes the request along the chain. cache_control: type: ephemeral messages: - role: user content: |- Please review this Python code: ```python def calculate_order_total(items): total = 0 for item in items: total += item['price'] * item['quantity'] return total ``` summary: Prompt Cache '3': value: model: claude-sonnet-4-5 max_tokens: 16000 thinking: type: enabled budget_tokens: 10000 messages: - role: user content: >- Are there an infinite number of prime numbers such that n mod 4 == 3? summary: Thinking Control '4': value: model: claude-opus-4-5-20251101 max_tokens: 4096 messages: - role: user content: >- Analyze the trade-offs between microservices and monolithic architectures output_config: effort: medium summary: Effort '5': value: model: claude-sonnet-4-5 messages: - role: user content: Hello max_tokens: 256 stream: true summary: Streaming Message '6': value: model: claude-sonnet-4-5 max_tokens: 1024 messages: - role: user content: >- Please analyze the content at https://arxiv.org/abs/1512.03385 tools: - type: web_fetch_20250910 name: web_fetch max_uses: 5 summary: Web Fetch responses: '200': description: '' content: application/json: schema: type: object properties: id: type: string description: | Message's unique identifier type: type: string description: | Type of the object role: type: string description: | Role of the message sender content: type: array items: type: object properties: type: type: string description: Type of content block text: type: string description: | Actual text content x-apidog-orders: - type - text description: | Actual text content model: type: string description: > Specific model name and version that generated this response stop_reason: type: string description: | Reason why the model stopped generating content usage: type: object properties: input_tokens: type: integer description: >- Number of tokens input to the model (prompts and historical messages, etc.) output_tokens: type: integer description: >- Number of tokens in the output content generated by the model cache_creation_input_tokens: type: integer description: Number of input tokens used to create the cache cache_read_input_tokens: type: integer description: | Number of input tokens read from the cache required: - input_tokens - output_tokens - cache_creation_input_tokens - cache_read_input_tokens x-apidog-orders: - input_tokens - output_tokens - cache_creation_input_tokens - cache_read_input_tokens description: > Object about API call resource usage, mainly token statistics required: - id - type - role - content - model - stop_reason - usage x-apidog-orders: - id - type - role - content - model - stop_reason - usage example: id: chatcmpl-a1568ee22c7a4f31848f3dc16c2f3 type: message role: assistant content: - type: text text: >- Hello! It's nice to meet you. I'm Claude, an AI assistant. How can I help you today? Feel free to ask me anything you'd like - I'm happy to assist with a wide range of topics and tasks. model: claude-3-5-sonnet-20240620 stop_reason: end_turn stop_sequence: null usage: input_tokens: 3 output_tokens: 52 cache_creation_input_tokens: 0 cache_read_input_tokens: 0 headers: {} x-apidog-name: Successful Response security: [] x-apidog-folder: 💬 Text Models x-apidog-status: released x-run-in-apidog: https://app.apidog.com/web/project/810968/apis/api-23153821-run components: schemas: {} securitySchemes: {} servers: - url: https://api.cometapi.com description: Prod Env security: [] ```