Aller au contenu
300+ modèles · 15+ fournisseurs
Chat, images, embeddings compatibles OpenAI
Tokens container-NAME · révocation instantanée
Marge transparente de 5% sur le coût fournisseur
Apporte votre propre fournisseur · zéro lock-in
Chaîne MITM via hoody-exec · 40 à 70% d'économies
300+ modèles · 15+ fournisseurs
Chat, images, embeddings compatibles OpenAI
Tokens container-NAME · révocation instantanée
Marge transparente de 5% sur le coût fournisseur
Apporte votre propre fournisseur · zéro lock-in
Chaîne MITM via hoody-exec · 40 à 70% d'économies
300+ modèles · 15+ fournisseurs
Chat, images, embeddings compatibles OpenAI
Tokens container-NAME · révocation instantanée
Marge transparente de 5% sur le coût fournisseur
Apporte votre propre fournisseur · zéro lock-in
Chaîne MITM via hoody-exec · 40 à 70% d'économies
300+ modèles · 15+ fournisseurs
Chat, images, embeddings compatibles OpenAI
Tokens container-NAME · révocation instantanée
Marge transparente de 5% sur le coût fournisseur
Apporte votre propre fournisseur · zéro lock-in
Chaîne MITM via hoody-exec · 40 à 70% d'économies
Hoody Platform

300+ modèles IA. Une seule URL compatible OpenAI.

ai.hoody.com tourne sur votre bare-metal. Change la base URL dans n'importe quel client OpenAI et votre code marche avec Claude, GPT, Gemini, Llama ou n'importe lequel des 15+ fournisseurs d'inférence.

Les conteneurs s'authentifient avec des tokens container-NAME — aucune vraie clé API dans vos workloads. Supprimez un conteneur et son accès IA disparaît avec lui.

300+ modèles15+ fournisseursCompatible OpenAIMarge de 5%
N'importe quel code compatible OpenAI

# Avant (OpenAI direct)

from openai import OpenAI

 

client = OpenAI(

base_url="https://api.openai.com/v1",

api_key="sk-..."

)

Pointez-le vers ai.hoody.com

# Après (Hoody AI Gateway)

from openai import OpenAI

 

client = OpenAI(

base_url="https://ai.hoody.com/api/v1",

api_key="container-dev-env"

)

Le catalogue de fournisseurs

15+ fournisseurs d'inférence. Une seule API.

Génération de texte, génération d'images, embeddings. Chaque grand fournisseur que vous auriez sinon dû brancher séparément.

AnthropicTexte

Famille Claude — Opus, Sonnet, Haiku

OpenAITexte

Famille GPT — modèles phares et tiers optimisés coût

GoogleTexte

Famille Gemini via Vertex AI

MetaTexte

Famille Llama — hébergée chez des partenaires d'inférence

MistralTexte

Modèles open-weight Mistral + Mixtral

DeepseekTexte

V3 et famille Coder

QwenTexte

Alibaba Qwen — 72B et raisonnement QwQ

CohereEmbed

Famille Command R plus embeddings

xAITexte

Famille Grok — incluant le tier vision

PerplexityTexte

Modèles Sonar avec ancrage web en direct

Together AITexte

Plateforme d'hébergement pour modèles open-weight

Fireworks AITexte

Inférence optimisée pour modèles open-weight

300+ modèles au total. Bring Your Own Provider (§5 ci-dessous) étend ça aux clés directes et endpoints locaux/privés. Catalogue complet dans les docs.

Auth conteneur-native

Aucune vraie clé API dans vos conteneurs.

Chaque conteneur reçoit une clé virtuelle liée à son nom : `container-NAME`. Le token ne fonctionne que depuis l'infra où il a été émis. Supprime le conteneur — le token devient instantanément inutile.

Intégration IA traditionnelle

  • Vraie clé API sk-... stockée en env
  • Les fuites survivent dans l'historique git, les logs, Slack
  • La rotation exige une mise à jour coordonnée sur tous les workloads
  • La révocation tue tout ce qui utilise cette clé

Hoody AI gateway

  • Token container-NAME émis automatiquement à la création du conteneur
  • Le token ne fonctionne que depuis l'intérieur du conteneur
  • Rotation = recréer le conteneur avec le même nom
  • Supprimez le conteneur = ce conteneur disparaît, sa clé aussi

Sûr pour passer à un freelance, pour les side-projects vibe-codés et le SaaS grand public. Le gateway tourne sur votre bare-metal — Hoody ne voit jamais vos prompts ni vos réponses. Zero-knowledge par architecture, pas par politique.

Couche MITM

Interceptez chaque requête IA. Empilez les couches dans l'ordre.

Routez le gateway via hoody-exec pour insérer du middleware avant l'appel au fournisseur. Mettez en cache les réponses pas chères. Injectez du contexte. Routez vers le bon modèle. Verrouillez les tool calls destructeurs derrière une approbation humaine. Diffusez vers d'autres agents. Loguez tout. L'ordre est un pipeline — chaque couche s'exécute avant la suivante, et vous choisissez celles qu'il vous faut.

votre apphoody-exec (pipeline MITM)ai.hoody.comfournisseur (Anthropic, OpenAI, …)

1 · Cache de réponses

Hashez le prompt ; sautez l'inférence sur un hit. La couche la moins chère en premier.

2 · Injection de contexte

Préfixe les system prompts depuis votre base de connaissances avant l'appel.

3 · Routing par coût

Prompts faciles → modèles moins chers. Prompts difficiles → Claude. 40 à 70% d'économies documentées.

4 · Manipulation des tool calls

Réécris ou bloque les tool calls avant exécution. Sandbox les écritures fichier.

5 · Human-in-the-loop

Bloquez les actions à fort enjeu. Envoyez une notification. Attendez l'approbation.

6 · Cascade d'agents

Déclenche un autre hoody-agent en HTTP. Systèmes multi-agents sans orchestrateur.

7 · Journal d'audit

Chaque requête + réponse vers SQLite pour la conformité et le debug.

Le moteur de règles intégré couvre les patterns MITM courants sans une ligne de code. Bascule sur des scripts hoody-exec custom quand une règle ne suffit pas.

Zéro lock-in

Apporte votre propre fournisseur. Sors du keyless.

L'auth keyless est le défaut et la voie sûre. Mais vous n'êtes jamais enfermé : routez directement vers n'importe quel endpoint compatible OpenAI — Ollama local, Azure OpenAI, inférence Hugging Face, un proxy entreprise ou des clés fournisseur directes — en réglant les variables d'env dans le container. C'est le opt-out explicite du keyless, pas un mode parallèle.

Environnement du conteneur — opt-out du keyless

# direct provider keys

ANTHROPIC_API_KEY=sk-ant-...

OPENAI_API_KEY=sk-...

 

# point at local Ollama

OPENAI_BASE_URL=http://localhost:11434/v1

 

# or Azure / enterprise proxy

OPENAI_BASE_URL=https://your-proxy.internal/v1

Clés fournisseur directes (bypass gateway)Ollama local (OPENAI_BASE_URL)Azure OpenAIProxy entreprise compatible OpenAI
vs gateways IA commerciaux

Ce que vous assembleriez sinon à la main

LiteLLM, Portkey, OpenRouter et les comptes fournisseurs directs résolvent chacun une partie de ce que le gateway résout dans une seule surface tournant sur votre propre matériel.

SujetHoody AI GatewayGateway commercial / DIY
Où ça tournesupporté nativementvotre bare-metalCloud du vendeur (LiteLLM SaaS, Portkey)
Auth scopée par conteneursupporté nativementTokens container-NAMEClés API partagées + RBAC
Apporter votre propre fournisseursupporté nativementN'importe quel endpoint compatible OpenAISouvent oui, varie selon le vendeur
Règles MITM + scriptssupporté nativementMoteur de règles intégré + scripts hoody-execTier payant ou proxy externe
Compatible OpenAIsupporté nativementOuiOui (la plupart des alternatives)
Tarificationsupporté nativementMarge de 5% sur le coût fournisseurFrais par appel + SaaS par siège
Intégré à l'infra + walletsupporté nativementUn wallet, une seule surface APIFacturation et ops séparées

Quand votre stack tourne déjà sur LiteLLM ou OpenRouter et que vous ne voulez pas faire tourner un gateway, ces solutions restent meilleures. Le Hoody AI Gateway prend tout son sens quand vous voulez de l'auth scopée par conteneur, du MITM natif et le modèle wallet à deux balances — la General Balance finance le serveur (Stripe/crypto/virement), l'AI Balance finance le gateway, avec des transferts unidirectionnels General → AI et une seule facture pour les deux.

Démarrer

Claude en un changement de base_url.

Crée un conteneur, mets la base URL sur https://ai.hoody.com/api/v1, utilise container-NAME comme bearer. Toutes les bibliothèques compatibles OpenAI savent déjà quoi faire.

Catalogue des modèles

Voir aussi — /platform/control-plane pour l'émission des tokens et le wallet, /platform/proxy pour la couche URL en dessous.