FR ▾

API LLM sans censure compatible OpenAIuncensoredapis.com

AccueilRéférence API

Référence Uncensored API expliquée champ par champ

Cette page documente chaque champ que vous enverrez à ou recevrez de Uncensored API : le corps de la requête de complétions de chat, l'objet de réponse, les valeurs finish_reason, le bloc d'utilisation, les chunks de streaming et la liste des modèles. Chaque section associe une courte spécification à un exemple annoté que vous pouvez coller dans un terminal et exécuter.

Mis à jour le

Points clés

  1. Il existe deux endpoints : POST /v1/chat/completions et GET /v1/models. Les deux s'authentifient avec une clé Bearer.
  2. La réponse suit la forme familière de complétion de chat : id, choices[].message, finish_reason et usage.
  3. Le streaming utilise les événements envoyés par le serveur ; un chunk final transporte l'utilisation automatiquement et le flux se termine avec data: [DONE].
  4. Limites qui façonnent les requêtes : fenêtre de contexte de 100 000 tokens, 2048 par défaut et 32 000 maximum pour max_tokens, corps de 8 Mo.

Conventions et transport

L'URL de base est https://api.uncensoredapis.com/v1. Tous les corps sont en JSON et UTF-8. Chaque requête transporte Authorization: Bearer <key> ; une clé manquante ou incorrecte renvoie 401. Seules deux routes existent, et tout autre chemin renvoie 404.

MéthodeCheminObjectif
POST/v1/chat/completionsGénérer un message de l'assistant, éventuellement en streaming
GET/v1/modelsLister l'ID de modèle que vous pouvez demander

L'API est uniquement textuelle. Il n'y a pas de routes pour les embeddings, les images, l'audio ou la vidéo, ni de fine-tuning, et il n'y a qu'un seul modèle, adressé comme uncensored. Parce que le format filaire est compatible avec la convention des complétions de chat, les SDK Python et Node officiels fonctionnent lorsque vous remplacez base_url. Les docs couvrent la configuration de première exécution ; cette page est le compagnon au niveau des champs.

Champs du corps de la requête

Le tableau liste les champs compris par l'endpoint. Les champs d'échantillonnage sont transmis à la génération sans modification, donc les valeurs que vous choisissez se comportent comme dans n'importe quelle API de type chat-completions.

ChampTypeNotes
modelstringToujours "uncensored".
messagesarrayObjets ordonnés avec role (system, user, assistant, tool) et content.
max_tokensintegerCap de complétion. Par défaut 2048, maximum 32 000.
temperaturenumberAléatoire. Plus bas est plus déterministe.
top_pnumberCoupe d'échantillonnage du noyau.
stopstring or arraySéquences qui terminent la génération.
streambooleantrue bascule la réponse vers les événements envoyés par le serveur.
toolstableauDéfinitions de fonctions au format standard JSON-schema.

Voici une requête annotée complète. Le message système définit le comportement, le message utilisateur porte la tâche, et stop met fin à la génération à la première ligne vide.

curl https://api.uncensoredapis.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [
      {"role": "system", "content": "You are a terse release-notes writer."},
      {"role": "user", "content": "Summarize: fixed login bug, added dark mode."}
    ],
    "max_tokens": 120,
    "temperature": 0.4,
    "stop": ["\n\n"]
  }'

Deux règles de budget sont importantes. Premièrement, le prompt plus la complétion doivent tenir dans 100 000 tokens, donc une requête dont les tokens de prompt plus max_tokens dépassent ce seuil est rejetée avec un 400. Deuxièmement, le corps sérialisé ne peut pas dépasser 8 Mo. Si vous envoyez de longues historiques, réduisez les anciennes tours de votre côté avant qu'elles n'approchent l'une ou l'autre limite.

L'objet de réponse

Un appel non en streaming renvoie un seul objet JSON. Lisez-le de haut en bas comme suit.

{
  "id": "chatcmpl-example123",
  "object": "chat.completion",
  "created": 1767225600,
  "model": "uncensored",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "v1.4: Login bug fixed. Dark mode added."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 38,
    "completion_tokens": 14,
    "total_tokens": 52
  }
}
  • id : un identifiant unique pour la complétion. Enregistrez-le à côté de votre propre id de requête lorsque vous devez corréler les événements.
  • object : la constante chat.completion.
  • created : horodatage Unix en secondes.
  • model : fait écho à uncensored.
  • choices : un tableau. Vous recevez une entrée, donc choices[0] est la réponse. index est sa position.
  • choices[].message : role est assistant ; content contient le texte, ou est null lorsque le modèle a retourné des tool_calls à la place.
  • choices[].finish_reason : raison pour laquelle la génération s'est arrêtée ; voir la section suivante.
  • usage : comptabilité des tokens pour la facturation, couverte ci-dessous.

Valeurs de finish_reason

Embranchement sur finish_reason avant de faire confiance au contenu. Une réponse tronquée et une réponse complète se ressemblent jusqu'à ce que vous la vérifiiez.

ValeurSignificationCe que votre code doit faire
stopLe modèle a atteint une fin naturelle ou a déclenché l'une de vos séquences stop.Utilisez le contenu tel quel.
lengthLa limite max_tokens (ou la fenêtre de contexte) a été atteinte en cours de réponse.Augmentez max_tokens, raccourcissez le prompt, ou demandez au modèle de continuer.
tool_callsLe modèle souhaite exécuter une ou plusieurs fonctions.Exécutez-les et envoyez les résultats en retour en tant que messages tool.

Lorsque la valeur est tool_calls, le message ressemble à ceci, avec les arguments livrés sous forme de JSON string que vous devez analyser vous-même :

{
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "id": "call_abc1",
        "type": "function",
        "function": {"name": "get_order", "arguments": "{\"order_id\": 8841}"}
      }]
    },
    "finish_reason": "tool_calls"
  }]
}

Enveloppez toujours json.loads ou JSON.parse sur arguments dans la gestion des erreurs, car le JSON généré peut occasionnellement être mal formé.

Le bloc d'utilisation et ce qu'il coûte

usage rapporte prompt_tokens, completion_tokens et total_tokens. Ce sont les nombres contre lesquels votre solde est débité : entrée à $0,25 par million de tokens et sortie à $1,00 par million. Le solde prépayé est déduit par requête, sans abonnement.

Un exemple résolu sous les hypothèses déclarées : supposons qu'une requête utilise 2 000 tokens de prompt et 500 tokens de complétion. Le coût d'entrée est 2 000 / 1 000 000 x $0,25 = $0,0005. Le coût de sortie est 500 / 1 000 000 x $1,00 = $0,0005. La requête totalise $0,0010. Ces nombres de tokens sont des hypothèses pour l'arithmétique, pas une mesure de toute charge de travail réelle. La page tarification a les taux en un seul endroit.

Puisque les tokens de sortie coûtent quatre fois plus cher que les tokens d'entrée, un max_tokens serré est votre contrôle de coût le plus direct.

Format du chunk en streaming

Définissez "stream": true et la réponse devient text/event-stream. Chaque événement est une ligne commençant par data: suivie de JSON, séparée par une ligne vide. Le type d'objet change vers chat.completion.chunk et message est remplacé par delta.

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"role":"assistant","content":""},"finish_reason":null}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"v1.4: "},"finish_reason":null}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"Login bug fixed."},"finish_reason":null}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[{"index":0,"delta":{},"finish_reason":"stop"}]}

data: {"id":"chatcmpl-example123","object":"chat.completion.chunk","choices":[],"usage":{"prompt_tokens":38,"completion_tokens":14,"total_tokens":52}}

data: [DONE]
  1. Le premier chunk définit généralement delta.role à assistant avec un contenu vide.
  2. Les chunks de contenu portent un fragment dans delta.content. Concaténez-les dans l'ordre d'arrivée.
  3. Le chunk de contenu de clôture a un delta vide et un finish_reason non nul.
  4. Un dernier chunk avec un tableau choices vide porte usage. Vous ne le demandez pas ; il est ajouté automatiquement.
  5. La chaîne littérale data: [DONE] termine le flux.

Protégez-vous contre ce tableau choices vide : indexer choices[0] sur le chunk d'utilisation génère une erreur dans les boucles simples. L'exemple de SDK ci-dessous le gère.

import os
from openai import OpenAI

client = OpenAI(base_url="https://api.uncensoredapis.com/v1", api_key=os.environ["API_KEY"])

reason, usage = None, None
for chunk in client.chat.completions.create(
    model="uncensored",
    messages=[{"role": "user", "content": "Name three uses of a rubber duck in debugging."}],
    stream=True,
):
    if chunk.choices:
        piece = chunk.choices[0].delta.content
        if piece:
            print(piece, end="", flush=True)
        if chunk.choices[0].finish_reason:
            reason = chunk.choices[0].finish_reason
    if getattr(chunk, "usage", None):
        usage = chunk.usage

print("\nfinish:", reason, "| tokens:", usage.total_tokens if usage else "n/a")

Pour les tool_calls en streaming, delta.tool_calls arrive en fragments ; accumulez la chaîne arguments par index d'appel et analysez une fois finish_reason est tool_calls.

L'endpoint des modèles

GET /v1/models nécessite uniquement l'en-tête Bearer et renvoie un objet liste. Comme il n'y a qu'un seul modèle, data contient une seule entrée, uncensored. Les clients qui remplissent une liste déroulante de modèles à partir de cette route afficheront donc un seul choix.

curl https://api.uncensoredapis.com/v1/models -H "Authorization: Bearer $API_KEY"

{
  "object": "list",
  "data": [
    {"id": "uncensored", "object": "model"}
  ]
}

C'est aussi le moyen le moins cher de vérifier une clé : un 200 signifie que la clé est valide, un 401 signifie qu'elle est incorrecte ou a été régénérée. Appeler cette route ne génère pas de tokens. Pour la gestion des statuts et les règles de retry, consultez le playbook erreurs et limites de débit.

Liste de contrôle de référence pour les auteurs de clients

Si vous écrivez une bibliothèque cliente ou enveloppez l'endpoint dans une passerelle, vérifiez chacun de ces comportements par rapport à la spécification ci-dessus avant la mise en production.

  1. Propreté des en-têtes. Envoyez la clé uniquement dans l'en-tête Authorization, jamais dans la chaîne de requête, et ne journalisez jamais la valeur de l'en-tête.
  2. Analysez de manière défensive. Traitez les champs supplémentaires inconnus dans les réponses comme ignorables. Liez votre analyseur aux champs documentés ici plutôt qu'à l'ordre exact des clés JSON.
  3. Vérifiez finish_reason sur chaque réponse. Affichez un indicateur visible lorsqu'il est égal à length, car les utilisateurs lisent autrement du texte coupé comme une réponse complète.
  4. Budget avant l'envoi. Estimez les tokens du prompt, ajoutez votre max_tokens, et comparez la somme avec 100 000. Rejeter localement est plus rapide qu'attendre un 400.
  5. Gérez la queue du stream. Attendez un chunk avec une liste choices vide et un objet usage, puis [DONE]. Fermez la connexion après le sentinelle.
  6. Enregistrez l'utilisation. Stockez total_tokens par requête afin que vous puissiez réconcilier votre propre comptage contre le solde prépayé plus tard.
  7. Respectez le plafond. Le compte autorise 300 requêtes par minute par clé, donc une passerelle qui diffuse à de nombreux utilisateurs a besoin de sa propre file d'attente.

Aucune de ces étapes ne dépend d'un SDK fournisseur. Un client HTTP simple qui définit l'en-tête Bearer et décode du JSON est suffisant, et les exemples de SDK sur cette page sont des commodités, pas des exigences. Associez cette liste de contrôle avec le tableau d'erreurs dans le playbook et vous couvrez tout le cycle de vie de la requête : construire, envoyer, streamer, analyser, comptabiliser et récupérer.

Questions et réponses

Puis-je obtenir plus d'un choix par requête ?

Attendez-vous à une seule entrée dans choices et lisez choices[0]. Si vous voulez des alternatives, émettez des requêtes séparées.

Pourquoi message.content est null ?

Le modèle a renvoyé tool_calls au lieu de texte. Vérifiez finish_reason, exécutez les fonctions et renvoyez les résultats.

Que se passe-t-il si prompt plus max_tokens dépasse 100 000 ?

La requête est rejetée avec une erreur 400 bad request. Réduisez le prompt ou abaissez max_tokens.

Le streaming change-t-il le prix ?

Non. La facturation utilise les mêmes comptes de tokens de prompt et de complétion, et le chunk d'utilisation final les rapporte.

Votre clé est à un formulaire de vous

Créez un compte, copiez la clé, changez l'URL de base. C'est toute la configuration.