GLM 5.3 : vérifier les contrats entre plusieurs fichiers

Exemple API minimal

Code Python illustratif, pas une réponse exécutée. La clé vient de l’environnement et les relances automatiques sont désactivées. Une coupure peut laisser le résultat et le coût inconnus : ne relancez pas à l’aveugle.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-glm-5-3",
    max_tokens=512,
    messages=[{"role": "user", "content": "Crée une liste de vérification pour ma tâche. Sépare les faits des hypothèses."}],
)
print(response.choices[0].message.content)

Dessiner la frontière du changement avant les fichiers

Supposons une application où un formulaire transmet une commande à un service, qui la convertit avant enregistrement. Écrivez le trajet réel : composant, validateur, service et stockage. Pour chaque étape, précisez les données qu'elle reçoit et celles qu'elle promet. Ce plan permet de sélectionner les fichiers indispensables au changement au lieu de joindre un ensemble volumineux dont les relations restent implicites.

Marquez les contrats publics : nom d'un champ JSON, type d'une erreur ou comportement attendu lorsqu'une valeur manque. Ajoutez les éléments qui ne doivent pas changer, tels que la lecture d'anciens enregistrements. La demande n'est alors plus « refactorise ce projet », mais « vérifie que cette modification conserve ces contrats ». Cette précision crée des critères de relecture indépendants du style de la réponse.

Fournir des fichiers identifiables et cohérents

Présentez chaque extrait avec son chemin, sa version et son rôle. Un import local manquant doit être signalé ; sinon, le modèle risque d'inventer son comportement. Pour une signature appelée dans plusieurs endroits, fournissez les usages représentatifs et dites lesquels restent absents. Gardez les numéros de ligne comme aides à la revue, sans les traiter comme des références immuables après application du diff.

Le contexte déclaré de 1048576 jetons ne signifie pas que le navigateur transmet toute l'histoire ou accepte un dépôt sans limite. Les contraintes de messages, de fichiers et de corps JSON demeurent séparées. Préparez un dossier autonome qui contient les contrats décisifs. Si une image de diagramme est utilisée, son passage par un pont textuel payant doit être distingué de la vision native, absente ici.

Faire examiner les invariants dans les deux directions

Demandez une lecture de l'entrée vers le stockage, puis du stockage vers l'affichage. Un renommage peut être correctement écrit mais mal relu par un ancien composant. Pour chaque invariant, exigez un parcours concret : valeur initiale, transformation, valeur finale et point de contrôle. Les assertions vagues sur la cohérence globale ne suffisent pas pour approuver une modification de format.

Ajoutez les chemins d'erreur et les anciennes données à la même grille. Un champ optionnel peut devenir obligatoire uniquement sur un parcours rare. Faites classer les constats entre défaut démontré par l'extrait, risque dépendant d'un fichier absent et choix de conception à discuter. Cette séparation aide à ne pas appliquer une correction invasive destinée à résoudre un défaut seulement supposé.

Choisir effort et sortie sans leur attribuer un résultat

Cette identité déclare low, high et max pour reasoning_effort. Choisissez le réglage explicitement si votre scénario en a besoin et gardez-le dans votre fiche de comparaison. Un niveau plus élevé n'est pas une garantie de meilleur diff, de réussite des tests ou de latence donnée. N'extrapolez pas ces niveaux aux paliers Flash, Pro et Pro 2 à partir de leurs noms.

Fixez aussi un plafond de sortie compatible avec une revue ciblée : liste des contrats, anomalies et tests proposés. Si la réponse est tronquée, ne l'appliquez pas comme un correctif complet. Le budget de sortie et le contexte d'entrée sont différents ; le raisonnement peut occuper une partie de l'usage de sortie, sans produire autant de texte final visible qu'un simple comptage de mots le laisserait croire.

Garder l’exécution et les outils dans leur vrai périmètre

Demandez des commandes de validation adaptées au dépôt, puis vérifiez leur existence avant de les lancer vous-même. Le modèle ne doit pas présenter une suite comme réussie parce qu'il a écrit ses commandes. Un client IDE peut disposer d'outils autorisés, mais cette capacité appartient à l'intégration. La recherche explicite du navigateur payant n'ajoute pas automatiquement un outil Internet à une requête de l'API publique.

Pour maîtriser un appel Python, max_retries=0 désactive la politique de répétition automatique documentée par le SDK. Le client doit conserver la différence entre statut HTTP connu et rupture réseau, que MDN décrit pour Fetch. Ces références ne prouvent aucune performance de GLM 5.3. Une issue inconnue peut conserver un coût réservé ; elle ne permet pas de promettre une nouvelle tentative gratuite.

Valider le changement aux frontières réelles

Construisez un petit plan d'acceptation : une entrée normale, une donnée historique, une erreur de validation et un consommateur qui attend encore l'ancien contrat. Exécutez les tests dans votre environnement et examinez le diff final, y compris les fichiers que le modèle n'a pas vus. Une revue multifichier reste incomplète si elle vérifie chaque fichier isolément sans faire passer une donnée entre eux.

Avant de transférer votre consigne, vérifiez que seller-glm-5-3 est réellement autorisé dans le sélecteur. Le compte de démo Pro 2 ne donne pas un droit général à ce modèle. Le transfert prépare seulement un brouillon et un brouillon existant peut prévaloir. Conservez ensuite les résultats observés et les points non testés ; ils constitueront le dossier de la prochaine revue, pas une promesse de cette page.

Questions et réponses

Pourquoi ne pas simplement envoyer tout le dépôt ?

Un dépôt complet peut contenir beaucoup de données sans rapport avec la décision et dépasser les limites du client avant celles du modèle. Sélectionnez les contrats et leurs usages, identifiez les omissions et fournissez des versions cohérentes. La couverture se démontre par les frontières examinées, pas par le volume envoyé.

High ou max garantit-il une correction plus fiable ?

Aucune garantie de ce type n'est établie ici. Ces valeurs sont des niveaux d'effort déclarés pour seller-glm-5-3, pas un classement mesuré des résultats. Gardez le réglage constant pour une évaluation et jugez les contrats préservés, les tests exécutés et le coût constaté plutôt qu'une étiquette.

Peut-on reprendre les paramètres de Pro 2 sans changement ?

Non : seller-pro-2 est une version modifiée fondée sur GLM-5.3 mais reste une identité distincte. La démonstration, les paramètres et les tarifs doivent être lus pour l'entrée choisie. Un nom de famille commun ne prouve pas que deux requêtes auront le même comportement ou les mêmes droits d'accès.

Que vérifier après un correctif proposé sur plusieurs fichiers ?

Vérifiez d'abord les chemins et les imports, puis les contrats entre composants et les formats persistés. Lancez les tests de reproduction et les régressions concernées dans votre projet. Signalez ce qui manque ou n'a pas été exécuté ; une analyse en langage naturel ne remplace ni compilation ni test d'intégration réel.

Sources

Contenu préparé avec l’aide de l’IA. Les exemples sont illustratifs, pas des réponses réelles ni des tests comparatifs. Les sources externes ne remplacent pas les conditions du service.

• Documentation Dikaya : requêtes et limites
  dikaya.cc
• Catalogue Dikaya : identités et modalités
  dikaya.cc
• Tarifs Dikaya : conditions de calcul
  dikaya.cc
• SDK Python OpenAI : politique de nouvelles tentatives
  github.com
• MDN : réponses HTTP, erreurs réseau et Fetch
  developer.mozilla.org