Dina prompts fungerar. Ditt flöde fungerar. Sedan säger någon ”vi testar en ny modell”, och plötsligt är du inne och rör ett halvdussin noder, byter autentiseringsuppgifter och hoppas att du inte råkade skapa något subtilt fel.
Marketing ops-team märker det när experiment stannar upp. Byråägare märker det när varje kund vill ha en annan modell. Och produktansvariga märker det när ”snabb testning” blir ett ärende till utvecklingsteamet. Den här automatiseringen för GitHub Models-integration gör att dina OpenAI-liknande prompts förblir stabila medan du byter modeller i bakgrunden.
Det här arbetsflödet bygger ett litet kompatibilitetslager i n8n. Du får se hur det routar förfrågningar för ”lista modeller” och ”chat completion” till GitHub Models och sedan returnerar svar i det format som dina befintliga OpenAI-baserade noder redan förväntar sig.
Så fungerar den här automatiseringen
Se hur den här lösningen löser problemet:
n8n Workflow Template: GitHub models + OpenAI: byt llm utan omskrivning
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Github Chat Completions"]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Chat Response"]
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>POST ChatCompletions"]
n10@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Is Agent?", pos: "b", h: 48 }
n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Agent Response"]
n10 --> n11
n10 --> n4
n9 --> n2
n2 --> n10
end
subgraph sg1["Flow 2"]
direction LR
n0@{ icon: "mdi:cog", form: "rounded", label: "Aggregate", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Github Models"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Models Response"]
n8["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>GET models"]
n0 --> n5
n8 --> n1
n1 --> n0
end
subgraph sg2["When chat message received Flow"]
direction LR
n3@{ icon: "mdi:brain", form: "rounded", label: "n8n Webhooks", pos: "b", h: 48 }
n6@{ icon: "mdi:robot", form: "rounded", label: "Powered By Github Models", pos: "b", h: 48 }
n7@{ icon: "mdi:play-circle", form: "rounded", label: "When chat message received", pos: "b", h: 48 }
n3 -.-> n6
n7 --> n6
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n7 trigger
class n6 ai
class n3 aiModel
class n10 decision
class n2,n4,n9,n11,n1,n5,n8 api
classDef customIcon fill:none,stroke:none
class n2,n4,n9,n11,n1,n5,n8 customIcon
Utmaningen: att byta LLM:er slår sönder fungerande arbetsflöden
Modelltestning låter enkelt tills du gör det mer än en gång. Ett flöde kan ha en AI Agent-nod, ett annat använder en vanlig chattmodell och ett tredje har en kedja som är beroende av en specifik svarsstruktur. När du byter leverantör eller endpoint kan du behöva skriva om prompts, mappa om fält och felsöka små skillnader som är ärligt talat svåra att se. Det är inte ”en ändring”, det är följdeffekten: folk slutar experimentera eftersom det är riskfyllt, långsamt och störande.
Friktionen bygger på. Så här faller det isär i riktiga team.
- Varje modelltest blir till ändringar i arbetsflöden, så experiment staplas på hög och når sällan produktion.
- Prompts dupliceras mellan noder, vilket gör att konsekvensen försämras över tid.
- Små skillnader i svarsformat skapar tysta fel, som saknade fält eller tomma svar.
- Du tappar en ”känd fungerande” baslinje eftersom originalupplägget skrivs över i stället för att isoleras.
Lösningen: en anpassad OpenAI-kompatibel endpoint för GitHub Models
Det här n8n-flödet fungerar som en översättare mellan dina befintliga OpenAI-liknande LLM-noder och GitHub Models. Du konfigurerar en ny OpenAI-autentisering i n8n, men i stället för att peka den mot OpenAI sätter du Base URL till en n8n-webhook från den här mallen. Från och med då ”tror” din LLM-nod att den pratar med ett OpenAI-kompatibelt API. I bakgrunden tar flödet emot två typer av förfrågningar: en för att lista modeller och en för chat completions. Det vidarebefordrar förfrågningarna till GitHub Models via HTTP-anrop och formar sedan om svaren så att dina noder fortsätter fungera utan att du behöver refaktorera prompts.
Flödet startar när din LLM-nod frågar efter tillgängliga modeller eller skickar en chat completion-förfrågan. n8n anropar GitHub Models, normaliserar outputen och svarar tillbaka till LLM-noden i det format den redan förväntar sig. Om streaming ingår kontrollerar flödet det och returnerar rätt typ av svar.
Vad som förändras: före vs. efter
| Det här eliminerar | Effekten du kommer att se |
|---|---|
|
|
Effekt i praktiken
Säg att du har 6 AI-drivna arbetsflöden i n8n (innehållsunderlag, supportsvar, intern QA och så vidare). Att byta modeller manuellt innebär ofta att du öppnar varje flöde, uppdaterar autentiseringsuppgifter, kontrollerar modellnamnet och kör ett snabbtest, kanske 10 minuter per flöde. Det är ungefär en timme varje gång du vill experimentera. Med den här lösningen ändrar du Base URL en gång och väljer en annan GitHub-modell, och sedan fortsätter dina befintliga noder att skicka samma OpenAI-liknande förfrågningar. För många team sjunker testtiden till ungefär 10 minuter totalt.
Krav
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
- GitHub-konto för åtkomst till GitHub Models.
- Åtkomst till HTTP Request i n8n för att anropa GitHub Models API.
- GitHub-autentisering/token (skapa den i GitHub-inställningar för utvecklartokens).
Kunskapsnivå: Medel. Du klistrar in autentiseringsuppgifter, sätter en Base URL och verifierar att två webhooks svarar korrekt.
Behöver du hjälp att implementera detta? Prata med en automationsexpert (kostnadsfri 15-minuters konsultation).
Så går flödet
Ett chattmeddelande startar allt. Chat Message Trigger startar flödet när en användare frågar något och skickar sedan meddelandet vidare in i en LLM-kedja som använder en OpenAI-liknande anslutning för chattmodell.
LLM-noden anropar din n8n-webhook i stället för OpenAI. Du skapar en anpassad OpenAI-autentisering där Base URL pekar på det här flödets webhook-endpoints. Ur LLM-nodens perspektiv är det samma upplägg som vanligt.
Två webhooks hanterar ”API-ytan”. En webhook svarar på modellupptäckt (“models”) genom att anropa GitHubs endpoint för modellkatalogen, slå ihop objekten och returnera en kompatibel modellista. Den andra webhooken hanterar chat completions genom att skicka prompt-payloaden till GitHubs endpoint för chat completion via HTTP Request.
Flödet returnerar ett svar i exakt det format dina noder förväntar sig. En If-kontroll (Agent Stream Check) avgör om det ska svara med ett strömmat svar eller ett standardiserat webhook-svar, så att din efterföljande logik inte får oväntade överraskningar.
Du kan enkelt ändra vilken GitHub-modell du använder som standard och hur du mappar svars-fälten utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera webhook-triggern
Det här arbetsflödet exponerar två webhook-endpoints för modellista och chat completions, samt en chat-trigger för LLM-kedjehantering.
- Öppna Model List Webhook och ställ in Path till
github-models/models. - I Model List Webhook ställer ni in Response Mode till
responseNodeså att Return Model List kan svara. - Öppna Chat Completion Webhook och ställ in Path till
github-models/chat/completionsoch HTTP Method tillPOST. - I Chat Completion Webhook ställer ni in Response Mode till
responseNodeså att svaren går vidare till Streamed Agent Reply eller Standard Chat Reply. - Låt Chat Message Trigger vara aktiverad för att starta kedjan via LLM Chain Processor.
Steg 2: Anslut GitHub API och konfigurera HTTP-anrop
Dessa noder anropar GitHubs modellkatalog och inferens-endpoints.
- Öppna Model Catalog Request och bekräfta att URL är
https://models.github.ai/catalog/models. - I Model Catalog Request behåller ni Authentication satt till
predefinedCredentialTypeoch Node Credential Type tillgithubApi. - Inloggningsuppgifter krävs: Anslut era
githubApi-inloggningsuppgifter i Model Catalog Request. - Öppna Chat Completion API Call och ställ in URL till
https://models.github.ai/inference/chat/completionsoch Method tillPOST. - Ställ in JSON Body i Chat Completion API Call till
={{ { model: $json.body.model, messages: $json.body.messages, stream: $json.body.stream } }}. - Inloggningsuppgifter krävs: Anslut era
githubApi-inloggningsuppgifter i Chat Completion API Call.
Steg 3: Sätt upp LLM-kedjeprocessorn
Kedjan använder den OpenAI-kompatibla modellen som konfigureras i Webhook LLM Connector.
- Öppna Webhook LLM Connector och ställ in Model till
openai/gpt-4o-mini. - Inloggningsuppgifter krävs: Anslut era
openAiApi-inloggningsuppgifter i Webhook LLM Connector. - Säkerställ att Webhook LLM Connector är länkat som språkmodell för LLM Chain Processor via AI-anslutningen.
Steg 4: Konfigurera aggregering, routning och webhook-svar
Det här steget styr hur modellistor returneras och hur chat completion-svar strömmas eller returneras som JSON.
- I Combine Model Items ställer ni in Aggregate till
aggregateAllItemDataför att samla in alla katalogobjekt. - I Return Model List ställer ni in Respond With till
jsonoch Response Body till={{ ({ "object": "list", "data": $json.data.map(item => ({ "id": item.id, "object": "model", "created": 1733945430, "owned_by": "system" })) }) }}. - Öppna Agent Stream Check och säkerställ att villkoret kontrollerar
={{ $('Chat Completion Webhook').first().json.body.stream }}för en true-boolean. - Ställ in Streamed Agent Reply till Respond With
textoch Response Body till={{ $json.data }}för strömmade utdata. - Ställ in Standard Chat Reply till Respond With
jsonoch Response Body till={{ $json }}för icke-strömmade svar.
stream kommer Agent Stream Check som standard att routa till Standard Chat Reply, vilket kan vara inkompatibelt med strömningsklienter.Steg 5: Testa och aktivera ert arbetsflöde
Validera varje flödesväg med webhook-test-URL:erna och aktivera sedan arbetsflödet.
- Klicka på Execute Workflow och skicka en testförfrågan till Model List Webhook; bekräfta att Return Model List svarar med ett modellisteobjekt.
- Skicka en POST-förfrågan till Chat Completion Webhook med en JSON body som innehåller
model,messagesochstream; verifiera routning via Chat Completion API Call och Agent Stream Check. - Om
streamär true, bekräfta att Streamed Agent Reply returnerar text; om false, bekräfta att Standard Chat Reply returnerar JSON. - När allt är validerat växlar ni arbetsflödet till Active för användning i produktion.
Saker att se upp med
- GitHub-autentisering kan gå ut eller kräva specifika behörigheter. Om något slutar fungera, kontrollera först din GitHub-tokens scopes och credential-testet i n8n.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du att redigera output i all oändlighet.
Vanliga frågor
Cirka 30 minuter om dina GitHub-autentiseringsuppgifter är klara.
Ja, men någon behöver vara bekväm med att klistra in API-autentiseringsuppgifter och testa ett webhook-svar. Ingen kodning, bara noggrann konfiguration.
Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Molnplaner börjar på 20 USD/månad för högre volymer. Du behöver också ta hänsyn till begränsningar i GitHub Models (GitHub påpekar att de kostnadsfria modell-API:erna inte är avsedda för produktionsbruk).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger dig obegränsade körningar men kräver grundläggande serverhantering.
Du kan behålla samma OpenAI-liknande autentisering och byta ut vad som händer bakom webhooken. Vanliga justeringar är att ändra hur ”Model Catalog Request” mappar modell-ID:n, justera payload-fälten i ”Chat Completion API Call” och ändra streaming-beteendet genom att redigera logiken i ”Agent Stream Check” så att den matchar ditt önskade svarsformat.
Oftast beror det på en utgången token eller saknade behörigheter i GitHub-autentiseringen som används av HTTP Request-noderna. Dubbelkolla autentiseringen som är kopplad till ”Model Catalog Request” och ”Chat Completion API Call”, och testa sedan igen från webhook-URL:en för att bekräfta att du får ett riktigt svar. Om du skickar många förfrågningar kan du också slå i GitHubs gränser för prototypanvändning, vilket kan se ut som intermittenta fel.
Det beror mer på din driftmiljö och GitHubs begränsningar än på själva flödet. I n8n Cloud hanterar högre nivåer fler körningar per månad, och vid egen drift finns ingen körningsgräns (din server blir begränsningen). I praktiken fungerar det här mönstret bra för stabil intern användning, men GitHub positionerar uttryckligen dessa modell-API:er för prototyping snarare än produktionstrafik i stor skala. Om du behöver hög volym kan du behålla samma upplägg men peka din Base URL mot en betal-leverantör med högre rate limits.
Ofta, ja. Du bygger i praktiken en OpenAI-kompatibel ”shim” med flera webhooks, villkorligt streaming-beteende och ommappning av svar, och n8n hanterar den typen av logik snyggt på ett ställe. Zapier och Make kan också använda webhooks, men den här typen av request/response-proxying blir snabbt klumpig, och kostnaderna tenderar att öka när du lägger till förgreningar och högre task-volymer. Om du bara behöver ett enkelt ”skicka prompt, få svar”-anrop är de verktygen helt okej. Om du vill kunna byta modeller utan att koppla om flera flöden är n8n ett mer naturligt val. Prata med en automationsexpert om du är osäker på vad som passar.
När det här väl är på plats slutar modelltestning att vara ett omskrivningsprojekt. Du håller arbetsflödena stabila och får tillbaka farten i experimenterandet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.