Documentation

twinny

twinny ne demande pas d’URL de base. Il demande un protocole, un nom d’hôte, un port et un chemin d’API ; pour le chat, ce chemin correspond à la base de l’API. Il faut donc indiquer https, api.kunavo.com et /v1, et laisser le port vide.

twinny n’a pas de champ d’URL de base — Add provider → OpenAI-compatible server, puis Protocol https, Hostname api.kunavo.com, Port vide et API path /v1 ; son panneau de chat utilise votre clé.

Onglet Fournisseurs → Ajouter un fournisseur → Serveur compatible avec OpenAI

Label          Kunavo
Type           Chat
Provider       OpenAI-compatible server
Hostname       api.kunavo.com
Port           (leave blank — "Blank means the protocol's default")
Protocol       https
API path       /v1
Model name     claude-sonnet-5
FIM template   (Autocomplete only — not part of a Chat provider)
API key        sk-kn-...

Le chemin d’API est /v1, et non /v1/chat/completions. Le tableau des fournisseurs de twinny tranche la question en une phrase : « Pour le chat, le chemin correspond à la base de l’API ; twinny ajoute /chat/completions ». Un chemin qui inclut déjà la route produit donc /v1/chat/completions/chat/completions et une réponse 404. Il n’y a pas ici de champ unique d’URL de base où se tromper, mais le même tableau propose un raccourci : collez https://api.kunavo.com/v1 dans Hostname et il sera « décomposé en protocole, hôte, port et chemin ».

Choisissez le préréglage générique OpenAI-compatible server, et non celui d’OpenAI ou d’Anthropic. La page des API hébergées de twinny indique que le chat passe par le SDK du fournisseur vers son point de terminaison fixe, si bien que les champs du nom d’hôte, du port et du chemin sont masqués ; la clé serait envoyée à ce fournisseur, et non à votre point de terminaison. Les libellés de champs ci-dessus proviennent du tableau du formulaire fournisseur, dans l’ordre indiqué.

Kunavo n’a pas exécuté twinny avec ce point de terminaison. Cette page s’appuie sur la documentation de twinny et le tableau des routes de Kunavo ; une page de configuration publiée ne constitue pas un test. Le bouton Test provider de twinny est celui qui le prouve réellement : il « envoie une petite requête correspondant à la fonction du fournisseur et affiche soit le succès, soit l’erreur renvoyée par le serveur, ainsi que l’URL appelée ».

Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration twinny.

Étape par étape

Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
Ouvrez l’onglet Providers à partir de l’icône de robot en haut de la barre latérale, ou exécutez Manage twinny providers depuis la palette de commandes.
Add provider → sous On your machine, choisissez OpenAI-compatible server, le préréglage générique. Il pointe par défaut vers localhost:8080.
Définissez Protocol sur https, Hostname sur api.kunavo.com, effacez Port et définissez API path sur /v1. Laissez Type sur Chat.
Collez la clé dans API key — twinny l’envoie sous la forme Authorization: Bearer. Définissez ensuite Model name, soit en le saisissant, soit en passant par Choose from the server's models, puisque Kunavo répond à GET /v1/models.
Cliquez sur Test provider, puis sur Use this provider pour en faire le fournisseur de chat actif. Utilisez Copy pour dupliquer la ligne pour un deuxième modèle, plutôt que de saisir à nouveau les quatre champs du point de terminaison.

Vérifié avec la page Other local servers de twinny le 21 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans la comparaison twinny vs Continue.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans twinny.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèle	Entrée / sortie sur Kunavo	Où cela s’intègre dans twinny
`claude-sonnet-5`	$1.40 / $7.00	le panneau de chat, la modification en ligne et la revue de code — le choix par défaut fonctionnel
`claude-haiku-4-5`	$0.70 / $3.50	les messages de commit, les assistants de terminal et les actions de code, où le volume domine
`gpt-5-6-terra`	$0.70 / $4.20	les fichiers longs collés dans le chat, et un deuxième avis d’une autre famille lorsqu’une revue manque de profondeur

La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

Le chat fonctionne. La complétion automatique et l’index ne fonctionnent pas.

twinny répartit le travail entre trois types de fournisseurs, configurés séparément. L’affirmation « twinny fonctionne avec Kunavo » ne s’applique donc qu’à l’un d’eux. Les deux autres ne correspondent pas à des paramètres que vous n’auriez pas encore trouvés : les routes dont ils ont besoin ne sont pas desservies par Kunavo.

Type de fournisseur	Requête envoyée par twinny	Avec api.kunavo.com
Conversations	Requête POST au format OpenAI vers `<API path>/chat/completions`	Compatible — c’est la configuration décrite ci-dessus.
Complétion automatique (FIM)	un prompt brut de remplissage au milieu vers `/v1/completions`	Non. Kunavo ne propose pas de route /v1/completions ni de modèle de base ou de code pour l’utiliser.
Plongements vectoriels	une requête vers `/v1/embeddings`	Non. Kunavo ne fournit aucun modèle d’embeddings ; l’index de l’espace de travail ne peut donc pas être créé ici.

Aucun de ces deux manques ne bloque la configuration : twinny conserve un fournisseur actif par type, et ces types sont indépendants. La page de twinny sur les API hébergées qualifie cette répartition de « configuration courante » : un petit modèle de base local pour la complétion, avec un modèle hébergé pour le chat, la revue et les modifications. L’index de l’espace de travail suit le même principe : les embeddings ne sont pas générés ici, et la documentation de twinny recommande à la place un modèle local tel que nomic-embed-text avec Ollama. Les vecteurs de modèles différents ne sont pas compatibles ; changer de modèle nécessite donc de reconstruire l’index, et non de le mettre à jour.

Questions fréquentes

Comment configurer twinny pour utiliser un point de terminaison d’API personnalisé ?

Ouvrez l’onglet Providers à partir de l’icône de robot dans la barre latérale de twinny, choisissez Add provider, puis, sous « On your machine », sélectionnez le préréglage générique « OpenAI-compatible server ». La documentation de twinny indique que le formulaire fournisseur accepte n’importe quel nom d’hôte, port, protocole et chemin. Définissez donc Protocol sur https, Hostname sur le nom d’hôte de votre point de terminaison, laissez Port vide pour utiliser le port par défaut du protocole et définissez API path sur la base de l’API. Collez votre clé dans le champ API key, que twinny envoie dans un en-tête Authorization: Bearer, puis cliquez sur Test provider : twinny envoie une petite requête correspondant à la fonction de ce fournisseur et indique soit le succès, soit l’erreur renvoyée par le serveur, ainsi que l’URL appelée.

Le chemin d’API de twinny doit-il être /v1 ou /v1/chat/completions ?

Pour un fournisseur de chat, il s’agit de /v1. Le tableau des fournisseurs de twinny indique : « Pour le chat, le chemin correspond à la base de l’API ; twinny ajoute /chat/completions ». L’extension construit donc elle-même la route complète. Un chemin qui l’inclut déjà devient /v1/chat/completions/chat/completions et renvoie une erreur 404 plutôt qu’une erreur d’authentification. Pour la complétion automatique et les embeddings, le même formulaire suit la convention inverse : le chemin d’API doit alors être la route complète, /v1/completions et /v1/embeddings étant les valeurs par défaut du préréglage générique.

Où saisir la clé API de twinny, et existe-t-il un champ d’URL de base ?

La clé se saisit dans le champ API key du fournisseur et est envoyée sous la forme Authorization: Bearer. La documentation de twinny indique que les clés sont stockées avec le fournisseur dans le stockage de VS Code et masquées dans les journaux de twinny. Il n’y a pas de champ unique d’URL de base : le point de terminaison est réparti entre Protocol, Hostname, Port et API path. Un raccourci consiste à coller une URL complète dans Hostname : la documentation précise qu’une URL collée, comme https://my-box:8080/v1, est décomposée en protocole, hôte, port et chemin. Ainsi, coller https://api.kunavo.com/v1 remplit trois champs à la fois.

La complétion automatique de twinny peut-elle passer par une passerelle hébergée comme Kunavo ?

Non, car une route manque ; il ne s’agit pas d’un paramètre. Le préréglage générique de twinny, compatible avec OpenAI, envoie un prompt brut de remplissage au milieu vers une route de type /v1/completions, qui n’est pas desservie par api.kunavo.com. Le catalogue ne contient par ailleurs aucun modèle de base ou de code entraîné pour le remplissage au milieu. Gardez la complétion automatique sur un serveur local — la FAQ de twinny suggère qwen2.5-coder:1.5b-base sur Ollama — et utilisez le fournisseur hébergé pour le chat. twinny qualifie cette combinaison de configuration courante ; comme le fournisseur actif est choisi par type, aucun changement n’est nécessaire.

Kunavo peut-il alimenter l’index de l’espace de travail de twinny ?

Non. L’index de l’espace de travail génère des embeddings de vos fichiers avec un fournisseur Embeddings, et Kunavo ne sert aucun modèle d’embeddings. Aucun modèle de son catalogue ne propose cette route ; la requête est donc rejetée plutôt que traitée. La documentation de twinny recommande nomic-embed-text sur Ollama pour cette tâche. Ce modèle s’exécute sur votre machine, indépendamment du fournisseur de chat. Cette configuration répartie ne bloque pas l’usage ; notez qu’il faudra reconstruire l’index si vous changez ensuite de modèle d’embeddings, car les vecteurs de modèles différents ne sont pas compatibles.

Pourquoi ne pas utiliser le préréglage OpenAI ou Anthropic de twinny avec une clé Kunavo ?

Parce que ces préréglages n’envoient pas les requêtes à l’endroit prévu. La page des API hébergées de twinny indique que les requêtes de chat via une API hébergée passent par le SDK du fournisseur vers son point de terminaison fixe ; les champs du nom d’hôte, du port et du chemin sont donc masqués. La clé que vous saisissez serait envoyée au point de terminaison du fournisseur, et non à votre passerelle. Le préréglage générique « OpenAI-compatible server » est celui qui laisse les champs du point de terminaison modifiables, d’où le choix indiqué ci-dessus. Les identifiants de modèle sont transmis tels quels au point de terminaison configuré ; utiliser un identifiant Claude avec un fournisseur compatible avec OpenAI est donc la combinaison prévue, et non une incompatibilité.

Kunavo a-t-il testé twinny ?

Non. Kunavo n’a pas testé ce client en conditions réelles ; la configuration ci-dessus provient de la documentation de twinny, vérifiée le 21 septembre 2026, et du tableau des routes de Kunavo. Une page de configuration publiée ne constitue pas un test. Le test gratuit à votre disposition est le bouton Test provider de twinny, qui indique l’URL appelée et la réponse du serveur. Une commande curl vers /v1/models permet de déterminer si une défaillance vient du point de terminaison, de la clé ou du formulaire.