API pour agents et LLM
Ce n’est pas une API séparée : c’est exactement la surface que le navigateur appelle quand vous lancez le test de vitesse sur ce site, documentée pour qu’un script, un agent ou un outil LLM puisse l’appeler aussi. Pas de clé, pas d’inscription, pas de CORS.
Il n’y a pas d’« API publique » séparée ici : ce sont les quatre mêmes points de terminaison que le navigateur de ce site appelle pour lancer un test de vitesse, sans clé d’API, sans compte, et, voir plus bas, sans en-tête CORS.
Points de terminaison
/api/speed/pingSans limiteUne sonde minimale d’aller-retour.
Le champ t de la réponse est purement informatif. Les Workers gèlent Date.now() entre les opérations d’E/S, ce n’est donc pas une horloge fiable pour mesurer la latence, chronométrez la requête vous-même.
/api/speed/metaSans limiteReflète ce que Cloudflare voit de l’appelant : IP, FAI, ASN, ville, pays, et le point de présence (colo) qui a répondu.
Rien n’est stocké ici. C’est renvoyé à l’appelant et à personne d’autre.
/api/speed/down120 requêtes / 60 s / IPDiffuse bytes (paramètre de requête, 1 Mo par défaut, plafonné à 100 Mo) de données aléatoires, pour mesurer la vitesse de téléchargement.
La réponse est no-store, no-transform, rien ne la compresse ni ne la met en cache, ce qui gonflerait la vitesse mesurée.
/api/speed/up120 requêtes / 60 s / IPAccepte un corps de requête allant jusqu’à 100 Mo et indique combien d’octets sont arrivés et en combien de temps, pour mesurer la vitesse d’envoi.
Un Content-Length déclaré au-delà de 100 Mo est rejeté avec 413 avant même de lire le corps.
La limite d’usage, en chiffres
/api/speed/down et /api/speed/up partagent une même limite de 120 requêtes par IP sur chaque fenêtre de 60 secondes, qui se réinitialise d’elle-même. Sur une ligne gigabit, un test de vitesse par défaut fait environ 40 de ces requêtes (quatre flux de téléchargement et quatre d’envoi, chacun relançant des requêtes jusqu’à la fin de sa phase, moins sur les lignes plus lentes), soit environ 3 tests complets par fenêtre. Au-delà, la réponse est 429 avec un en-tête Retry-After. Le décompte est tenu par site Cloudflare : considérez-le comme approximatif. /api/speed/ping et /api/speed/meta sont sans limite : leurs réponses sont triviales, et les limiter ajouterait une vérification exactement sur le chemin qu’ils existent pour mesurer.
La plus grande requête que l’un ou l’autre point de terminaison sert ou accepte est de 100 Mo.
Pas de CORS: volontairement
Ces points de terminaison n’envoient aucun en-tête Access-Control-Allow-Origin, et aucun ne passe par la vérification de même origine que ce site utilise sur ses routes de compte et de facturation. Cette combinaison est délibérée : un appelant côté serveur, curl, un agent, un outil LLM, fonctionne déjà aujourd’hui, tandis qu’un navigateur exécutant du JavaScript cross-origin contre ces points de terminaison est déjà bloqué par le navigateur lui-même. Ajouter un CORS * permettrait à n’importe quel site web de consommer la bande passante de ce site depuis les navigateurs de ses propres visiteurs ; documenter la situation actuelle ne coûte rien et ne change rien.
Un exemple concret: curl
Téléchargez 5 Mo et chronométrez, la forme standard d’une vérification manuelle de débit.
curl -o /dev/null -w "%{time_total}s for %{size_download} bytes\n" \
"https://mysygnal.net/api/speed/down?bytes=5000000"Un exemple concret: un agent ou un outil LLM
La même mesure, chronométrée par l’appelant plutôt que de faire confiance à la réponse, voir la note sur /api/speed/ping ci-dessus.
const t0 = performance.now();
const res = await fetch("https://mysygnal.net/api/speed/down?bytes=5000000");
await res.arrayBuffer();
const seconds = (performance.now() - t0) / 1000;
const mbps = (5_000_000 * 8) / seconds / 1_000_000;Tout ce que ce site offre par ailleurs à un appelant
llms.txt indexe les outils, les guides et chaque page de routeur de ce site dans un seul fichier texte brut, pensé pour être lu par un modèle plutôt que par un navigateur.