Skip to content

Conventions

Base de format

Les endpoints de chat consomment et renvoient du JSON. En mode streaming, la reponse est diffusee en text/event-stream.

Champ model

Le champ model est obligatoire et doit suivre l’un de ces formats:

text
group:<uuid>
custom:<uuid>

Exemple:

text
group:123e4567-e89b-12d3-a456-426614174000
custom:123e4567-e89b-12d3-a456-426614174111

Les cibles group:<uuid> peuvent utiliser les modes auto, normal, orch ou synth. Les cibles custom:<uuid> fonctionnent toujours en mode normal. Si une cible custom recoit metadata.mode avec orch ou synth, l’API renvoie 400.

Messages

La requete attend un tableau messages.

Roles acceptes:

  • system
  • user
  • assistant
  • tool

Regle importante:

  • le tableau doit contenir au moins un message user
  • le dernier message user porte la demande en cours
  • les messages tool sont acceptes pour compatibilite mais ne sont pas transmis comme historique de chat
  • tool_call_id est optionnel et peut contenir jusqu’a 200 caracteres

Formats de contenu

Le champ content d’un message peut etre:

  • une chaine
  • null
  • un tableau de blocs contenant des proprietes comme type et text

Streaming

Si stream vaut true, l’API renvoie des evenements SSE.

Le flux suit en pratique cette logique:

  1. un premier chunk initialise la reponse assistant
  2. des chunks ajoutent du texte dans choices[0].delta.content
  3. un chunk final ferme la reponse
  4. le flux se termine avec data: [DONE]

metadata

Le champ metadata est optionnel. Il est utile notamment pour:

  • fournir un identifiant request_id
  • indiquer un mode via metadata.mode

Valeurs de metadata.mode prises en charge:

  • auto
  • normal
  • orch
  • synth

Les champs inconnus de la requete sont ignores. Les champs pris en charge sont listes sur chaque page d’endpoint.

Effort de raisonnement

L’effort de raisonnement peut etre transmis de trois facons:

  • reasoning_effort: s’applique a la cible brain
  • reasoning.effort: forme objet compatible OpenAI, s’applique aussi a la cible brain
  • reasoning_effort_overrides: objet qui associe des identifiants de cible comme brain ou agent:0 a un effort

Valeurs acceptees:

  • none
  • minimal
  • low
  • medium
  • high
  • xhigh
  • max

Les valeurs explicites de reasoning_effort_overrides ont priorite sur reasoning_effort et reasoning.effort.

Identifiants de requete

Les clients peuvent envoyer x-request-id avec des lettres, chiffres, ., _, : ou -, jusqu’a 128 caracteres. L’API renvoie l’identifiant retenu dans le meme en-tete et dans les erreurs.

metadata.request_id peut aussi fournir un identifiant applicatif. Quand il est present et non vide, il est utilise dans les metadonnees d’execution Kitemesh.

Limites de saisie utiles

  • messages: entre 1 et 500 elements
  • temperature: entre 0 et 2
  • max_tokens: entre 1 et 200000
  • max_completion_tokens: entre 1 et 200000
  • denied_tools[].reason: jusqu’a 2000 caracteres
  • approved_tool_execution_ids et denied_tools: jusqu’a 200 elements chacun sur les requetes de reprise

Si max_tokens et max_completion_tokens sont fournis ensemble, preferez max_completion_tokens pour exprimer clairement la limite souhaitee.