Ten common mistakes when building with the Anthropic API and how to avoid them: forgetting max_tokens (required), system prompt in messages array (wrong), non-alternating messages, unchecked stop_reason, creating client per request, no 529 handling, hardcoded model IDs, expensive output tokens, no streaming, and unnecessary PII.
max_tokensUnlike OpenAI, max_tokens is required. Omitting it returns a 400 error.
// BAD
await client.messages.create({ model: 'claude-sonnet-4-20250514', messages });
// GOOD
await client.messages.create({ model: 'claude-sonnet-4-20250514', max_tokens: 1024, messages });
Claude uses a top-level system parameter, not a system message in the array.
// BAD — this sends "system" as a user message role, which will error
messages: [{ role: 'system', content: '...' }, { role: 'user', content: '...' }]
// GOOD
system: 'You are helpful.',
messages: [{ role: 'user', content: '...' }]
Messages must strictly alternate between user and assistant.
// BAD — two user messages in a row
messages: [
{ role: 'user', content: 'Hello' },
{ role: 'user', content: 'How are you?' }, // ERROR
]
// GOOD — combine into one or add assistant between
messages: [
{ role: 'user', content: 'Hello. How are you?' },
]
stop_reasonIf stop_reason === 'max_tokens', the response was truncated.
if (message.stop_reason === 'max_tokens') {
// Response is incomplete — increase max_tokens or handle truncation
}
Each new Anthropic() creates a new connection pool. In serverless, this adds latency.
// BAD — new client every request
app.post('/chat', async (req, res) => {
const client = new Anthropic(); // Cold connection every time
});
// GOOD — reuse across requests
const client = new Anthropic();
app.post('/chat', async (req, res) => {
await client.messages.create({ ... });
});
529 (overloaded) is common during peak hours. The SDK retries automatically, but you should handle it for critical paths.
Model IDs change with new versions. Use environment variables.
const MODEL = process.env.CLAUDE_MODEL || 'claude-sonnet-4-20250514';
Output tokens cost 5x more than input tokens. A 4096 max_tokens response on Opus costs ~$0.30. Use the smallest max_tokens that works.
Without streaming, users stare at a blank screen for 5-30 seconds. Always stream for interactive use.
Don't include user PII in prompts unless the task requires it. Redact before sending.
| Pitfall | Fix |
|---|---|
Missing max_tokens |
Always include it |
| System in messages | Use top-level system param |
| Non-alternating messages | Combine or interleave |
Unchecked stop_reason |
Check for max_tokens truncation |
| Client per request | Module-level singleton |
| No 529 handling | SDK retries + fallback model |
| Hardcoded model IDs | Environment variable |
| Expensive output | Minimize max_tokens |
| No streaming | Always stream for UI |
| Unnecessary PII | Redact before sending |
max_tokens present on every messages.create callsystem parameterstop_reason checked for truncation| Error | Cause | Solution |
|---|---|---|
| API Error | Check error type and status code | See clade-common-errors |
See ten numbered pitfall sections above, each with BAD/GOOD code comparisons. Quick Reference table at the end summarizes all fixes.
Each section contains production-ready code examples. Copy and adapt them to your use case.
Integrate the patterns that match your requirements. Test each change individually.
Run your test suite to confirm the integration works correctly.