Known limitations (v0.1.0)

These are verified against the current source and test suite, not speculative.

Provider quota and capacity

None of the four built in providers (xAI, Gemini, Groq, OpenRouter) expose an endpoint for querying actual remaining quota. AIR only tracks usage a provider reports back on a response, against a limit you configure with add_provider(..., limits={...}). If you never configure a limit, capacity is always treated as unknown for that provider and it is never skipped for capacity reasons. See features/capacity-tracking.md.
If a provider ever answers without reporting usage, that provider's capacity tracking permanently downgrades from "known" to "estimated" for the life of that AIR instance, since the running total can no longer be verified as exact.
A provider whose health becomes exhausted (a QuotaExceededError) is skipped by automatic priority and intelligent routing indefinitely. AIR has no retry_after/cooldown mechanism; no provider adapter currently reports one. The only way to make AIR consider that provider again is to call it directly with explicit provider selection; a success there resets its health. See core/fallback.md.

All token counts (estimate_tokens, estimate_message_tokens, and everything derived from them, including ChatResponse.original_estimated_tokens/optimized_estimated_tokens/estimated_tokens_saved) are a conservative character based approximation (ceil((chars / 4) * 1.2)), not a real tokenizer for any specific model. Treat them as estimates only.

The default summarization strategy (local_summary) is a lightweight compaction (joining and truncating older messages to a fixed character length), not a semantic summary. It does not attempt to preserve meaning beyond truncation.
AI assisted summarization (summarize_with_ai=True) calls a configured provider directly to summarize, spending that provider's quota. It is off by default for this reason.

Request classification (classify_request) uses fixed keyword lists to detect coding and reasoning signals. It does not call another model to classify the request, and it will miss anything not covered by its keyword list (for example, a coding request with no code fence and none of the recognized keywords).
A provider with no capabilities configured is treated as having none of the capability flags set, and will be skipped by intelligent routing for any request with required capabilities.

SQLiteContextStore uses one sqlite3 connection per AIR instance, guarded by an asyncio.Lock. It is safe for concurrent async operations within a single process, but is not designed for multiple separate processes writing to the same database file concurrently.
There is no public constructor argument on AIR for supplying a custom ContextStore implementation directly; AIR always builds either the in memory or SQLite store depending on persist.

SystemTTSBackend is a desktop convenience only (macOS say, Linux espeak/espeak-ng, Windows System.Speech through PowerShell). It does not work on mobile platforms or in a browser, and is not useful in a typical headless server environment. Applications targeting those environments should supply their own TTSBackend or consume structured events directly instead. See features/tts.md.

AIR is not currently published to PyPI. See installation.md for the verified local installation path.