Et kompatibelt API lader jeres systemer kalde en ny udbyders model med samme kode, som de bruger i dag, ofte ved kun at ændre adressen og nøglen. Det gør det let at prøve en anden model, men flere funktioner virker anderledes eller slet ikke gennem det kompatible lag, og nogle forskelle giver ingen fejlbesked.
Flere udbydere efterligner den samme udbredte grænseflade, som oprindelig blev lavet af én af de store. Det har gjort det til et salgsargument, at et skifte kun er en adresse. Artiklen ser på, hvad løftet holder, og hvad I skal teste, før I bygger et skifte af AI API på det. Forskellen til et mellemlag, der selv oversætter mellem udbyderne, er beskrevet i et lag mellem jeres systemer og modellen.
Det, udbyderne selv skriver
Vi har læst dokumentationen for det kompatible lag hos to store udbydere 8. november 2026. Den første skriver, at laget først og fremmest er til at teste og sammenligne modeller, og at det i almindelighed ikke regnes som en langsigtet eller produktionsklar løsning. Dokumentationen nævner blandt andet disse forskelle:
- Parameteren for streng overholdelse af et skema ved værktøjskald ignoreres, så svaret fra et værktøjskald følger ikke med sikkerhed skemaet.
- Kun én form for struktureret svar accepteres.
- Lyd og filer som input understøttes ikke.
- Mellemlagring af lange prompter understøttes ikke.
- Felter, der ikke understøttes, ignoreres for størstedelens vedkommende stille, uden fejlbesked.
- System- og udviklerbeskeder lægges sammen til én.
Den anden udbyder skriver, at dens modeller kan bruges med den udbredte grænseflades biblioteker ved at ændre få kodelinjer. Udbyderen anbefaler at kalde sin egen grænseflade direkte, hvis man ikke allerede bruger de andre biblioteker. Understøttelsen er stadig i beta, og ved billedgenerering ignoreres parametre, der ikke er nævnt, uden besked.
Begge udbydere fortæller altså selv, at laget har grænser. Det er en nyttig oplysning, når I vurderer, hvor let et skifte reelt er.
Det stille problem
Det vigtigste punkt er de felter, der ignoreres uden fejl. Sender jeres system en indstilling, som den nye udbyder ikke kender, kører kaldet videre, og svaret kommer. Det ser ud, som om alt virker. Men svaret er lavet uden indstillingen, og forskellen viser sig først i resultatet: et svar, der ikke følger formatet, en grænse, der ikke blev overholdt, eller en instruktion, der kom et andet sted hen i rækkefølgen.
En kørsel uden fejl siger derfor intet om kvaliteten. Testen er, om svarene er de rigtige.
Hvad der skal testes
Det er sitets metode at gå disse punkter igennem, før et skifte gennem et kompatibelt lag tages i brug:
Værktøjskald. Bruger jeres løsning, at modellen kalder funktioner eller systemer, så prøv hvert værktøj. Kontrollér, at argumenterne kommer i det forventede format, også når modellen er i tvivl.
Strukturerede svar. Forventer de næste systemer et bestemt format, så kør jeres eksempler og kontrollér hvert svar mod skemaet. Hvis laget ikke håndhæver skemaet, skal jeres egen kode gøre det.
Rækkefølgen af instruktioner. Bruger I flere slags instruktioner, så se, om de behandles ens, når de lægges sammen.
Filer, billeder og lyd. Kontrollér, hvilke typer input laget tager imod, og hvad der sker med dem, det ikke tager imod.
Indlejringer. Kalder I også en indlejringsmodel gennem laget, så vær opmærksom på, at et skifte af den kræver, at hele indekset bygges igen. Se indlejringer og vektordatabaser.
Grænser og fejl. Grænser for forespørgsler pr. minut, længden af input og svar, og de fejlbeskeder, der kommer, når grænsen nås. Jeres kode skal kunne håndtere den nye udbyders fejl.
Optælling og afregning. Hvordan forbrug tælles og vises, kan være forskelligt, og jeres overvågning af forbrug skal passe til det.
Når punkterne er gennemgået, køres jeres prøvesamling med den nye model, som beskrevet i øvelsen: skift model på en afgrænset opgave.
Hvad løftet er værd
Et kompatibelt API gør den første prøve billig. Det er en reel fordel, fordi det sænker tærsklen for at sammenligne modeller på jeres egne opgaver. Som grundlag for drift er det svagere, og de to udbydere, vi har læst, siger det selv.
Den sunde brug er derfor at prøve gennem det kompatible lag og at beslutte ud fra testen, om I kan blive der, eller om løsningen skal bygges på udbyderens egen grænseflade eller et mellemlag.
Hvad det kræver, og hvad det koster at lade være
Gennemgangen af punkterne tager en udvikler en til tre dage for en løsning, alt efter hvor mange værktøjer og formater den bruger. Prøvesamlingen skal være klar, og en fagperson skal bedømme svarene.
Lader I være, og sætter I et skifte i drift, fordi kaldene ikke gav fejl, kan resultaterne være forkerte i lang tid, før nogen opdager det. Omkostningen er fejl i de systemer, der bruger svarene, tid til at finde årsagen og ny test bagefter. Det er dyrere end testen, fordi det sker i drift.
Det skal I lade være med
- At læse en kørsel uden fejl som en bestået test · felter kan være ignoreret uden besked.
- At bygge drift på et lag, udbyderen selv kalder et testværktøj · læs dokumentationen først.
- At glemme jeres egen kontrol af formater · den skal fange det, laget ikke håndhæver.
Det skal valget kunne vise
- ☐ Hvilke funktioner jeres løsning bruger: værktøjer, formater, filer, indlejringer.
- ☐ Udbyderens egen beskrivelse af, hvad det kompatible lag ikke understøtter.
- ☐ Resultat af testen for hvert punkt.
- ☐ En beslutning om, hvorvidt løsningen bliver på laget eller flyttes til udbyderens egen grænseflade.
Kilder
- Dokumentation for kompatible grænseflader hos to store udbydere, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv ned, hvilke værktøjer og formater jeres vigtigste AI-løsning bruger, og find den nye udbyders liste over det, laget ikke understøtter.
Læs også: Hvad binder, når I vælger AI? · Modellen skifter under jer
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
