Pourquoi c'est important

Les agents qui fonctionnent en boucle ont deux coûts qui s'additionnent rapidement. Coût de quota : chaque appel à un outil MCP compte sur votre allocation hebdomadaire. Coût en tokens : chaque partie des données dans la fenêtre de contexte augmente le coût de traitement et dégrade la qualité du raisonnement.

Un bloc de contexte léger répond aux deux : un balayage de ticker rapide, résumé en quelques lignes, injecté une seule fois au début de la conversation. L'agent a conscience de la situation sans la tempête d'appels d'outils ni l'inflation de tokens.

Prérequis

Cryptohopper MCP configuré dans un client MCP — voir la présentation de la configuration.
Un workflow d'agent qui s'exécute périodiquement ou en continu. Les invites ponctuelles ne bénéficient pas de cette technique.
Le niveau Pioneer est suffisant — les appels de ticker sont peu coûteux sur tous les niveaux. Voir les niveaux d'abonnement.

Étapes de configuration

Définir ce qui entre dans le bloc
Quatre à six lignes, toutes dérivées des tickers — environ 100 tokens. Un bloc typique couvre : le prix et l'évolution sur 24h de vos tokens de référence, le plus grand gagnant et le plus grand perdant de votre univers de balayage, toute paire avec un volume inhabituel, et une étiquette de régime de marché d'un mot.
```
BTC  66 120   (+1.1%, vol normal)
ETH   3 240   (+2.8%, vol élevé)
SOL  148.50   (+1.9%, vol normal)

Plus grand gagnant :      ARB +8.2% (vol 2.4x)
Plus grand perdant :       DOGE -3.5% (vol normal)
Volume inhabituel :  LINK (prix stable, vol 3.1x)

Régime de marché :   risk-on, largeur modérée
```

Générer le bloc avec une boucle par symbole

Il n'y a pas d'outil de ticker groupé — chaque ticker est un appel MCP unique. La fonction ci-dessous effectue un appel par symbole. Un balayage de 3 ancres + 10 symboles coûte 13 appels par exécution.

def build_thin_context() -> str:
    exchange = "binance"

    # Tickers d'ancrage fixes — un appel pour chacun
    anchors = ["BTC/USDT", "ETH/USDT", "SOL/USDT"]
    anchor_tickers = [mcp.get_ticker(exchange, pair) for pair in anchors]

    # Univers de balayage — un appel par symbole
    sweep_pairs = [
        "ARB/USDT", "OP/USDT", "AVAX/USDT", "LINK/USDT", "AAVE/USDT",
        "UNI/USDT", "DOGE/USDT", "MATIC/USDT", "SEI/USDT", "TIA/USDT",
    ]
    sweep_tickers = [mcp.get_ticker(exchange, pair) for pair in sweep_pairs]

    # Dériver les champs de résumé
    all_tickers = anchor_tickers + sweep_tickers
    top_gainer  = max(all_tickers, key=lambda t: t.change_24h_pct)
    top_loser   = min(all_tickers, key=lambda t: t.change_24h_pct)
    unusual     = [t for t in all_tickers if t.volume_ratio_vs_baseline > 2.5]

    return format_as_context(anchor_tickers, top_gainer, top_loser, unusual)


# Nombre total d'appels = len(anchors) + len(sweep_pairs) = 13 par exécution

Injecter le bloc en haut du message d'ouverture de l'agent

Placez le bloc avant l'instruction de tâche avec un horodatage. L'agent lit d'abord le contexte et ne doit pas re-récupérer les informations déjà répertoriées.

[CONTEXTE AU 2026-04-24 08:00 UTC]

BTC  66 120   (+1.1%, vol normal)
ETH   3 240   (+2.8%, vol élevé)
SOL  148.50   (+1.9%, vol normal)

Plus grand gagnant :      ARB +8.2% (vol 2.4x)
Plus grand perdant :       DOGE -3.5% (vol normal)
Volume inhabituel :  LINK (prix stable, vol 3.1x)

Régime de marché :   risk-on, largeur modérée

Votre tâche : [ce que vous voulez vraiment que l'agent fasse]

Laisser l'agent monter en puissance à partir du bloc léger lorsqu'il a besoin de plus
Le bloc est le résumé. Quand quelque chose semble intéressant, l'agent appelle le MCP pour obtenir des bougies ou une profondeur de carnet d'ordres sur cette paire spécifique. La plupart des exécutions se terminent sans aucune escalade — c'est le comportement correct.
Rafraîchir à une cadence qui correspond au workflow
Agent horaire → reconstruire au début de chaque heure.
Résumé quotidien → une fois par jour.
Assistant à la demande → une fois par session.

Ne réutilisez pas un bloc entre les limites de cadence — un contexte obsolète est pire qu'aucun contexte.

Les mathématiques

Un agent fonctionnant toutes les heures, 16 heures sur 24, 5 jours par semaine, avec un balayage de 13 symboles :

Approche	Appels par exécution	Appels hebdomadaires
Naïf (l'agent tire depuis le début)	20–100 (varie énormément)	1 600–8 000
Contexte léger + escalade sélective	13 de base + ~10–30 en cas d'escalade	1 840–5 040 (stable)

Le contexte léger n'est pas toujours moins cher globalement — ce qu'il achète, c'est la prévisibilité. Vous savez à quoi ressemble la semaine la plus chargée. Sur les 6 000 appels/semaine de Pioneer, il permet à un agent horaire léger d'être utilisable sur le niveau gratuit.

Quand ne pas utiliser ce schéma

Situation	Pourquoi le contexte léger n'aide pas
Recherche conversationnelle ponctuelle	Posez simplement la question — l'assistant s'en charge
Workflows qui nécessitent toujours des données détaillées	Un générateur de paramètres de bot en grille a déjà besoin de l'historique des bougies ; le contexte léger est redondant
Workflows sensibles au slippage (glissement) et à l'exécution	Ceux-ci ne devraient jamais raisonner à partir d'un contexte mis en cache — tirez toujours des données fraîches

Utilisez le contexte léger lorsque le workflow est répété, prévisible et basé principalement sur la conscience de la situation. Les économies s'accumulent ; sans ces propriétés, la surcharge n'en vaut pas la peine.

Dépannage

L'agent ignore le contexte léger et re-tire les mêmes données

Invitez-le explicitement : « Le bloc de contexte ci-dessus est l'état actuel — ne ré-tirez pas les tickers pour BTC, ETH, SOL, ou quoi que ce soit de répertorié. Ne tirez de nouvelles données que si vous avez besoin de quelque chose qui n'est pas dans le bloc. » Une fois formulée comme une contrainte, l'agent la respecte.

Le bloc est obsolète au moment où l'agent l'utilise

Pour les workflows à courte cadence (niveau minute), le bloc devient vite obsolète. Rafraîchissez plus souvent, ou marquez clairement l'horodatage du bloc afin que l'agent sache qu'il doit vérifier avant de prendre des décisions basées sur de vieux chiffres.

Le format du bloc est incohérent d'une exécution à l'autre

Corrigez le format en tant que modèle et remplissez les valeurs — ne laissez pas le modèle écrire le bloc. Un générateur déterministe produit un résultat cohérent.

Vous souhaitez plus de données dans le bloc

Résistez à la tentation. Chaque ligne coûte des tokens à chaque exécution. Si un point de données n'est référencé que par la plupart des exécutions, il appartient à un appel à la demande, pas au bloc.

Le bloc contient des chiffres que l'agent ignore

Supprimez-les. Un bloc utilisé à 100 % est meilleur qu'un bloc utilisé à 60 %.

Le contexte multi-échange rend le bloc trop volumineux

Utilisez un échange principal (généralement Binance) pour le bloc. Demandez à l'agent de récupérer d'autres plateformes uniquement lorsque la comparaison est nécessaire — ne pré-remplissez pas le contexte multi-plateforme pour le cas général.

Vous souhaitez un contexte léger couvrant plusieurs horizons temporels

Utilisez un bloc par objectif d'agent au lieu d'essayer de les unifier. L'agent axé TA obtient un bloc avec une tendance sur 4h ; l'agent axé scan obtient un bloc avec des deltas sur 24h.

Alimente un agent avec le contexte du marché sans cramer de tokens