How the platform uses the Claude API in production, what data is sent, and how it is bounded.
The platform sends data to a model provider, so customers should be able to read exactly what is sent and when. This page is maintained alongside the code that makes the calls.
| Feature | Trigger | Sent to the API | Never sent |
|---|---|---|---|
| Build failure analysis | A build fails | Last 400 lines of build output, detected language, dependency manifest names | Environment variable values, repository credentials |
| Log summarisation | Operator presses Summarise on a log view | The visible window, after the platform's redaction pass | Logs the operator has not selected |
| Support assistant | Customer asks a question in the console | The question plus documentation passages retrieved from our own pages | Account identifiers, billing details, service contents |
A redaction pass runs on every payload. It replaces values matching known secret shapes with a placeholder and records that it did so, so the answer can still say that a connection string was present.
per_request_max_tokens: 4000
per_project_daily_ceiling: configured in the console
failure_analysis: one attempt, no retry loop
log_summarisation: on demand only, never scheduledA failed call is reported as unavailable rather than retried until it succeeds, because a failing provider should not consume the platform's budget silently.
Build failure analysis is judged by whether the suggested file was in the commit that broke the build. That is a crude measure, but it is checkable, and it is the one we report internally.