🤓 Nolife Tokens - réduire le contexte LLM sans compromettre la capacité de récupération

le 16 août 2026

Les agents de codage IA ont inversé un problème de performance bien connu.

Pendant des années, nous avons lutté contre les limitations liées au débit de données, aux allers-retours HTTP, à la latence et à la mémoire des processus. Ces contraintes restent importantes. Ce qui a changé, c'est qu'une part importante du coût et des défaillances d'une session d'agent réside désormais dans l'invite de commande : résultats des outils, journaux, différences, arborescences du dépôt, bruit du compilateur, objets JSON et les mêmes lignes d'information répétées des centaines de fois.

Le processus naïf est simple :

Tool → giant stdout → LLM context

Cela fonctionne jusqu'à ce que le contexte soit saturé d'informations sans grande valeur et que le modèle doive encore trouver la seule ligne d'erreur pertinente. Des fenêtres de contexte plus larges permettent d'envoyer toutes les données, mais ne rendent pas cette pratique judicieuse.

Cet article décrit nolife-tokens, une expérience volontairement modeste avec Symfony et Flow. La thèse est ciblée et vérifiable :

Supprimer des informations du contexte LLM actif ne signifie pas nécessairement les perdre. Le contexte peut être fortement compressé, tandis que les données omises restent récupérables de manière déterministe grâce à des références légères.

Nous avons mesuré le volume, la rétention du signal et la récupération au bit près sur les équipements de test. Nous n'avons pas encore mesuré les jetons facturés par le fournisseur, la latence de bout en bout des agents ni le coût en dollars. Ces distinctions sont importantes.

Inspiration sans clonage de produits

Plusieurs projets ouverts explorent des idées connexes : RTK (compression des commandes et des sorties avant leur lecture par l’agent), context-mode (conserver les données brutes et les récupérer à la demande), Headroom (compression adaptée au contenu avec stockage réversible), Claude-mem (divulgation progressive de la mémoire).

Vous n’avez pas besoin de connaître ces bases de code. L’idée commune utile n’est pas « un autre framework d’agents », mais plutôt :

Effectuez un travail plus déterministe avant d'envoyer les données au LLM.

La déduplication des journaux, la suppression des clés de télémétrie, la classification des différences Git, le hachage d'une section omise : aucune de ces opérations ne nécessite de modèle. Le budget de contexte du modèle doit être consacré à la gestion des ambiguïtés et à la prise de décision, et non à cinq cents copies de « [INFO] requête démarrée ».

nolife-tokens est un laboratoire pour cette idée au sein de la pile Darkwood : PHP 8.5, Symfony Console et darkwood/flow. Pas d’embeddings, pas de base de données vectorielle, pas de MCP, pas de Redis, pas de LangChain.

Point de départ : un squelette et un pipeline observable

Le projet a débuté avec une structure Symfony 8.1 minimale. Le code de l'application se résumait essentiellement à un noyau. Flow était déjà une dépendance de Composer, mais inutilisée.

La première étape, TOKEN_PIPELINE_POC, a permis de connecter un pipeline Flow minimal via un ContextPacket mutable :

Load
→ Classify
→ MeasureRaw
→ Optimize
→ MeasureOpt
→ EvaluateSignals

Interface de ligne de commande :

bin/console tokens:analyze fixtures/sample.log
bin/console tokens:benchmark

Le flux est utile ici non pas parce que nous avons besoin d'une orchestration simultanée, mais parce que chaque étape est observable. Le paquet accumule une trace : octets et jetons estimés après le chargement, type de contenu après la classification, taille après l'optimisation, réussite/échec après les vérifications de signaux. Le lecteur (et l'ingénieur) voit :

raw → classified → reduced → evaluated

au lieu d'une fonction optimizeContext() opaque qui masque l'endroit où le volume a disparu.

Voici à quoi ressemble, dans l'esprit, une trace typique de tokens:analyze :

LOAD         | fixtures/sample.log | 19,354 bytes
CLASSIFY     | log
MEASURE_RAW  | 19,354 bytes        | ~4,839 tokens
OPTIMIZE     | log refs=1          | 4,813 bytes
MEASURE_OPT  | markers~4 referenced~3671 | ~1,204 tokens
SIGNAL       | PASS
RECOVERY     | PASS

Cette liste d'étapes constitue le produit. En cas de problème (économies insuffisantes, signal défaillant, nombre excessif de références), vous pouvez identifier l'étape responsable sans avoir recours à une plateforme de métriques supplémentaire.

Pourquoi limiter la taille du projet ? Parce que les systèmes contextuels ont tendance à se transformer en frameworks avant même que l’on ait pu vérifier la viabilité de l’idée de base. nolife-tokens se rapproche volontairement davantage d’un laboratoire en console que d’une API de bibliothèque. Pas de ports, d’adaptateurs ni d’interfaces spéculatives. Uniquement des classes PHP, des services Symfony via l’injection automatique de dépendances, et des fichiers dans le répertoire var/.

Jetons estimés, et non jetons facturés

La mesure utilise une approximation documentée, la même heuristique que RTK documente publiquement :

// TokenEstimator.php (excerpt)
estimatedTokens: (int) ceil($bytes / 4),

Les pourcentages entre les valeurs brutes et optimisées sont utiles à des fins de comparaison. Les valeurs absolues ne correspondent pas aux jetons facturés par le fournisseur. Les modèles de tokenisation diffèrent. Dans cet article, le terme « jetons » désigne cette estimation, sauf indication contraire.

Classification déterministe en premier

La stratégie de compression dépend du type de contenu. La classification est heuristique et sans LLM.

Cette distinction n'est pas purement théorique. Différents types de bruit se compressent différemment.

• Journaux : les lignes répétitives et les messages de faible intensité doivent rester affichées ; les lignes ERROR / WARNING importantes doivent rester affichées.
• JSON : télémétrie, remplissage, identifiants de requête ; les champs de décision (id, status, error) doivent rester
• Différences Git : de nombreuses lignes + / - contiennent des informations utiles ; un élagage agressif est dangereux
• Listes de fichiers : peuvent se décomposer en arbres avec des décomptes
• Texte : espaces blancs légers uniquement dans le POC actuel

Premier test de performance : volume vs signal

Les fixtures insèrent intentionnellement des chaînes critiques. Une optimisation se contentant de tronquer la fin de la chaîne permettrait souvent de « gagner des jetons » tout en supprimant l'erreur insérée. Le test de performance suit donc SIGNAL : chaque sous-chaîne attendue doit toujours apparaître dans le texte visible optimisé.

Résultats de la première étape (optimisation avec perte — les données omises n'étaient pas encore enregistrées) :

* estimé en octets / 4

Les signaux implantés comprenaient :

• ERREUR PaymentService ligne 421 dans le journal des modifications
• authentication check removed et src/Security/AuthGuard.php dans le diff
• l'identifiant du paiement, le statut « échec » et le message d'erreur au format JSON.

L'indicateur clé de performance qui compte n'est pas « combien avons-nous supprimé ? », mais plutôt : les informations nécessaires à la prise de décision ont-elles été préservées ?

JSON : le bruit structuré s’effondre bien

Le format JSON s'est avéré le plus simple. Les clés structurées ont permis à un filtre déterministe de supprimer ou de référencer ultérieurement les données de télémétrie tout en conservant les champs de décision. Une charge utile composée principalement de trames de remplissage et de débogage est passée d'environ 6 800 jetons estimés à quelques dizaines de jetons JSON visibles lors de la première étape, avec la validation du protocole SIGNAL PASS.

C’est là l’avantage structurel du bruit typé : on peut nommer ce qui est jetable.

Journal : la répétition, c'est de l'argent facile — jusqu'à ce que les signaux se rompent

Les journaux sont compressés car les agents voient la même ligne de manière répétée :

[INFO] request started
[INFO] request started
[INFO] request started
[INFO] request started

devient :

[INFO] request started ×4

Les lignes à signal élevé restent inchangées. Cela paraît anodin jusqu'à ce qu'on écrive un test de rétention déterministe. Une version préliminaire utilisait [ERROR] PaymentService ligne 421 alors que le signal attendu était ERROR PaymentService ligne 421. La sous-chaîne échouait à cause du ] entre ERROR et PaymentService. La leçon est simple mais importante : les tests de signal sont sensibles au formatage, et les lignes à signal élevé doivent rester suffisamment stables pour être interprétées par les humains et pour les vérifications.

Différences Git : un résultat utilement faible

La comparaison des différences n'a permis de réduire le temps de traitement que d'environ 24 %. Il ne s'agit pas d'un échec de l'expérience. Si la plupart des données d'entrée contiennent des modifications significatives, le bruit sûr est négligeable. Viser aveuglément une « réduction de 90 % » risquerait de fausser la surface de décision (par exemple, la suppression d'une vérification d'authentification dans AuthGuard.php).

Les différences Git révèlent une limite de compression naturelle. C'est le type de résultat que l'on attend d'un laboratoire : ne pas forcer les choses.

Ce que la première étape a permis de comprendre, en une phrase : la réduction du nombre de jetons sans test de signal est vaine. Un test de signal permet de distinguer « nous avons éliminé le bruit » et « nous avons corrigé l’erreur ».

Propriété manquante : supprimer ≠ détruire

Le premier prototype présentait une faiblesse structurelle. Une fois le contenu supprimé, il disparaissait du contexte actif et devenait inaccessible. Si un agent décidait ultérieurement que les données de télémétrie supprimées étaient pertinentes, il n'y avait rien à récupérer.

Cela nous amène à la deuxième étape importante : REVERSIBLE_CONTEXT_POC.

Principe:

REMOVE FROM CONTEXT
≠
DESTROY INFORMATION

Les optimiseurs renvoient désormais un OptimizeResult :

// OptimizeResult.php
final class OptimizeResult
{
    /**
     * @param list<array{reason: string, content: string, marker_placeholder?: string}> $omissions
     */
    public function __construct(
        public readonly string $visible,
        public readonly array $omissions = [],
    ) {}
}

ContextOptimizer conserve chaque omission sous var/context/ .json` et insère un court marqueur dans le texte visible :

// ContextOptimizer.php (excerpt)
$id = $this->store->makeId($packet->sourcePath, $omission['reason'], $omission['content']);
$ref = new ContextReference(
    id: $id,
    source: $packet->sourcePath,
    type: $packet->type->value,
    reason: $omission['reason'],
    content: $omission['content'],
);
$this->store->put($ref);
// ...
$visible = str_replace($placeholder, $ref->marker(), $visible);

Les identifiants sont déterministes et courts : ctx_ plus les premiers chiffres hexadécimaux de sha256(source|reason|content).

Forme réelle stockée (abrégée) :

{
  "id": "ctx_31154f",
  "source": "fixtures/sample.log",
  "type": "log",
  "reason": "deduplicated repeated lines",
  "content": "[INFO] request started\n..."
}

Le contexte actif ne nécessite que :

#ref:ctx_31154f

Lors de l'exécution grossière du journal, ce marqueur coûte environ quatre jetons estimés tandis que ~3,6k jetons estimés restent hors contexte sur le disque.

La récupération est une commande de console, pas un moteur de recherche :

bin/console tokens:show-ref ctx_31154f

// TokensShowRefCommand.php (excerpt)
$ref = $this->store->get($id);
$io->writeln(sprintf('Source: %s', $ref->source));
$io->writeln(sprintf('Type: %s', $ref->type));
$io->writeln(sprintf('Reason: %s', $ref->reason));
$io->writeln('--- RAW CONTENT ---');
$io->writeln($ref->content);

La fonction ContextStore::get normalise les identifiants #ref:ctx_… ou les identifiants bruts et lit le fichier JSON. La récupération dans le pipeline est exacte au bit près : chaque référence est rechargée et son contenu est comparé à celui écrit lors de l’optimisation.

Pipeline de flux mis à jour

Load
→ Classify
→ MeasureRaw
→ Optimize (+ store refs)
→ MeasureOpt
→ EvaluateSignals
→ EvaluateRecovery

La construction reste un générateur FlowFactory de fermetures sur ContextPacket :

// TokenPipelineFactory.php (excerpt)
return $this->flowFactory->create(static function () use (...) {
    yield static function (ContextPacket $packet): ContextPacket {
        $packet->type = $classifier->classify($packet->raw);
        $packet->addTrace('CLASSIFY', $packet->type->value);
        return $packet;
    };

    yield static function (ContextPacket $packet) use ($optimizer): ContextPacket {
        $optimizer->optimize($packet);
        $packet->addTrace('OPTIMIZE', sprintf('%s refs=%d', $packet->type->value, count($packet->references)));
        return $packet;
    };

    // … MEASURE_OPT, SIGNAL …

    yield static function (ContextPacket $packet) use ($store): ContextPacket {
        foreach ($packet->references as $ref) {
            $loaded = $store->get($ref->id);
            if ($loaded === null || $loaded->content !== $ref->content) {
                $missing[] = $ref->id;
            }
        }
        $packet->recoveryPass = $missing === [];
        $packet->addTrace('RECOVERY', $packet->recoveryPass ? 'PASS' : 'FAIL');
        return $packet;
    };
});

Deux invariants :

1. SIGNAL — Les chaînes de caractères critiques insérées restent dans le texte optimisé visible
2. RÉCUPÉRATION — chaque #ref effectue un aller-retour octet par octet depuis var/context/

Référence réversible

Résultats mesurés actuels :

Comment lire les colonnes :

• BRUT — nombre estimé de jetons de l'entrée originale
• VISIBLE — jetons estimés encore dans le contexte actif (y compris les marqueurs #ref)
• MARQUEURS — coût estimé des marqueurs seuls
• RÉFÉRÉ — jetons estimés stockés hors contexte
• ENREGISTRÉ — réduction du visible par rapport au brut
• SIGNAL / RÉCUPÉRATION — les deux invariants réussite/échec

Le format JSON se compresse toujours fortement (réduction visible d'environ 98 %) tout en conservant les champs de décision et en stockant environ 6 200 jetons estimés derrière des références structurelles. Les différences restent le cas le plus résistant (environ 24 %), avec désormais une seule référence grossière pour le contexte inchangé compressé au lieu de dizaines de micro-références.

Granularité grossière vs granularité fine : la granularité de référence a un coût

Pour les journaux, le test de performance s'exécute avec les deux niveaux de granularité.

Le mode fin a triplé le nombre de références et la surcharge des marqueurs pour économiser environ deux jetons visibles. Pour cette charge de travail, le mode grossier s'est avéré le plus performant : récupération simplifiée, moins d'identifiants à suivre pour l'agent et contexte actif quasi identique.

Ce n'est pas une règle absolue. La granularité doit suivre le modèle de récupération attendu. Les journaux nécessitent souvent un seul bloc contenant toutes les données agrégées. Le JSON structuré exige souvent des références aux positions des champs, afin que le modèle puisse toujours voir où se trouvaient les données de télémétrie.

Émission grossière logarithmique (extrait) :

// LogOptimizer.php (coarse branch excerpt)
$out[] = sprintf('%s ×%d', $prev, $count);
$coarseParts[] = $expanded;
// …
$visible .= "\n\nRepeated informational logs omitted.\n" . $placeholder;
$omissions[] = [
    'reason' => 'deduplicated repeated lines',
    'content' => implode("\n\n", $coarseParts),
    'marker_placeholder' => $placeholder,
];

Références JSON structurelles

Conceptuellement :

{
  "id": 42,
  "status": "failed",
  "error": "PaymentService timeout",
  "telemetry": { "... huge payload ..." }
}

devient :

{
  "id": 42,
  "status": "failed",
  "error": "PaymentService timeout",
  "telemetry": "#ref:ctx_xxxxxx"
}

Le modèle conserve la position sémantique, les identifiants, l'état et les erreurs. Environ six mille jetons de télémétrie restent disponibles hors de la fenêtre. La configuration actuelle fournit neuf références (clés de bruit + remplissage groupé), environ 36 jetons de marqueur, et les instructions SIGNAL PASS et RECOVERY PASS.

C'est plus efficace que la suppression de clés : la structure subsiste même lorsque les valeurs quittent l'invite.

Dans le code, les clés de bruit ne sont pas supprimées ; leurs valeurs deviennent des espaces réservés que ContextOptimizer réécrit ensuite en #ref:…. Les clés de remplissage correspondant à padding_* / noise_* sont regroupées en une seule omission lorsque cela est possible, afin qu'un gros bloc ne se transforme pas en quatre-vingts petites références :

// JsonOptimizer.php (excerpt)
if ($this->isPaddingKey($key)) {
    $paddingBucket[$key] = $item;
    continue;
}

if ($this->isNoiseKey($key)) {
    $placeholder = '{' . '{REF_' . count($omissions) . '}' . '}';
    $omissions[] = [
        'reason' => 'omitted json field: ' . $key,
        'content' => json_encode($item, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT) ?: '',
        'marker_placeholder' => $placeholder,
    ];
    $result[$key] = $placeholder;
    continue;
}

Le JSON visible ressemble donc toujours à la réponse de l'API. C'est important pour les agents qui raisonnent autant sur les noms de champs que sur le texte.

Ceci n'est pas un chiffon

nolife-tokens n'utilise pas d'embeddings, de recherche vectorielle, de récupération sémantique, de bases de données externes, de LangChain, de MCP ou de Redis.

La récupération aujourd'hui est :

reference id → local JSON file → exact bytes

Cette simplicité est intentionnelle. Nous voulons démontrer qu'une réduction structurelle peu coûteuse élimine déjà la majeure partie du gaspillage évident. La recherche sémantique peut attendre que des mesures indiquent sa nécessité.

Implications pour les agents de codage

Un processus plus rigoureux ressemble à ceci :

Tool
  → deterministic reducer
  → high-signal context (+ #ref markers)
  → LLM

          ↓ (only if needed)
     tokens:show-ref / expand
          ↓
       raw source

Cela ne nécessite ni de remplacer Cursor ni d'inventer un autre EDI. Une future intégration pourrait être aussi simple que :

bin/console tokens:context …

et en intégrant le résultat optimisé à un agent existant. L'objectif est d'offrir un meilleur contexte aux outils que nous utilisons déjà, et non de créer une nouvelle interface pour les agents.

Coût et latence (affirmations prudentes)

Réduire le nombre de jetons d'entrée peut diminuer les coûts pour le fournisseur, la charge de prétraitement, la latence et le bruit. Nous n'avons pas comparé ces effets avec une API de fournisseur en production dans le cadre de ce projet. Jusqu'à présent, nous avons mesuré le volume de contexte, la rétention du signal et la récupération. Considérer la réduction du volume comme une réduction de facture avérée serait malhonnête.

Il existe également un effet de second ordre qui importe aux agents : la distraction. Même lorsqu’un modèle « détecte » l’erreur dans un journal de 20 Ko, son attention peut être détournée par les répétitions environnantes. La réduction déterministe ne se résume pas à une simple question d’économie ; elle vise aussi à offrir au modèle une surface de décision plus claire. Cet effet est plus difficile à quantifier que la simple réduction de la taille des fichiers, et nous n’avons pas prétendu le faire ici.

L'utilisation pratique à court terme au sein des flux de travail de type Darkwood reste pour l'instant hors ligne : exécuter tokens:analyze sur un fixture ou un dump d'outil capturé, examiner la trace de la scène et déterminer si le contexte visible est suffisant pour être collé dans Cursor. L'intégration qui intercepte chaque commande shell (à la manière de RTK) est explicitement exclue du périmètre de ces étapes.

Philosophie de l'ingénierie

Avant d'appeler un mannequin, demandez :

PHP peut-il résoudre cette partie de manière déterministe ?

Ce code source inclut : la classification du contenu, la déduplication des journaux, la suppression ou la référence du bruit JSON, la réduction des arborescences de fichiers, la suppression des métadonnées git et du contexte inchangé long, les omissions de hachage, la persistance des références, la mesure des tailles, l’assertion des signaux, l’assertion de récupération.

Composants (responsabilités, pas un simple fichier) :

Modes de défaillance que nous avons déjà rencontrés ou que nous prévoyons

Surcompression

Une ligne, rare mais cruciale, peut se confondre avec du bruit. Les projecteurs de signalisation en captent une partie ; les agents réels repèrent les cas que les projecteurs ne détectent pas.

Explosion de référence

Une première approche de Git générait environ 36 petites références pour les contextes réduits. La surcharge liée aux marqueurs augmentait considérablement et l'expérience utilisateur s'en trouvait dégradée. La solution consistait à utiliser une seule référence globale pour tout le contexte inchangé omis. Mieux vaut moins de références utiles que de nombreuses micro-références.

Perte sémantique

La préservation d'une chaîne de caractères ne garantit pas toujours sa bonne interprétabilité. Un code d'état sans contexte narratif peut encore perturber un modèle. Les filtres déterministes optimisent le volume et les signaux explicites, et non la compréhension.

Fausse confiance de bytes / 4

Les pourcentages comparatifs sont fiables pour ce laboratoire. Les « économies absolues sur la facture » ​​ne le sont pas.

Dépendance de récupération

Une fois que l'agent s'appuie sur #ref, il faut lui apprendre à développer cette fonctionnalité. Actuellement, c'est un humain qui exécute tokens:show-ref. La divulgation progressive automatique est la prochaine étape expérimentale ; il ne s'agit pas d'une fonctionnalité finalisée.

Collisions d'identification et hygiène des magasins

Les identifiants de référence sont adressables par contenu. Les collisions avec un contenu différent augmentent la longueur du hachage et génèrent une erreur. Les collisions avec un contenu identique sont réécrites de manière idempotente. Le stockage se trouve dans le répertoire var/, ignoré par Git ; il s'agit d'un cache d'espace de travail, et non d'une base de connaissances persistante. Cela convient pour une preuve de concept, mais s'avère insuffisant pour la mémoire de production multi-utilisateurs — une raison supplémentaire de ne pas confondre cela avec la persistance de type Claude-mem.

Posture de sécurité

Considérez le contenu analysé comme des données, et jamais comme des instructions à exécuter. Les optimiseurs ne font que réécrire les chaînes de caractères. Les journaux et les fichiers JSON peuvent contenir du texte ressemblant à des directives d'agent (« ignorer les instructions précédentes… »). Le pipeline ne doit en aucun cas interpréter ce texte comme un élément de contrôle. Aujourd'hui, il s'agit principalement d'une question d'implémentation : pas d'évaluation, pas d'analyse du contenu, et surtout, ne vous fiez pas aux instructions de test comme à une politique.

Ce que nous avons délibérément omis

Il est utile de lister les objectifs secondaires pour que l'expérience reste lisible :

• Pas de résumé des sections omises basé sur LLM (pour l'instant). Les résumés seraient incomplets d'une autre manière et plus difficiles à reconstituer exactement.
• Pas de crochet de curseur automatique ni d'interception de shell
• Absence de système d'empaquetage contextuel permettant de choisir parmi vingt candidats sous une limite de 4 Ko (conçu plus tard dans la feuille de route initiale, non implémenté).
• Aucune suite de tests PHPUnit n'est utilisée ; tokens:benchmark constitue la surface de validation.
• Aucune affirmation selon laquelle les jetons estimés correspondent aux compteurs de facturation d'OpenAI/Anthropic

Le fait de les omettre fait partie de la méthode : évaluer l’idée de réduction réversible avant d’y superposer des produits.

Suivant : divulgation progressive

La suite logique :

LEVEL 0  tiny overview
   ↓
LEVEL 1  selected section / #ref expansion
   ↓
LEVEL 2  raw original source

Exemple de croquis :

Application failed during checkout.
1 PaymentService error.
telemetry omitted.
#ref:ctx_payment

Si nécessaire : développer la référence. Uniquement si nécessaire : données brutes complètes. Le contexte est désormais déterminé par la demande plutôt que par l’envoi systématique du journal complet.

C’est là que nolife-tokens cesse d’être seulement un compresseur et devient une expérience en matière d’architecture de contexte.

Schématiquement :

                    ┌─────────────────────┐
   raw tool dump ─► │ classify + optimize │ ─► visible context (+ #ref)
                    └──────────┬──────────┘
                               │ omissions
                               ▼
                        var/context/*.json
                               │
              expand / show-ref │ (on demand)
                               ▼
                         original bytes

Aujourd'hui, la flèche vers le bas est manuelle. La divulgation progressive l'intègre à la boucle de l'agent : d'abord une vue d'ensemble, puis les extensions choisies, puis les données brutes uniquement lorsque les couches moins coûteuses échouent.

Conclusion

Les grandes fenêtres de contexte incitent à la facilité : tout envoyer. La question technique passe de « quelle quantité de données le modèle peut-il accepter ? » à :

Quel est le contexte minimal nécessaire à la prise de décision correcte, et à quel coût pouvons-nous récupérer le reste ?

Deux étapes importantes concernant les jetons nolife sont déjà visibles, avec des mesures :

• Des réductions déterministes importantes sont possibles pour les journaux bruités et les fichiers JSON
• la rétention du signal peut être testée comme un invariant de première classe
• les données omises peuvent être récupérées octet par octet.
• La granularité de référence elle-même a un coût mesurable (une granularité grossière est préférable à une granularité fine sur notre configuration logarithmique).
• Les types de contenu ont des limites de compression naturelles différentes (les différences Git sont d'environ 24 % ici).

Le problème n'est pas résolu. Les questions de coût pour les prestataires, d'expansion pilotée par les agents et de divulgation progressive restent à explorer. Le laboratoire est volontairement de petite taille : suffisamment petit pour que chaque mécanisme demeure compréhensible, ce qui, pour les systèmes contextuels, est peut-être l'objectif principal.

Commandes utilisées dans ce travail

bin/console tokens:analyze fixtures/sample.log
bin/console tokens:analyze fixtures/sample.log --granularity=fine
bin/console tokens:analyze fixtures/sample.json
bin/console tokens:analyze fixtures/sample.diff
bin/console tokens:benchmark
bin/console tokens:show-ref ctx_31154f

Code source

Dépôt : https://github.com/matyo91/nolife-tokens
Slides: https://github.com/matyo91/slidewire