iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Claude Console’s Usage page is an API-usage audit view, not a complete project or workflow dashboard. Sign in to Claude Console, open Usage, choose Export, and inspect the downloaded CSV. Anthropic documents a breakdown by API key and model, which is useful for finding applications still calling an old model. The documented export does not establish project-name, workflow-status, user, real-time, budget-alert, or spend-monitoring views.
If your team needs developer or team attribution, centralized budgets, rate limits, or gateway audit logs, you need an additional control layer rather than assuming those functions exist in the native Usage page. This guide shows what the Console export can prove, how to turn it into a repeatable audit, and when a third-party gateway is justified.
What the Claude dashboard actually monitors
For the workflow documented by Anthropic, the relevant dashboard is the Usage page in Claude Console. Its practical purpose is to let an API customer export activity and investigate which credentials and models generated that activity. Anthropic describes the downloaded CSV as usage broken down by API key and model in its model-deprecation and usage-auditing documentation.
That distinction matters because “monitor projects and workflows” can imply a much broader product: project pages, named workflow runs, user-level ownership, live charts, spend alerts, or job-status tracking. The cited Claude Console documentation does not establish those features in the Usage export. Treat the page as an evidence source for API credentials and model selection, then add your own project mapping or a separate gateway if you need richer attribution.
#1 Best Overall
What the export can answer
- Which API keys appear in the exported usage.
- Which models are associated with that activity.
- Whether a key or model deserves investigation during a model migration.
- Whether an application may still be calling a model that is being deprecated, subject to the limits of the fields included in the CSV.
What it does not prove
- That a row is associated with a human user, department, project name, ticket, or workflow run.
- That the page provides real-time monitoring, spend alerts, budgets, rate limits, or workflow-status tracking.
- That a model was used by a particular customer-facing feature merely because its API key has activity.
Use those unsupported interpretations as requirements for an additional system, not as assumptions about the Console page.
Before you start
You need access to the Claude Console organization that owns the API activity and permission to view its Usage page. Have a secure location ready for the downloaded CSV; usage exports can reveal operational details such as credential identifiers, model choices, and activity timing. Keep the file in your approved storage and restrict access to the people performing the audit.
Define the question you are trying to answer before exporting. A model-migration audit, for example, asks whether any key still calls a deprecated model. A project-cost allocation exercise asks which key represents each internal project. The native export directly supports the first question and only indirectly supports the second, because the documented breakdown is by key and model rather than by project.
How to export Claude API usage
- Sign in to Claude Console. Use the organization and environment whose API activity you want to review. Do not assume that a personal account or a different organization contains the same keys.
- Open the Usage page. Navigate to the Console area labeled Usage. If your organization presents more than one environment or account, confirm that you are viewing the one that owns the keys under review.
- Select Export. Use the page’s Export action to download the usage file. The documented workflow is an export for later inspection, not a promise of a continuously updating dashboard feed.
- Store the CSV safely. Preserve the original file as an audit artifact, record the export date and the Console organization, and work from a copy when possible.
- Review the key and model fields. Anthropic’s instruction is to review the downloaded CSV for usage broken down by API key and model. Start with those two dimensions rather than inferring fields that the documentation does not promise.
- Record findings and owners. For each key or model that needs action, record the responsible application owner in your own inventory. That ownership mapping is an operational control you maintain; it is not a field that the documented export guarantees.
A practical review worksheet
Create a separate worksheet with columns such as API key identifier, model observed, application owner, internal project, migration status, last reviewed, and evidence location. Keep the first two columns tied to the CSV and mark the remaining columns as your organization’s annotations. This prevents an internal label from being mistaken for native Claude metadata.
How to read the CSV without over-interpreting it
Start with API keys
Group or filter rows by API key to find which credentials generated the usage you are investigating. A key is a useful technical boundary when your team issues separate credentials per application or environment. It is not automatically a project, person, or workflow: a single key may be shared by several services, and a project may use more than one key.
Then inspect models
Within each key, list the models present. This lets you distinguish an application that has already migrated from one that still calls an older model. Keep the model value exactly as exported so that a later comparison with Anthropic’s deprecation notices is unambiguous.
Rank #2
- Used Book in Good Condition
Join the export to your own inventory
To answer “which project is responsible,” join the CSV to a key inventory maintained by your engineering or platform team. A minimal inventory should map each key to an application, environment, technical owner, and business project. If the inventory has no match, classify the key as unmapped and investigate it rather than assigning it to the most likely project.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Use a conservative evidence rule
Report only what the file supports. For example, “Key K is associated with model M in this export” is supported by the documented breakdown. “The checkout workflow used model M 37 times” requires workflow-level telemetry that the Usage export is not documented to provide. Keep that second statement out of a Console-only report unless another system supplies the evidence.
Using the export for model-deprecation audits
Anthropic positions this export as a way to identify applications that still use deprecated models. Start with the current model-deprecation information, then search the exported model values for names listed there. The relevant documentation is Anthropic’s model-deprecation page.
- Obtain the current deprecation list. Open the model-deprecation documentation on the same review date as your audit. Deprecation status can change, so retain the date alongside your findings.
- Normalize only for comparison. Compare the model identifiers in the CSV with the identifiers in the documentation. Do not silently rewrite the original CSV value; keep the source value and place any normalized label in a separate column.
- Find every affected key. Filter the export for deprecated model identifiers, then list each API key associated with them.
- Trace each key to an application. Use your internal key inventory, deployment configuration, and service owners to determine which application must change. The Console export alone does not name that application.
- Plan and verify the migration. After the owner updates the application, run the next scheduled export and check whether the deprecated model still appears. Keep both the pre-change and post-change files so the audit trail shows what changed.
This procedure demonstrates the strongest documented use of the Usage export: finding credentials and models that need migration. It does not turn the export into a live workflow monitor or establish that a particular business process completed successfully.
How do I monitor Claude usage by project?
You cannot claim native project-level monitoring from the documented Usage export. The supported fields are API key and model. To approximate project monitoring, design your credential and inventory practices so that each project can be traced to a key, then combine the export with your own records.
Recommended Free Tools
Option 1: One key per project or application
Issue separate keys for boundaries you genuinely need to audit, such as production application A, staging application A, and production application B. Document the mapping in a controlled inventory. This creates a practical join key for later exports, but it also increases credential-management work and does not add project names to the CSV itself.
Option 2: One key per environment with an external mapping
If separate keys per project would be impractical, keep a smaller key set and maintain a service registry that records which projects deploy through each key. This is simpler operationally but produces less precise attribution when several projects share a credential.
Option 3: Add application telemetry
Record project and workflow identifiers in the application layer that makes the API request. Your logs can then connect a request to a deployment, job, or customer operation. The Console export remains useful for reconciling which key and model were active, while application telemetry supplies the context the export does not document.
Do not describe any of these designs as a built-in Claude project dashboard. They are ways to build an attribution process around the Console’s key-and-model evidence.
Where can I see Claude API usage?
For the documented audit path, sign in to Claude Console and open Usage. Choose Export to obtain the file for analysis. The export is the important artifact because Anthropic specifically documents reviewing the downloaded CSV by API key and model.
If you need historical comparisons, store each export with a consistent filename that includes the organization, environment, and UTC export date. For example, use a pattern such as claude-usage-production-2026-10-16.csv. The filename is your convention, not a Claude-generated requirement. Keep an index that records who downloaded the file, which date range or view was selected if the interface exposes one, and where the original is stored.
Can I export Claude usage by API key?
Yes. Anthropic documents an Export action on the Claude Console Usage page and says the downloaded CSV shows usage broken down by API key and model. Read the official procedure at Model deprecations — Auditing model usage.
The answer has an important boundary: export by API key does not equal export by project, workflow, developer, or team. If your CSV review needs those dimensions, add an internal key-to-owner mapping, application logs, or a separate gateway layer.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When a third-party gateway is warranted
Anthropic’s Claude Code documentation describes using a third-party LLM gateway as a centralized layer. The listed gateway capabilities include attributing usage by developer or team, enforcing budgets and rate limits, maintaining audit logs, and switching providers through gateway configuration. These are gateway capabilities; they should not be presented as native features of the Claude Console Usage page.
Anthropic identifies LiteLLM as a third-party gateway and states that Anthropic does not endorse, maintain, or audit its security or functionality. Read the relevant guidance in Other LLM gateways. Treat any gateway as infrastructure that requires your own architecture, security, reliability, and vendor review.
What a gateway can add
- Developer or team attribution: requests can be associated with the identity or group your gateway understands.
- Budgets and rate limits: centralized policies can limit consumption or request volume before traffic reaches the model provider.
- Audit logging: a gateway can record the request context needed for operational investigations, subject to your privacy and retention rules.
- Provider switching: gateway configuration can provide a control point for changing providers without rewriting every application integration.
What a gateway does not remove
- You still need accurate project and owner identities at the point where requests enter the gateway.
- You must secure gateway credentials, logs, configuration, and administrative access.
- A gateway introduces another service whose availability, latency, compatibility, and data-handling behavior must be evaluated.
- Gateway records and Claude Console exports may use different identifiers or time boundaries, so reconciliation requires a defined process.
Choosing an approach
| Need | Claude Console Usage export | Key inventory and application telemetry | Third-party gateway |
|---|---|---|---|
| See API activity by key | Documented capability: export broken down by API key. | Uses the export as an input and adds ownership context. | Can add another record of the request path. |
| See models in use | Documented capability: export broken down by model. | Can connect models to deployments or workflows you log. | Can apply centralized routing or policy, depending on configuration. |
| Project or workflow attribution | Not established by the cited documentation. | Possible through your key registry and application logs. | Gateway documentation describes developer/team attribution, but project detail depends on your identity and tagging design. |
| Budgets and rate limits | Not established for the Usage page. | Requires controls in your applications or infrastructure. | Listed as gateway capabilities; validate implementation and limits yourself. |
| Audit logs | The export is an audit artifact for key/model usage. | Can supplement it with application events. | Listed as a gateway capability; review retention, access, and security. |
| Operational responsibility | Manage exports, storage, interpretation, and model migration. | Maintain the inventory, logging, and reconciliation process. | Also operate and secure the additional gateway layer. |
Choose the simplest option that answers your actual question. If your objective is to locate deprecated model calls, the Console export may be sufficient. If you need accountable team attribution and centrally enforced limits, plan for an additional control layer and its operational cost.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A repeatable monitoring routine
Weekly or release-based review
- Export Usage data from the correct Console organization.
- Store the original CSV with its date and environment.
- Compare API keys and models with your inventory.
- Flag new, unmapped, or unexpectedly active keys.
- Check model identifiers against the current deprecation documentation.
- Assign each finding to an application owner and record a due date.
Before a model migration
- Export usage before changing production configurations.
- List every key using the model under review.
- Confirm that each key maps to an owner and deployment.
- Update the application configuration under your normal change-control process.
- Export again after deployment and compare the model values.
After an incident
- Preserve the relevant export without editing the original.
- Identify the keys and models associated with the incident window, if the available export view supports that period.
- Correlate those values with your application and gateway logs.
- Rotate or disable credentials according to your organization’s security procedure if compromise is suspected.
- Document which conclusions come from the Console export and which come from other logs.
Troubleshooting common interpretation and workflow problems
The export has a key but no obvious project
That is expected when the documented dimensions are API key and model. Check your key inventory and deployment configuration. If several projects share one key, the export cannot reliably separate them; improve the credential boundary or add application-level telemetry.
Free tools Windows power users keep installed
One-click scans. No signup required.
A model appears that no team recognizes
Preserve the exact model identifier, identify every key associated with it, and search deployment repositories, environment configuration, and service ownership records. Do not infer that the model belongs to the most recently changed project.
Best Value
The export and gateway records disagree
Compare export dates, time zones, filtering rules, retries, and identifier formats. A gateway may record an attempted request while the provider export reflects accepted usage, or the two systems may cover different windows. Define which system is authoritative for each question and retain both records for reconciliation.
You need live alerts
The cited Console documentation supports an export-based review, not a promise of real-time alerts. Implement alerting in your own telemetry or gateway layer if immediate notification is a requirement. Keep the Console export as a periodic provider-side reconciliation artifact.
You need user-level attribution
The documented key/model breakdown does not establish user attribution. Capture an approved user or service identity in your application or gateway, minimize sensitive data, and document retention and access rules.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesSecurity and governance practices
- Limit access: give Usage-page and CSV access only to people who need it for operations, finance, compliance, or incident response.
- Protect exports: store files in approved locations, encrypt them according to your policy, and avoid emailing unprotected copies.
- Separate evidence from annotations: keep the original CSV unchanged and maintain a separate review worksheet for project names, owners, and decisions.
- Set retention: define how long exports and any gateway or application logs are retained, then delete them on schedule.
- Review credential design: shared keys reduce attribution quality; excessive key proliferation increases rotation and access-management work.
- Evaluate gateways independently: Anthropic’s documentation says it does not endorse, maintain, or audit LiteLLM’s security or functionality. Apply your own security review to any third-party gateway.
Documentation for related Claude Code setups
If your monitoring work concerns Claude Code rather than a directly integrated API application, consult Anthropic’s Advanced setup — Claude Code guidance for supported configuration patterns. The CLI reference can help you distinguish command-line behavior from organization-wide usage auditing. Neither page changes the documented limitation of the Console Usage export: its stated breakdown is by API key and model.
The practical boundary
Use Claude Console Usage when you need a provider-side export showing which API keys and models appear in your activity, especially for finding applications that still call deprecated models. Do not label it a project or workflow dashboard unless you have separate evidence for those dimensions. For project ownership, connect keys to an internal inventory and application logs. For centralized developer or team attribution, budgets, rate limits, or gateway audit logs, evaluate a third-party gateway and accept the additional security and operational responsibility.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
