# Limitations & Caveats {#limitation}

:::warning
This page does not exhaustively cover all limitations and caveats of Takumi Guard. Detailed disclosure of the boundaries of defense mechanisms could be exploited to circumvent them, so the content here is intentionally limited.
:::

## Blocking Coverage {#blocking-limitations}

The Takumi Guard blocklist is continuously updated through an automated analysis pipeline and research by the GMO Flatt Security team, but it cannot detect and block every malicious package before installation. New attack techniques and zero-day malware may not be identified at the time of analysis.

For this reason, Takumi Guard provides [breach notifications](/docs/t/guard/features/breach-notifications.md) alongside blocking. If a package that was considered safe at install time is later found to be malicious, users who downloaded it are notified. The combination of pre-install blocking and post-install notification reduces overall risk.

## Rate Limits {#rate-limit}

Takumi Guard applies the following rate limits based on access method:

| Access Method        | Rate Limit               |
| -------------------- | ------------------------ |
| Anonymous            | 2,000 req/min per IP     |
| Email-verified token | 10,000 req/min per token |
| Org user token       | 10,000 req/10s per token |
| Bot token            | 10,000 req/10s per token |

Requests exceeding the rate limit are rejected with `429 Too Many Requests`.

:::info
The GitHub Actions/Bot rate limit window was reduced from 60 seconds to 10 seconds in April 2026, effectively raising the allowed throughput from ~10,000 req/min to ~60,000 req/min per token. This accommodates large-scale environments with many concurrent GitHub Actions jobs sharing a single token.
:::