Limieten en kostenfactoren

Deze pagina documenteert hoe de Cryptohopper Market Data MCP aanroepen telt, limieten toepast en kostenmultiplicatoren rekent voor historische gegevens. Dit is de technische referentie; zie abonnementstiers voor het overzicht per tier.

Twee onafhankelijke limieten

De MCP handhaaft twee aparte limieten voor elk account:

• Wekelijkse aanroeplimiet. Een doorlopend wekelijks quotum aan aanroepen, specifiek per tier.
• Frequentielimiet. Een korte-interval limiet op hoe snel aanroepen gedaan kunnen worden.

Beide limieten worden per account toegepast. Het aanmaken van extra API-sleutels vermenigvuldigt geen van beide limieten.

Wekelijkse aanroeplimiet

Tier	Wekelijkse aanroepen
Pioneer	6.000
Explorer	30.000
Adventurer	150.000
Hero	1.250.000

De teller wordt elke vrijdag op een vast tijdstip per account gereset. Het overschrijden van de limiet geeft een QUOTA_EXCEEDED foutmelding tot de volgende reset.

Het huidige gebruik en de tijd tot de reset kunnen op elk moment opgevraagd worden. Zie gebruik en limieten.

Frequentielimiet

Naast de wekelijkse limiet voorkomt een korte-interval frequentielimiet snelle uitbarstingen. Het exacte tijdsvenster en de drempelwaarde worden uniform toegepast over alle tiers en kunnen zonder kennisgeving aangepast worden om de stabiliteit van de dienst te behouden.

Het overschrijden van de frequentielimiet geeft een RATE_LIMIT_EXCEEDED foutmelding. Opnieuw proberen na een korte vertraging slaagt meestal.

Richtlijn: Als jouw workflow veel opeenvolgende aanroepen omvat (bijvoorbeeld het scannen van tickers voor alle paren op een beurs), voeg dan een kleine vertraging tussen aanroepen toe — in de orde van tientallen tot honderden milliseconden — om onder de frequentielimiet te blijven. MCP-clients doen dit automatisch in de meeste gevallen.

Kosteeneenheid

Een aanroepeenheid is de basislading voor een enkele tool-aanroep. De wekelijkse aanroeplimiet wordt uitgedrukt in eenheden.

De meeste tool-aanroepen tellen als 1 eenheid. Historische kaarsquery's kunnen als meer dan 1 eenheid tellen, zoals hieronder beschreven.

Kostenfactor: historische gegevens

Historische kaarsquery's hebben een kostenmultiplicator op de Explorer en Adventurer tiers. De multiplicator hangt af van de terugkijkdiepte:

Terugkijkdiepte	Kostenmultiplicator
Korte geschiedenis (recente bars binnen een kort venster)	5×
Lange geschiedenis (bars die reiken naar het maximale geschiedenisbereik van de tier)	20×

De grens tussen "kort" en "lang" is tierspecifiek en kan aangepast worden. Als werkregel worden query's die ruwweg de meest recente ~10% van de historische toelage van de tier ophalen in rekening gebracht tegen 5×; diepere query's worden in rekening gebracht tegen 20×.

Op de Hero tier worden alle historische query's in rekening gebracht tegen 1× ongeacht de terugkijkdiepte.

Ticker- en orderboekquery's worden altijd in rekening gebracht tegen 1× op alle tiers.

Voorbeelden

Query	Tier	Eenheidskosten
Huidige BTC/USDT ticker op Binance	Alle	1
Volledige orderboek snapshot voor ETH/USDT op Kraken	Alle	1
Laatste 100 × 1u kaarsen voor SOL/USDT op Binance (recent)	Explorer	5
Laatste 500 × 1u kaarsen terugkijkend ~3 weken	Explorer	5
Laatste 1.000 × 1u kaarsen terugkijkend naar 90-dagen limiet	Explorer	20
Laatste 1.000 × 4u kaarsen (diepe terugkijk)	Adventurer	20
Laatste 3.000 × 1u kaarsen (3-jaar terugkijk)	Hero	1

De exacte kosten van een specifieke query kunnen vooraf bekeken worden door het gebruik-eindpunt aan te roepen na de query — het verschil in calls_used is de eenheidskosten.

Budgetrichtlijn

Een paar werkregels om binnen het quotum te blijven:

• Geef de voorkeur aan tickers voor brede scans. Een 200-paar tickerscan kost 200 eenheden. Dezelfde scan via orderboeken kost 200 eenheden (hoewel elke aanroep veel meer data overdraagt). Dezelfde scan via diepe kaarsgeschiedenis kan duizenden eenheden kosten.
• Houd de terugkijk van kaarsen beperkt. De meeste indicatoren (RSI, MACD, voortschrijdende gemiddelden tot 200-periode) hebben niet meer dan 150-200 kaarsen context nodig. Standaard 1.000 kaarsen ophalen is de meest voorkomende oorzaak van onnodig quotumverbruik.
• Cache waar het zinvol is. Orderboeken worden binnen seconden verouderd, dus het cachen van orderboek-snapshots is zelden nuttig. Kaarsgegevens ouder dan de huidige bar zijn onveranderlijk, dus het cachen of opslaan van historische kaarsen is passend.
• Gebruik Hero wanneer historische diepte structureel vereist is. Als jouw workflow routinematig lange kaarsgeschiedenissen ophaalt, is de vaste 1× kostenfactor op Hero meestal economischer dan dezelfde data ophalen op Adventurer tegen 20×.

Quotum voor multi-agent implementaties

Als meerdere agents één account delen, trekken alle agents uit hetzelfde wekelijkse quotum. Om agents te scheiden:

• Maak extra API-sleutels aan (binnen de sleuteltoewijzing van de tier). Elke sleutel verbruikt uit het gedeelde quotum maar kan onafhankelijk ingetrokken of gerouleerd worden.
• Implementeer beperking op applicatieniveau per sleutel om te voorkomen dat één agent het quotum voor anderen uitput.

Zie hoe je meerdere agents met meerdere API-sleutels uitvoert voor patronen.

Foutafhandeling

Limietgerelateerde fouten geretourneerd door de MCP:

Foutcode	Betekenis
QUOTA_EXCEEDED	Wekelijkse aanroeplimiet bereikt. Reset op de volgende resettijd.
RATE_LIMIT_EXCEEDED	Korte-interval frequentielimiet bereikt. Probeer opnieuw na korte vertraging.
HISTORY_LIMIT_EXCEEDED	Gevraagde terugkijk overschrijdt de maximale geschiedenis van de tier.
EXCHANGE_NOT_SUPPORTED	Gevraagde beurs staat niet in de toegestane lijst van de tier.

Volledige foutreferentie: foutreferentie.

Huidig gebruik controleren

De MCP biedt een gebruiksinspectietool die het volgende retourneert:

• tier — de actieve abonnementstier.
• calls_used — eenheden gebruikt in de huidige wekelijkse cyclus.
• calls_limit — de wekelijkse limiet van de tier.
• reset_at — ISO-8601 tijdstempel van de volgende reset.