Anthropic Metrics
| Version | 0.1.0
|
| Subscription level What's this? |
Basic |
| Developed by What's this? |
Elastic |
| Ingestion method(s) | API |
| Minimum Kibana version(s) | 9.4.0 |
The Anthropic Metrics integration v0.1.0 is in technical preview
To use pre-release integrations, go to the Integrations page in Kibana, scroll down, and toggle on the Display beta integrations option.
The Anthropic Metrics integration collects API usage, cost, and rate limit data from Anthropic organizations via the Admin APIs. It enables observability and monitoring teams to track token consumption, monitor spend, and surface rate limit configurations for capacity planning.
This integration uses the Anthropic Platform Admin API (platform.claude.com) to collect workspace- and API-key-level cost, usage, and rate limit data. It requires an Anthropic organization on a Team or Enterprise plan with access to the Admin API. Individual accounts (Free, Pro, Max) cannot create the required Admin API keys and are not supported.
Enterprise plan customers can use this integration for workspace- and API-key-level data.
For per-user or per-product breakdowns (Chat, Claude Code, Cowork, etc.), the separate Enterprise Analytics API (claude.ai/analytics/api-keys) is required — that API is currently not covered by this integration.
Elastic Agent polls three Anthropic Admin API endpoints on a configurable schedule using the CEL input:
- Usage API (
/v1/organizations/usage_report/messages): Token consumption by model, workspace, and service tier - Cost API (
/v1/organizations/cost_report): Daily cost breakdown by workspace and model - Rate Limits API (
/v1/organizations/rate_limits): Per-model rate limit configurations (RPM, ITPM, OTPM)
Token usage metrics aggregated in configurable time buckets (1 minute, 1 hour, or 1 day):
- Uncached input tokens, cached input tokens, cache creation tokens, and output tokens
- Breakdowns by model, workspace, service tier, context window, and inference geography
Daily cost data (amounts reported by the API in lowest units (eg cents)):
- Token usage costs, web search costs, and code execution costs
- Breakdowns by workspace and description (includes model and inference geography)
Rate limit configuration snapshots:
- Requests per minute (RPM), input tokens per minute (ITPM), output tokens per minute (OTPM)
- Model group membership and batch request limits
- Token usage monitoring: Track consumption trends across models and workspaces
- Cost management: Monitor daily spend and allocate costs by workspace
- Capacity planning: Compare rate limits against actual consumption to prevent throttling
- Finance reporting: Export usage and cost data for billing reconciliation
- An Anthropic organization (Team or Enterprise) with Platform Admin API access
- An Admin API key (starts with
sk-ant-admin...) provisioned by an organization admin via Claude Console > Settings > Admin keys. - Elastic Agent installed on a host with outbound HTTPS access to
api.anthropic.com
Agentless integrations allow you to collect data without having to manage Elastic Agent in your cloud. They make manual agent deployment unnecessary, so you can focus on your data instead of the agent that collects it. For more information, refer to Agentless integrations and the Agentless integrations FAQ.
Agentless deployments are only supported in Elastic Serverless and Elastic Cloud environments. This functionality is in beta and is subject to change. Beta features are not subject to the support SLA of official GA features.
Elastic Agent must be installed. For more details, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host.
Elastic Agent polls the Anthropic Admin APIs and ships collected events to Elasticsearch, where they are processed by the integration's ingest pipelines.
- Create an Admin API key in the Claude Console with organization admin permissions.
- In Kibana, navigate to Management > Integrations and search for Anthropic Metrics.
- Click Add Anthropic Metrics and enter the Admin API key.
- Configure each data stream using the settings below, then deploy the policy to your Elastic Agent.
Usage data stream settings
| Setting | Default | Description |
|---|---|---|
| Interval | 5m |
How often the Usage API is polled. |
| Initial Interval | 24h |
Lookback window on the first collection run. Must fit within Anthropic's granularity limits. |
| Bucket Width | 1h |
Time granularity for usage buckets. One of 1m, 1h, or 1d. Use 1m for real-time alerting, 1h for operational monitoring, or 1d for finance reporting. |
| Group By | model, workspace_id, service_tier, inference_geo |
Dimensions to break down usage data. Additional options: api_key_id, context_window, speed. |
Cost data stream settings
| Setting | Default | Description |
|---|---|---|
| Interval | 1h |
How often the Cost API is polled. The API only returns daily buckets, so polling more frequently than 1h adds no value. |
| Initial Interval | 168h (7 days) |
Lookback window on the first collection run. |
| Group By | workspace_id, description |
Dimensions to break down cost data. When description is included, the API returns structured fields for model, service tier, cost type, token type, context window, and inference geography. |
Rate Limit data stream settings
| Setting | Default | Description |
|---|---|---|
| Interval | 15m |
How often the Rate Limits API is polled. This is a snapshot API, so each poll returns the full current configuration. |
After deploying, verify data is flowing by checking the following data streams in Discover:
metrics-anthropic_metrics.usage-*metrics-anthropic_metrics.cost-*metrics-anthropic_metrics.rate_limit-*
For help with Elastic ingest tools, check Common problems.
- HTTP 401 errors: Verify the Admin API key is valid and starts with
sk-ant-admin.... Standard API keys do not work with Admin endpoints. - HTTP 403 errors: Confirm the key has organization admin permissions and the organization has Admin API access enabled.
- No data for usage/cost streams: Check that the time window parameters (
initial_interval,bucket_width) are configured correctly and that the organization has recent API activity.
For more information on architectures that can be used for scaling this integration, check the Ingest Architectures documentation.
The usage data stream collects token usage metrics from the Anthropic Usage API.
Exported fields
| Field | Description | Type |
|---|---|---|
| @timestamp | Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. | date |
| anthropic.usage.api_key_id | API key identifier when grouped by api_key_id. | keyword |
| anthropic.usage.bucket_end_time | End time of the usage bucket. | date |
| anthropic.usage.bucket_start_time | Start time of the usage bucket. | date |
| anthropic.usage.cache_creation_input_tokens | Cache creation input tokens consumed in the bucket. | long |
| anthropic.usage.cached_input_tokens | Cached input tokens consumed in the bucket. | long |
| anthropic.usage.context_window | Context window size when grouped by context_window. | keyword |
| anthropic.usage.inference_geo | Inference geography when grouped by inference_geo. | keyword |
| anthropic.usage.model | Claude model name for the bucket. | keyword |
| anthropic.usage.output_tokens | Output tokens generated in the bucket. | long |
| anthropic.usage.service_tier | Service tier for the bucket (e.g. standard). | keyword |
| anthropic.usage.speed | Speed tier when grouped by speed. | keyword |
| anthropic.usage.uncached_input_tokens | Uncached input tokens consumed in the bucket. | long |
| anthropic.usage.workspace_id | Workspace identifier for the bucket. | keyword |
| data_stream.dataset | The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.namespace | A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.type | An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. | constant_keyword |
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | constant_keyword |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module. |
constant_keyword |
| input.type | Type of input that generated the event. | keyword |
The cost data stream collects daily cost data from the Anthropic Cost API.
Exported fields
| Field | Description | Type |
|---|---|---|
| @timestamp | Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. | date |
| anthropic.cost.amount | Cost amount in lowest units (e.g. cents) as returned by the Anthropic API. | double |
| anthropic.cost.bucket_end_time | End time of the cost bucket. | date |
| anthropic.cost.bucket_start_time | Start time of the cost bucket. | date |
| anthropic.cost.context_window | Context window used (e.g. 0-200k, 200k-1M). Available when grouped by description. | keyword |
| anthropic.cost.cost_type | Type of cost (e.g. tokens, web_search, code_execution, session_usage). Available when grouped by description. | keyword |
| anthropic.cost.currency | Currency code for the cost amount (e.g. USD). | keyword |
| anthropic.cost.description | Cost line description (e.g. model usage, Web Search Usage). | keyword |
| anthropic.cost.inference_geo | Inference geography for the cost item (e.g. global, us, not_available). Available when grouped by description. | keyword |
| anthropic.cost.model | Model name for the cost item. Available when grouped by description. | keyword |
| anthropic.cost.service_tier | Service tier for the cost item (e.g. standard, batch). Available when grouped by description. | keyword |
| anthropic.cost.token_type | Type of token (e.g. uncached_input_tokens, output_tokens, cache_read_input_tokens). Available when grouped by description. | keyword |
| anthropic.cost.workspace_id | Workspace identifier for the bucket. | keyword |
| data_stream.dataset | The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.namespace | A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.type | An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. | constant_keyword |
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | constant_keyword |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module. |
constant_keyword |
| input.type | Type of input that generated the event. | keyword |
The rate_limit data stream collects rate limit configuration from the Anthropic Rate Limits API.
Exported fields
| Field | Description | Type |
|---|---|---|
| @timestamp | Date/time when the event originated. This is the date/time extracted from the event, typically representing when the event was generated by the source. If the event source has no original timestamp, this value is typically populated by the first time the event was received by the pipeline. Required field for all events. | date |
| anthropic.rate_limit.enqueued_batch_requests | Maximum enqueued batch requests allowed. | long |
| anthropic.rate_limit.group_type | Rate limit group type (e.g. model_group, batch, token_count). | keyword |
| anthropic.rate_limit.input_tokens_per_minute | Maximum input tokens per minute allowed for the model group. | long |
| anthropic.rate_limit.input_tokens_per_minute_cache_aware | Maximum cache-aware input tokens per minute for the model group. Only uncached and cache-creation tokens count against this limit; cache-read tokens are excluded for most models. | long |
| anthropic.rate_limit.limits.type | Limit metric type (e.g. requests_per_minute, input_tokens_per_minute). | keyword |
| anthropic.rate_limit.limits.value | Limit value for the metric type. | long |
| anthropic.rate_limit.models | Model names included in the group when group_type is model_group (array of keywords). | keyword |
| anthropic.rate_limit.output_tokens_per_minute | Maximum output tokens per minute allowed for the model group. | long |
| anthropic.rate_limit.requests_per_minute | Maximum requests per minute allowed for the model group. | long |
| anthropic.rate_limit.type | Object type (rate_limit). | keyword |
| data_stream.dataset | The field can contain anything that makes sense to signify the source of the data. Examples include nginx.access, prometheus, endpoint etc. For data streams that otherwise fit, but that do not have dataset set we use the value "generic" for the dataset value. event.dataset should have the same value as data_stream.dataset. Beyond the Elasticsearch data stream naming criteria noted above, the dataset value has additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.namespace | A user defined namespace. Namespaces are useful to allow grouping of data. Many users already organize their indices this way, and the data stream naming scheme now provides this best practice as a default. Many users will populate this field with default. If no value is used, it falls back to default. Beyond the Elasticsearch index naming criteria noted above, namespace value has the additional restrictions: * Must not contain - * No longer than 100 characters |
constant_keyword |
| data_stream.type | An overarching type for the data stream. Currently allowed values are "logs" and "metrics". We expect to also add "traces" and "synthetics" in the near future. | constant_keyword |
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | constant_keyword |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), event.module should contain the name of this module. |
constant_keyword |
| input.type | Type of input that generated the event. | keyword |
This integration includes one or more Kibana dashboards that visualizes the data collected by the integration. The screenshots below illustrate how the ingested data is displayed.
Changelog
| Version | Details | Minimum Kibana version |
|---|---|---|
| 0.1.0 | Enhancement (View pull request) Initial release with usage, cost, and rate_limit data streams for Anthropic Admin APIs. |
9.4.0 |