50 Things Anthropic's API Can't Do (And We're Going to Walk Through Every Single One)

Quick disclaimer before we start: Claude helped me write this. Very intentionally.

Not just "helped," either.

I gave Claude direct access to our docs at docs.backboard.io. It navigated the docs itself, read them, and produced this list.

So yes, an AI made by Anthropic read our documentation and wrote about the limitations of Anthropic's own API.

It did not argue.
It did not resist.
Because it knows.

So let's talk about what it knows.

Anthropic's API is stateless.
So is OpenAI's.
So is Grok.
So is OpenRouter.

That one word, stateless, explains almost every pain point developers hit the second they move beyond a toy demo.

And yes, we solve this at Backboard. You get free state for life, by the way. Not to bury the lead. But that is only part of the story.

Here is the bigger point.

Stateless means every API call starts from zero.

The model does not know who you are.
It does not know what was said five minutes ago.
It does not know what your user cares about.
It does not know what happened in the last session.

You send context.
It responds.
The connection closes.
It forgets.

That is not a bug.
That is the design.

These APIs are low-level primitives. And low-level primitives are supposed to be simple.

But the second you try to build something real, something users come back to, something that gets better over time instead of feeling reset every session, you hit a wall.

And that wall is infrastructure.

Session management.
Context window handling.
Memory extraction and retrieval.
Vector databases for RAG.
Multi-provider credential management.
Agent orchestration.

None of that ships with the raw API.
All of it becomes your problem.

That is where Backboard comes in.

Backboard is a single API layer that handles all of it across 17,000+ models, including Claude, GPT, Gemini, Grok, and more.

Shared state.
One key.
One abstraction.

Below is a list of 50 specific things Backboard does that the raw Anthropic API does not.

We are going to break all of them down in a 5-part series, starting with the most important concept: what "state" actually means.

Then we build from there, all the way to multi-agent systems you can spin up by describing what you want in plain English.

For now, here are the headlines. Follow me if you want to see all 5 parts without battling the Algo.

---

State and Conversation Persistence

1. Persist a full conversation across sessions without storing anything yourself
2. Pick up exactly where you left off, days or weeks later
3. Give every user their own isolated conversation thread
4. Run unlimited threads per assistant
5. Tag threads with metadata like user IDs, plans, or channels
6. Get the full structured conversation history back from the API at any time
7. Keep threads alive indefinitely until you explicitly delete them

Memory Across Sessions

1. Have an assistant automatically remember user preferences between completely separate conversations
2. Auto-extract facts from conversations and store them in a knowledge base
3. Automatically retrieve relevant memories when they matter, without writing any retrieval logic
4. Pre-load what you already know about a user before they ever say a word
5. Search semantically over everything the assistant has learned about a user
6. Use memory in read-only mode, retrieve without ever writing
7. Add, update, or delete specific memories via API
8. Customize exactly what kinds of facts get extracted, per assistant
9. Use higher-accuracy memory extraction for high-stakes use cases
10. Share everything the assistant learns about a user across all of that user's conversations

Context Window Management

1. Automatically handle conversations that exceed the model's context limit
2. Never manually count tokens or write truncation logic
3. Switch models mid-conversation without recalculating context for the new model
4. Automatically adjust document chunking when the model changes

Model Routing and Multi-Provider Access

1. Access 17,000+ models from a single API key
2. Switch models mid-conversation without losing any state or history
3. Use different models for different messages in the same thread
4. Route cheap queries to cheap models and hard ones to expensive models, in the same thread
5. Implement transparent provider fallback when a provider goes down
6. Browse the full model catalog programmatically, filter by capability, context size, and price

RAG and Document Intelligence

1. Upload a document and have it queryable in minutes with zero infrastructure
2. Get hybrid keyword and semantic search automatically on every query
3. Index mixed document types in one knowledge base, PDFs next to code files next to spreadsheets
4. Scope a document to a single conversation instead of the whole assistant
5. Choose your own embedding model and dimensions per assistant
6. Tune how many chunks get retrieved per query
7. Index code files natively alongside prose
8. Check document indexing status and get chunk and token counts back from the API

Tool Calling with Persistent State

1. Have every tool result automatically become part of the persistent conversation history
2. Chain multiple rounds of tool calls without rebuilding state between rounds
3. Loop tool calls until the agent reaches a completed state
4. Run multiple tools in parallel within a single response
5. Stream the final answer to the user after tool execution completes

Web Search

1. Give an assistant real-time web access with a single parameter
2. Let the assistant decide on its own when to search vs. use what it already knows
3. Combine live web search, persistent memory, and streaming in one API call

Multi-Agent Architecture

1. Run parallel agent threads simultaneously and merge outputs in a coordinator
2. Build specialist and coordinator agent networks
3. Give each agent in a network its own model
4. Give each agent its own system prompt and identity
5. Give each agent distinct tool-calling capabilities
6. Have every agent in a network share what they know about the same user
7. Describe a complete multi-agent system in plain English and have it built for you, no code required

---

That last one gets its own post. It's the whole point of doing all the other work first.

---

What's coming

This is the start of a 5-part series. Each post takes a chunk of the list above and walks through it properly, starting from first principles. If you don't know what "state" means, Part 1 explains it. If you've never thought about the difference between conversation context and long-term memory, Part 2 covers that. We're not assuming anything.

Part 1 (Beginner): What state is, why it matters, and your first 10 stateful patterns explained from scratch.

Part 2 (Intermediate): The difference between context and memory, and 10 patterns that make your assistant genuinely smarter over time.

Part 3 (Advanced): RAG without the infrastructure. Hybrid search, mixed document types, scoping, tuning.

Part 4 (Expert): Multi-model routing, stateful tool chains, and parallel agent execution.

Part 5 (Master): Describing multi-agent systems in plain English and having them built for you via MCP.

Follow along. By the end you'll have gone from "what is state" to building systems most teams spend months architecting.

Start here: docs.backboard.io
Or just get an API key: app.backboard.io — $5 free credits, no credit card needed