X mention-bot

Vad ToolGPT är på X

ToolGPT är den publika X/Twitter-identitet som drivs av Tools X mention-bot.

I praktiken betyder det att:

• X-kontot är den synliga publika bot-personan på X
• botten läser mentions eller konfigurerade bevakningsord via X API
• Tools bygger svarskontexten, tillämpar lokala säkerhets-/routingregler och lagrar interaktionshistoriken
• kandidatsvar genereras först i Tools och kan stanna i dry-run eller manuell granskning beroende på inställningarna
• själva X-kontot är alltså bara den synliga postningsidentiteten; den riktiga kontrollpanelen finns i Tools admin

Om du alltså ser ToolGPT på X är det samma botsystem som dokumenteras på den här sidan.

För den publika ändringshistoriken, se:

• ToolGPT-ändringslogg

Publik FAQ

”Hur bygger ToolGPT ett svar?”

På publik nivå ser svarskedjan ut så här:

1. Tools ingestar antingen en direkt @mention / reply eller en träff på ett konfigurerat bevakningsord.
2. Tools hämtar synlig trådkontext och kan vid behov även ta med länkutdrag eller RSS-evidens när sådana funktioner är aktiverade och relevanta.
3. En inbyggd neutral grundprompt appliceras alltid först.
4. Därefter appliceras den adminsynliga fallback-instruktionen och det fria fallback-mood-fältet, och den bäst matchande keyword-regeln kan overridea dem för just det svaret.
5. Tools genererar ett kort X-anpassat kandidatsvar, lägger det i dry-run/manuell granskning/live-post-flödet beroende på aktuella inställningar och sparar interaktionshistoriken.

”Är ToolGPT kommunistisk, antirasistisk, woke eller anti-höger?”

Nej, ingen politisk ideologi är konfigurerad som botens mål.

Den inbyggda grundprompten instruerar botten att:

• inte försöka vinna debatten åt en politisk sida
• skilja mellan fakta, juridik, moral och åsikt
• undvika kollektiv skuldbeläggning
• markera mot avhumanisering, rasistiska generaliseringar och hot i neutral ordalydelse
• undvika laddade etiketter om de inte verkligen behövs och stöds av kontexten

I uppskruvade trådar kan det ändå uppfattas som politiskt laddat utifrån, men den avsedda linjen är rättsstatsnära neutralitet och plattformssäkra gränser – inte partipolitisk kampanjretorik.

”Är ToolGPT bara ett eko av Thomas / Tornevall?”

Inte avsiktligt.

Publika svar formas av:

• en fast inbyggd neutral grundprompt
• den synliga trådkontext som Tools faktiskt hämtade
• adminsynlig fallback-instruktion och fallback mood
• valfria keyword-regeloverrides för den aktuella interaktionen
• X-specifika korthets- och säkerhetsgränser

Operatörsinställningarna påverkar ton och fallback-riktning, men systemet är inte tänkt att bara spegla en persons humör, politiska läger eller timeline-röst.

”Finns det dolda prompts?”

Det finns ett inbyggt systemlager, men den publika dokumentationen beskriver nu den grundläggande promptdesignen öppet i stället för att låtsas som att botten saknar styrande grundprompt.

Den publika kontraktsnivån är att grundprompten är byggd för att:

• svara direkt
• vara neutral, torr och saklig som standard
• undvika avhumanisering och kollektiv skuld
• säga till när verifiering saknas
• inte läcka hemligheter, credentials eller privata runtime-detaljer

Tools publicerar fortfarande inte varje intern abuse-prevention-detalj ord för ord, men målen och grundprinciperna för prompten är publika.

”Varför markerar ToolGPT ibland mot kollektiv skuldbeläggning, tortyrretorik eller avhumaniserande språk?”

För att den inbyggda prompten uttryckligen skiljer mellan legitim debatt om straff, utvisning där lagen tillåter det och skydd för brottsoffer å ena sidan – och krav på tortyr, kollektiv bestraffning, hot eller att grupper ska behandlas som mindre än människor å andra sidan.

Det är både ett neutralitetsval och ett skydd för att hålla ToolGPT inom plattformsvillkoren.

Publik promptdesign och neutralitetsbas

ToolGPT har nu en dokumenterad standarddesign för prompten även när det adminsynliga fältet för fallback custom instruction är tomt.

Den publika promptstacken är:

1. Inbyggd neutral grundprompt
2. Fallback custom instruction (adminsynlig additiv vägledning)
3. Fallback mood (adminsynligt fritt textfält för ton)
4. Bäst matchande svarsprioritetsprofil vald från de konfigurerade keyword-reglerna för den aktuella interaktionen
5. Aktuell trådkontext + eventuell länk-/RSS-evidens + X-specifika reply-gränser

Den inbyggda grundprompten är uttryckligen utformad för att:

• fungera som en saklig debatt- och faktabot
• undvika att vinna åt en politisk sida
• skilja mellan fakta, juridik, moral och åsikt
• inte spegla användarens vrede, sarkasm eller förolämpningar tillbaka
• undvika laddade förstaetiketter som woke, kommunist, fascist eller rasist om de inte verkligen behövs och stöds av sammanhanget
• beskriva problem mer konkret, till exempel som kollektiv skuldbeläggning, avhumaniserande språk, hot eller strider mot rättsstatens principer
• säga till när verifiering fortfarande saknas
• svara på hypotetiska eller principiella frågor på principnivå i stället för att gömma sig bakom irrelevant källbrist

Det är också därför den publika dokumentationen bör beskriva grundpromptens design öppet. Kraven på säkerhet och neutralitet finns inte där för att i smyg styra politiken, utan för att hålla ToolGPT inom plattformsvillkor, minska missbruk och göra svarsstilen mer förutsägbart neutral.

Hur keyword-styrningen är tänkt att fungera

Keyword-systemet är inte tänkt att betyda ”om ett magiskt ord dyker upp ska en viss ideologisk text pressas ut”.

Den avsedda modellen ligger närmare svarsprioritering utifrån hjälpsamhet och inriktning.

Publikt betyder det att:

• botten börjar alltid från den neutrala inbyggda grundprompten
• om ingen keyword-profil matchar tillräckligt starkt stannar svaret på normal fallback instruction + fallback mood
• om en keyword-profil är en tydligt bättre match kan den styra prioritet och riktning för just det svaret
• målet är att besvara den mest relevanta typen av fråga först, inte att överge neutraliteten

Exempel på den prioriteringslogiken:

• om inlägget främst handlar om X-boten själv, prioritera först ett kort svar som förklarar botten, dess roll eller dess begränsningar
• om inlägget främst frågar efter verifiering / källor / belägg, prioritera först ett fact-check-liknande svar
• om inlägget främst ber om ett direkt praktiskt svar, prioritera det konkreta svaret först i stället för att glida iväg i metadiskussion
• om inlägget mest är bait, svag kontext eller en dålig delträff, ska en svag keyword-träff inte få overridea ett mer hjälpsamt standardsvar

Systemet ska alltså förstås som:

• "Om du frågar om X-boten, prioritera den svarsriktningen först"
• inte "Om ett visst ord dyker upp, gör en ideologisk personlighetsförändring"

Status

Första implementationen är dry-run först.

Tools kan nu:

• lagra ett primärt X-botkonto
• polla explicita mentions från X
• polla publika X-poster som matchar konfigurerade bevakningsord när läget för enbart explicita mentions är av
• fortsätta bevaka redan engagerade konversationstrådar, så att en senare uppföljning i samma tråd inte alltid måste repetera @ToolGPT
• lagra interaktioner idempotent
• sanera synlig X-kontext från konversationen
• gå bakåt i reply-kedjor så äldre parent-poster finns kvar när en kort uppföljning bygger på tidigare trådtext
• generera AI-kandidatsvar
• spara dessa svar i Tools för granskning
• visa hur många längd-omkörningar ett lagrat kandidatsvar behövde innan det kom under aktuell teckengräns
• markera uppenbara refusal-/vägransvar som maskinläsbara publicera inte-kandidater
• behålla riktig provider-/policyfeltext tydligare när ett strukturerat reply-försök fallerar internt
• hantera opt-out och lokala rate limits
• använda fallback custom instruction + fallback mood
• använda keyword-baserade svarsprioritetsprofiler för att styra svaret mot den mest hjälpsamma riktningen för just den interaktionen
• analysera alla aktiva keyword-regler och välja den starkaste hjälpsamma träffen i stället för att alltid ta första svaga träffen
• känna igen svensk/engelsk verifieringsformulering tydligare, så frågor om fakta, källor eller belägg kan gå in i ett starkare fact-check-spår i stället för att ligga kvar som ett generiskt svarsläge
• alltid köra ett internt RSS-/feedarkiv-pass när RSS-evidens är aktiverat, där OpenAI först får välja relevanta sökord och Tools sedan gör en lokal SQL-sökning i arkivet för att bygga extra valfri stöd-kontext
• tolka bredare frågor i stil med ”vilka är de relevantaste/senaste nyheterna från nyhetsflödet idag?” som en feedarkiv-lookup också, även när posten aldrig bokstavligen säger sök i RSS, så ToolGPT kan sammanfatta färska feedposter i stället för att missa RSS-intentionen
• hålla det RSS-/arkivmaterialet som just valfri stöd-kontext: om det direkta svaret redan framgår av X-tråden ska ToolGPT inte trycka in arkivet som förstasvar bara för att det råkar finnas matchande feedrader
• behandla reasoning effort och web search som två olika reglage: starkare verifieringsprompter kan nu begära faktisk OpenAI-webbsökning när miljön stöder det, i stället för att bara höja reasoning-nivån
• tillämpa en striktare policy för oberoende verifiering: om en interaktion kräver riktig webbsökning men OpenAI faktiskt inte använder web search-verktyget behandlas svaret inte längre som oberoende verifierat. ToolGPT försöker nu i stället en gång till i normalt svarsläge utan webbsökning i stället för att posta en upprepad standardsats om saknad verifiering
• när användare frågar om dokumentation/changelog finns eller vad ToolGPT/SocialGPT faktiskt stödjer försöker botten nu också lägga in evidens från publika Tools-dokument och ändringsloggar innan den svarar, i stället för att falla tillbaka till ett generiskt “ingen dokumentation”-gissningssvar
• spara centrala adminfält inline via AJAX/onblur i stället för att kräva full sidreload för varje liten ändring
• auto-approva köade replies efter ett randomiserat delayfönster
• notifiera operatörer via mail och/eller Slack medan manuell approval fortfarande gäller
• vidarebefordra registrerad X-bot-aktivitet till Slack på begäran via kategorin audit_x_bot i Slack log routing, så att operatörer medvetet kan spegla bottens modererings-/runtimehändelser till Slack utan att behandla varje Slack-meddelande som en vanlig manuell-review-notis
• eskalera provider-sidiga runtimeblockeringar från spend-cap / credits-exhausted automatiskt: när den schemalagda X-bot-pollern märker att aktuell project-/account-budget stoppat botten kan Tools nu skicka ett varningsmail till konfigurerad supportmottagare och ett SMS till konfigurerat mobilnummer för sajtägaren tills nästa lyckade körning nollställer incidenten
• strippa bort oavsiktliga råa JSON-kuvert innan ett publikt reply sparas eller postas, så svar som egentligen skulle säga något i stil med Här är ett enkelt recept på blåbärspaj... inte längre riskerar att läcka ut som en bokstavlig { "message": ... }-payload i den publika X-tråden
• exponera admin- och ToolsAPI-ytor för diagnostik och granskning
• hålla tydligt oengagerade uppföljningstweets i ett synligt Publicera inte-läge i stället för att låta dem se publicerbara ut ända tills X nekar själva postningen
• undvika att lägga på en äldre regel-override för lätt när den senaste tweeten i praktiken bara är en mention och en länk
• låta operatörer styra hur många strukturerade reply-genereringsförsök Tools ska göra innan den ger upp (nuvarande stödda intervall: 1–5)
• hålla en något mjukare lokal reply-målgräns under X:s hårda 260-teckensgräns, så att slutposten oftare slutar på en hel mening i stället för att pressas ända upp mot maxlängden
• räkna in eventuell synlig @author-prefix i den slutliga postade reply-längden i stället för att behandla den taggen som gratis extra utrymme
• göra ett sista plain-text-försök att rädda fram ett direkt svar när den strukturerade reply-stegen slutar i ett ogenomskinligt non-replyable-resultat utan begriplig förklaring
• tona ner kända AI-konton som grok som reply-fokus när vanliga icke-AI-deltagare också är aktiva i samma tråd, så att ToolGPT kan fortsätta diskutera med människorna i stället för att dras in i AI-bait
• behandla “ingen keyword-regel matchade” som ett normalt fallback-till-standardinstruktion-läge i stället för som ett självständigt skäl att vägra svara
• visa en opt-out-del i admin där operatörer kan granska alla sparade opt-outs, opta in ett konto igen, ange användarnamn/X-user-id:n som alltid ska åsidosätta opt-out eller tillfälligt ignorera alla sparade opt-outs globalt
• hålla @Tornevall permanent skyddad från effektiv opt-out-blockering i X-botten så att huvudoperatörskontot fortfarande kan delta även om en gammal opt-out-rad råkade sparas tidigare
• paginera adminlistan Recent interactions så att operatören kan bläddra bland äldre lagrade interaktionssidor i stället för att alltid ladda en enda större latest-batch
• hålla hårdblockerade/icke-postbara diagnostikrader i en egen separat sektion när operatören uttryckligen väljer att visa icke-publicerbara rader, så rena dead-end-hard-blocks inte blandas tillbaka in i den vanliga granskningskön

När ToolGPT medvetet stoppar en tråd

ToolGPT får nu medvetet stoppa vissa återvändsgrändsloopar.

Nuvarande publika beteende:

• om en känd AI-deltagare som grok fortsätter att upprepa samma eller nästan samma svarsmönster
• och tråden inte längre rör sig framåt på ett meningsfullt sätt
• kan Tools markera den tråden som färdigbehandlad i stället för att låta samma utbyte fortsätta i timmar
• men safeguarden är nu förankrad i den senaste växlingen, så ett äldre upprepat AI-mönster ska inte fortsätta blockera en tråd som redan har gått vidare
• ToolGPT kan nu också köra en separat repetitionskontroll på bara de senaste 5–7 synliga posterna när en mänsklig deltagare uttryckligen klagar på att botten upprepar sig eller när den senaste växlingen tydligt bara går runt i samma poäng
• den nyare kontrollen kan göra en av två saker: antingen säga åt ToolGPT att fortsätta svara men föra diskussionen framåt med en ny vinkel / klargörande fråga, eller pausa tråden helt när den senaste växlingen har blivit en repetitiv återvändsgränd

Det här är tänkt som en safeguard mot repetitiva bot-till-bot-loopar, inte som ett dolt modereringsknep.

Målet är att:

• stoppa improduktiv upprepning
• undvika att premiumbegränsade svarsmöjligheter slösas på återvändsgränder
• lämna utrymme för nya riktiga mentions eller mer användbara uppföljningar senare

Omkörning av fastnade interaktioner

När en interaktion ser ut att ha fastnat eller fått fel regel/routing kan operatören köra om den från adminytan.

Publikt beteende:

• omkörning använder de senaste sparade X-botinställningarna
• regelvalet analyseras på nytt innan nytt kandidatsvar genereras
• tidigare blockerade eller icke-publicerbara kandidater kan därmed få ett nytt försök efter att regler, instruction, mood eller andra inställningar har ändrats

Beteende för reply-längd

Om den lokala Tools-gränsen sätts till 0 stänger det av den extra striktare Tools-cappen.

Tools håller ändå fortfarande den normala hårda X-gränsen innan postning, så för långa replies kortas fortfarande ned i stället för att skickas oförändrade.

X-sidans postningscredentials

Publikt är det viktiga bara detta:

• read-only-polling av mentions kan fungera med appnivåns läsbehörighet
• att faktiskt posta replies kräver giltiga X-sidiga user-context-skrivcredentials för botkontot
• även när sådana credentials finns kan X fortfarande neka postning om själva X-appen inte är konfigurerad för write access
• botens runtimebeteende styrs fortfarande från Tools admin, medan underliggande app-/kontobehörigheter på X-sidan är ett separat operatörsansvar utanför det publika botkontraktet

Adminsida

X-botten i Social Media Tools-admin används för att:

• slå av/på boten
• slå av/på reply-generering
• hålla dry-run på/av
• styra polling
• granska senaste interaktionerna
• se den senaste längdhistoriken direkt i tabellen när ett svar behövde en eller flera omkörningar för att passa teckengränsen
• approve/posta ett lagrat kandidatsvar
• köra reprocess / approve / skip på senaste interaktioner via AJAX direkt i tabellen
• opta in en avsändare igen direkt från ett interaktionskort när en sparad opt-out visade sig vara en falsk positiv
• låta Tools auto-approva svar efter ett randomiserat delay i stället för att svara på exakt samma crontid varje gång
• markera interaktioner som skip
• hantera opt-outs
• underhålla keyword-baserade svarsprioritetsprofiler som hjälper Tools att avgöra vilken svarsriktning som ska prioriteras för den inkommande mentionen
• läsa diagnostik

De senaste interaktionskorten visar nu också hårda refusals tydligare:

• om det lagrade kandidatsvaret i sig är non-replyable visas en egen blockeringsruta i kortet i stället för att det bara syns i expanderad diagnostik
• om X ändå skulle neka postningen (till exempel för att botten aldrig blev explicit engagerad i just den tråden) visar kortet en starkare hard-block-varning med orsaken och håller Approve/post avstängd
• inställningen Structured reply max attempts avvisar nu värden utanför intervallet med en tydlig 1–5-förklaring i stället för bara ett vagt invalid-data-fel

Adminsidan är nu också grupperad i tydligare operatörspaneler för:

• övergripande botstatus och snabbåtgärder
• konfiguration och aktiverade modes
• fallback instruction/mood samt keyword-baserad svarsprioritering
• diagnostik och blockers kring identitetsupplösning
• kvarstående runtimevarningar när en provider-side billing/spend cap blockerar botten
• opt-outs
• senaste interaktioner
• en dedikerad sida för händelseloggen, så att den stora runtimehistoriken kan ligga separat medan den vanliga X-bot-översikten hålls fokuserad på livekontroller och aktuell granskningskö

Diagnostikpanelen förklarar nu också den vanligaste förvirringen direkt:

• read-only-polling av mentions kan fungera med bara bearer/app-credentials
• att posta replies kräver fortfarande user-context-skrivcredentials
• om nödvändiga X-sidiga user-context-skrivcredentials saknas kan Tools fortfarande generera ett kandidatsvar men inte publicera det på X

AI/routing-sektionen förklarar nu också tydligare vad grok betyder i fälten:

• Known AI accounts in thread context betyder konton som grok som botten ska känna igen som andra AI-deltagare i en tråd
• Directed-command delegates betyder vanliga betrodda användarnamn som får be botten att uttryckligen adressera ett annat konto
• Trusted admin X usernames betyder extra betrodda operatörsanvändarnamn som botten ska lyssna extra mycket på för directed-account-kommandon
• Directed-command blocked target accounts betyder konton som grok som botten inte får ledas till att approacha via directed-account-läget

Opt-out-hanteringen är nu också striktare med avsikten. Generiska formuleringar som stop being stupid eller svenska sluta vara idiot behandlas inte längre som opt-out-kommandon bara för att de innehåller stop eller sluta. Tools väntar nu på tydligare opt-out-formuleringar som opt out, stop replying eller sluta svara innan en riktig opt-out sparas.

AI-sektionen innehåller nu också två nya fallbackfält:

• Fallback custom instruction: huvudinstruktionen som används när ingen starkare svarsprioritetsprofil matchar
• Fallback mood: det fria textfältet för grundton när ingen svarsprioritetsprofil overridear den. Nuvarande neutrala standard är neutral, dry, factual, men operatören kan fortfarande skriva en annan kort tonbeskrivning där.
• Required closing hashtags: valfritt avancerat fält, en hashtag per rad, till exempel #NewsTag och #ExampleTag; lämna det tomt om du inte uttryckligen vill tvinga fasta avslutande hashtags. När det används flyttar Tools dessa konfigurerade hashtags till allra sista delen av det slutliga svaret, i samma ordning, även efter lokal förkortning eller förberedelse inför repost/postning
• Watch keywords / trigger words: ord eller fraser som Tornevall som låter pollern ingestera relevanta publika poster även utan explicit @mention
• keyword-baserade svarsprofiler förstås bäst som ett prioriteringssystem för hjälpsam svarsriktning: till exempel ”om posten främst frågar om X-boten själv, prioritera det svaret först”, eller ”om posten främst ber om verifiering, prioritera ett fact-check-liknande svar först”
• Context format: välj mellan den äldre platta textprompten och en nästlad JSON-kontext
• Forward image URLs to AI: skicka faktiska bild-/media-URL:er från X till OpenAI som multimodala inputs i stället för att bara luta sig på textsammanfattningar
• Link handling enabled: när en synlig X-post innehåller externa länkar kan Tools nu också hämta ett kompakt server-side-utdrag från de sidorna och lägga in det i AI-kontexten i stället för att förvänta sig att modellen själv ska kunna läsa URL:en
• Max context posts accepterar nu värden upp till 50
• när den aktuella mentionen tillhör en längre konversation paginerar Tools nu längre bak i samma X-tråd innan svarskontexten byggs, så tidigare unkna/fientliga kommentarer i samma tråd lättare kan följa med när botten ombeds bedöma ton, misogyni eller återkommande beteendemönster
• replies som postades senare än den aktuella mentionen filtreras nu bort från den här tidigare-trådkontexten, så botten inte råkar behandla framtida kommentarer som om de redan hade funnits när det aktuella inlägget skrevs
• Max reply length accepterar nu också 0, vilket betyder “ingen lokal Tools-begränsning i antal tecken” (även om X självt fortfarande kan neka för långa liveposter)
• Prefix replies with @author är nu en explicit operatörstoggle, och Tools sparar nu också den inställningen korrekt igen när admin/API-konfigen sparas. Själva reply-trådningen kommer fortfarande från X-payloaden in_reply_to_tweet_id, så det synliga @username-prefixet är valfritt snarare än ett krav för att svaret ska bli en trådad reply
• även när den synliga prefix-togglen är avstängd ber livepostningen nu också X att exkludera författarens reply-mention från själva trådsvaret när det går, så svaret kan ligga kvar i tråden utan att auto-visa en ledande @username
• om ett genererat svar fortfarande är för långt för den effektiva gränsen försöker Tools nu först köra en kort AI-omskrivningsloop som komprimerar formuleringen innan systemet i sista hand faller tillbaka till hård trimning med …
• om ett genererat utkast fortfarande öppnar med frikopplad parafras som The message expresses... eller The post suggests... kör Tools nu ett extra direkt-svarsfixsteg så vanliga ask/explain-svar pressas tillbaka mot ett konkret svar i stället för att bara återberätta vad posten sade
• genererad reply-text normaliseras nu från Markdown till ren plain text innan den sparas eller postas, så Markdown-länkar som [etikett](https://example.com) plattas ut till vanlig text där den råa URL:en fortfarande syns korrekt på X
• strukturerad replygenerering fortsätter nu också genom hela femstegsstegen när inget publicerbart svar hittats ännu: fyra GPT-5-försök med stegvis starkare reasoning (low → medium → high → xhigh) och därefter ett sista fallback-försök med gpt-4o
• om en interaktion bara kom in via watch-keyword-polling/webhook-keyword-ingest och botten aldrig uttryckligen blev nämnd eller fick en reply från författaren håller Tools nu den interaktionen manuell för postning, eftersom X annars kan neka sådana replies med ett not-engaged-trådfel
• tydligt oengagerade uppföljningstrådar blockeras nu redan innan AI-genereringen ens startar, så Tools inte lägger betalda AI-försök på rader som X ändå redan skulle vägra på grund av uteblivet direkt engagemang
• en ny reply-regel med högsta prioritet overridear nu alla modes: botten ska gå rakt på det konkreta svaret eller omdömet, hoppa över preambler och scenbygge och aldrig öppna med formuleringar i stil med Kort svar:
• samma override förbjuder nu också punktlistor / numrerade minisammanfattningar i vanliga replies, så botten håller sig till rak löptext för trånga X/Twitter-svar
• samma topprioriterade override förbjuder nu också metaöppningar i tredje person som the commenter believes, the post says, the tweet criticizes eller you are saying that; utanför explicit summary-läge ska botten svara direkt på påståendet/frågan i stället för att först återberätta vad användaren skrev
• om någon bara taggar in botten utan att själv skriva något substantiellt utgår botten nu från att den ska läsa den tidigare synliga tråden och kommentera vad diskussionen handlar om
• explicita kortsvarsönskemål som Kortfattat!, briefly, short answer eller one sentence triggar nu en hårdare kortfattad-svarsväg med striktare promptinstruktioner, lägre output-tokenbudget och meningsmedveten eftertrimning
• när tråden redan namnger eller tydligt diskuterar en offentlig person instruerar bild-/multimodalprompten nu AI:n att diskutera den personen kontextuellt i stället för att reflexmässigt svara med generiska I cannot identify individuals-vägranden

Konfigurationspanelen beter sig nu också mer som en riktig operatörskonsol:

• centrala konfigfält kan sparas inline via AJAX vid blur/change
• senaste interaktionsåtgärder som Reprocess, Approve/post och Skip kör nu också via AJAX i stället för full sidomladdning
• pagineringen för senaste interaktioner kör nu också via AJAX, så sidbyte mellan lagrade interaktionssidor inte längre laddar om hela X-bottens adminsida
• tydligt icke-publicerbara rader döljs nu som standard i Recent interactions, med en uttrycklig toggle för Show non-publishable när operatören faktiskt vill se de blockerade diagnostikraderna också
• keyword-regelåtgärder som Add rule, Save rule och Delete rule kör nu också via AJAX i stället för att tvinga en full sidreload för varje regeländring
• listan över senaste interaktioner visar nu också hur många tecken varje lagrat kandidatsvar innehåller jämfört med den effektiva reply-gränsen och behåller senast lagrade postningsfel synligt i raden
• samma interaktionspayloads exponerar nu också ett maskinläsbart publicera/inte-publicera-beslut (should_publish, publish_block_reason_code, publish_block_message samt nästlat publication_decision), så script inte behöver gissa från fri text i ett refusalsvar
• uppenbara refusal-liknande kandidatsvar som I'm unable to assist with that. flaggas nu som explicita NOPE / publicera inte både i JSON-payloaden och i adminlistan för interaktioner
• senaste interaktioner renderar nu också den strukturerade reply-decision-payloaden i läsbart format (message, can_reply, status, vald modell/reasoning, alternativ och attemptsammanfattning) i stället för att bara visa ren reply-text
• senaste interaktioner använder nu badge-tunga kort med expanderbar sektion för beslut/diagnostik, så operatören snabbt kan skanna status, publicerbarhet, modellväg, teckenanvändning och antal omkörningar och bara öppna de djupare attempt-/raw-payload-detaljerna när det behövs
• den expanderade diagnostiken visar nu också grundläggande trådfångstdata, till exempel hur många historiska poster som sparades för interaktionen, hur många remote konversationssidor som hämtades och om senare trådreplies ignorerades för att de låg utanför den tidigare kontexten
• rå serialiserad interaktionspayload lazy-loadas nu först när operatören uttryckligen öppnar raw-payload-togglen, så vanlig sidsökning mycket mer sällan drunknar i jättestora JSON-block
• äldre interaktionsrader som skapades innan reply-length-metadata började sparas faller nu tillbaka till den aktuella lokala Tools-gränsen (260 som standard) i stället för att vilseledande visa 280
• listfält som known AI accounts, directed-command-listor för delegates/admins/blockerade targets och watch keywords har nu explicita Clear list-knappar och kan tömmas rent
• transportfel från X självt eller från server-side-hämtning av länkade sidor/media visas nu som strukturerade diagnostik-/runtimefel i stället för att krascha hela X-botsidan med ett rått 500-fel
• webhookkrascher i CRC-/delivery-vägen sparas nu också som explicita webhook_*_failed-händelser och kan vidarebefordras till Slack via kategorin audit_x_bot, så operatören äntligen kan se varför webhook-setup eller delivery-hantering gick sönder
• om X returnerar exakt postningsfelet You are not permitted to perform this action. förklarar Tools nu att detta normalt är ett X-side-problem med write/reply-behörighet för appen/tokenparet snarare än ett teckenlängdsproblem
• om X returnerar not-engaged-trådfeltexten (Reply to this conversation is not allowed because you have not been mentioned or otherwise engaged...) förklarar Tools nu att botkontot aldrig uttryckligen drogs in i just den konversationen och att postning därför bör förbli manuell tills botten faktiskt nämns/replyas in där
• om en botkörning blockeras av en provider-side billing/spend cap håller diagnostikytan nu kvar en tydlig varningsruta tills nästa lyckade X-bot-körning automatiskt rensar bort den igen, och varningen förklarar nu också att blockeringen kan komma från ett separat project/account-spend cap även när förbetalda credits fortfarande finns kvar

Interaktionspayload: maskinläsbart beslut om publicering

Payloaden för senaste/admin/API-interaktioner innehåller nu också explicit metadata om huruvida ett svar bör publiceras, så externa script kan stanna på en tydlig boolean i stället för att försöka tolka kandidatsvaret själva.

Additiva interaktionsfält:

• reply_decision.message
• reply_decision.can_reply
• reply_decision.status
• additivt reply_decision.independently_verified
• additivt reply_decision.verification_policy (required, used, independently_verified, state, additivt reason_code, additivt message, additivt fallback_used)

reply_decision.verification_policy.state kan nu vara not_required, verified, independent_verification_missing eller normal_mode_fallback. Det sista betyder att den ursprungliga prompten såg verifieringstung ut, men att ToolGPT medvetet försökte igen utan webbsökning och sparade ett vanligt kontextbaserat svar i stället för att posta en standardsats om saknad verifiering.

• reply_decision.model
• reply_decision.reasoning_effort
• reply_generation.selected_candidate
• reply_generation.alternatives[]
• reply_generation.attempts[]
• reply_generation.non_replyable_attempts
• reply_generation.max_attempts
• reply_decision_human[]
• should_publish
• publish_block_reason_code
• publish_block_message
• publication_decision.should_publish
• publication_decision.reason_code
• publication_decision.reason_message
• publication_decision.source
• publication_decision.display_state
• publication_decision.display_label

Nuvarande beteende:

• X-botten ber nu OpenAI att returnera ett strukturerat JSON-beslut för reply i stället för bara ren löptext
• de obligatoriska JSON-fälten är message, can_reply och status; additiva fält kan också dyka upp när modellen vill lämna nyttig operator-/debuginformation
• om den strukturerade responsen ändå ser ut som en vägran (I cannot assist with that, Jag kan inte hjälpa till med det och liknande) tvingar Tools can_reply=false även om modellen glömde sätta det själv
• när ett strukturerat försök kommer tillbaka som icke-svarbart formulerar Tools om nästa försök med tidigare refusal-/statuskontext så att botten får en ny chans att ge ett smart användbart svar i stället för att stanna direkt
• GPT-5-svar trappar nu upp reasoning effort stegvis (low → medium → high → xhigh) tills ett användbart strukturerat svar finns, och Tools ber därefter också gpt-4o om ett additivt alternativt kandidatsvar för operatörssynlighet
• om GPT-5-spåret aldrig producerar ett svarbart strukturerat svar faller Tools tillbaka helt till gpt-4o
• vanliga köade kandidatsvar returnerar fortfarande should_publish=true
• om det slutliga strukturerade beslutet säger can_reply=false returneras should_publish=false även om det fortfarande finns en plain-text-kandidat sparad för inspektion
• uppenbara refusal-/vägranskandidater returnerar nu should_publish=false med reason code candidate_refusal
• ett svar som redan har postats returnerar fortfarande should_publish=false, men exponerar nu också publication_decision.display_label="Already posted" så operatörsgränssnitt inte visar det som ett nytt blockeringsfall av typen Do not publish
• blockerade / opt-out / skip / failed / rate-limited / redan-postade rader returnerar också should_publish=false
• detta är bara additiv metadata; befintliga fält för status, error och candidate reply finns kvar oförändrade

Keyword-baserade svarsprioritetsprofiler

X-botten stödjer nu enkla keyword-styrda regelrader inspirerade av flödet i Mail Support Assistant.

I praktiken förstås de bäst som svarsprioritetsprofiler:

• en del säger vad posten verkar handla om
• en del säger vilken svarsriktning som ska prioriteras
• en del säger vilken ton som ska användas om den profilen vinner

Viktig migreringsnotering:

• regel-UI:t bygger på databastabellen x_bot_rules
• om en äldre miljö har adminsidan men ännu saknar tabellen måste du först köra php artisan migrate
• tills den migreringen finns fortsätter X-botten nu att köra med bara fallback instruction + fallback mood i stället för att krascha hela sidan

Varje regel har:

• IF / keywords
• INSTRUCTIONS
• MOOD

Nuvarande matchningsbeteende:

• botten tittar på den inkommande mention-texten och den synliga inhämtade trådkontexten för interaktionen
• samma regelmatchning gäller nu också poster som kom in via watch-keyword-sökningen
• keywords/fraser kan skrivas en per rad eller separeras med kommatecken/semikolon
• interpunktion normaliseras bort före matchning, så Donald Trump? och Donald Trump beter sig likadant
• den aktiva regel som får högst matchpoäng vinner
• vinnande regel kan overridea fallback instruction och/eller fallback mood för just det svaret
• den avsedda användningen är att prioritera den mest hjälpsamma svarsriktningen först, till exempel ”svara som botförklaring först” eller ”svara som verifiering/fact-check först”

Tråd-backfill och bifogad media

Botten bygger nu kontext från mer än bara den senaste X-posten.

Nuvarande beteende:

• Tools hämtar fortfarande den aktuella tweeten direkt
• den går nu också bakåt i reply-kedjan så parent-tweets finns kvar när senaste meddelandet bara är en kort uppföljning som “answer it”
• recent-search för conversation används sedan som komplement i stället för att vara enda trådkällan
• när den synliga tråden är längre än det konfigurerade promptfönstret försöker Tools nu bevara både trådstartens ankare och de senaste svaren i stället för att bara behålla de nyaste posterna
• den slutliga AI-prompten märker nu upp tråden som oldest first så modellen lättare kan följa ordningen
• om tidigare trådposter finns med ska botten nu behandla dem som implicit relevanta som standard även när den senaste posten inte uttryckligen säger “använd tidigare kontext”
• botten instrueras nu också uttryckligen att inte svara som om tidigare diskussion saknas när Tools redan skickat med de tidigare trådposterna i prompten

Bifogad media hanteras också mer ärligt nu:

• X-uppslag för tweets begär nu media-metadata och alt-text när X exponerar det
• AI-prompten innehåller fortfarande en kompakt mediasummering för tweets som har bild-/videometadata
• när Forward image URLs to AI är aktiverat vidarebefordrar botten nu också bild-URL:er som X exponerar (samt preview-image-URL:er när det är den enda visuella URL:en som finns) som multimodala OpenAI-inputs
• samma bildväg försöker nu också hämta bilden server-side och bädda in den som inline-bilddata när det går, med vanlig remote URL som fallback när inline-hämtningen inte fungerar eller blir för stor
• när Context format står på Structured JSON skickar botten nu ett nästlat JSON-objekt med inkommande post, mode-metadata, synliga kontextposter, reply constraints och vidarebefordrade bild-URL:er i stället för bara en platt prosablocksprompt
• när samma tweet finns både i live-uppslaget från X och i Tools lokala konversationsarkiv vinner nu live-raden för överlappande post-id:n, så bifogad media bevaras i stället för att ersättas av en äldre lokal dubblett utan mediapayload
• interna X/Twitter-attachment-länkar som /status/.../photo/1 eller /video/1 ignoreras nu som vanliga linked-page-länkar när riktig tweetmedia redan finns bifogad, så AI:n inte lika lätt svarar som om den bara såg attachment-sidans URL i stället för själva bilden
• om X bara visar att en bild finns men inte ger någon användbar beskrivning eller användbar bild-URL instrueras botten nu att säga det rakt ut i stället för att låtsas att den kan läsa råa pixlar

Det betyder att botten nu kan reagera bättre på uppföljningar som “kolla bild 2” när X exponerar antingen användbar media-metadata eller riktiga bild-URL:er, samtidigt som den fortfarande är sanningsenlig när plattformen inte ger tillräckligt med detaljer.

Kontextformat och multimodal vidarebefordran av bild-URL:er

X-botten har nu två operatörsstyrda promptkontroller:

• Context format
• Forward image URLs to AI
• Historical context max posts

Context format

Tillgängliga lägen:

• Structured JSON
• Flat text

Nuvarande beteende:

• Structured JSON är nu standard
• Tools bygger ett nästlat JSON-paket med inkommande post, mode-metadata, kända AI-konton, sanerade kontextposter, vidarebefordrade bild-URL:er och reply constraints
• Flat text behåller den äldre radbaserade promptlayouten för operatörer som vill ha legacy-stilen kvar

Forward image URLs to AI

När detta är aktiverat:

• Tools bevarar media-URL:er från X-kontextposter när X exponerar dem
• dessa URL:er skickas vidare till OpenAI som multimodala image_url-block tillsammans med textprompten
• när servern kan hämta bilden säkert försöker Tools nu hellre bädda in bilden som inline-data i OpenAI-anropet i stället för att bara hoppas att OpenAI kan läsa den externa URL:en själv
• foto-/bild-URL:er prioriteras direkt
• video-/animated-gif-rader kan falla tillbaka till preview-image-URL:er när det är den enda visuella URL som X lämnar ut

Link handling enabled

När detta är aktiverat:

• Tools bevarar nu normaliserad extern URL-metadata från den synliga X-tråden
• systemet försöker hämta några få länkade sidor server-side över HTTP(S)
• lyckade hämtningar reduceras till kompakta titel- och excerpt-sammanfattningar som läggs in i AI-kontexten
• det gör det mer sannolikt att korta uppföljningar som “läs artikeln” eller “du missade länken” kan besvaras mot faktiskt hämtad sidtext i stället för bara tweet-kroppen

När detta är avstängt:

• Tools behåller fortfarande vanlig X-textkontext
• men externa länkar hämtas inte server-side för extra sidkontext

När detta är avstängt:

• Tools behåller fortfarande mediasummeringar / alt-text i den sanerade kontexten
• men vidarebefordrar inte längre råa bild-URL:er till OpenAI för direkt visuell analys

Historical context max posts

Detta styr det lokala per-konversationsarkivet, inte promptfönstret.

Nuvarande beteende:

• Tools lagrar nu konversationshistorik lokalt i X-bottens interaktionsmetadata så att äldre trådinnehåll fortfarande kan återanvändas även om ett inlägg senare försvinner från X
• den mindre inställningen Max context posts styr fortfarande hur mycket av den historiken som skickas till OpenAI i en enskild prompt
• Historical context max posts = 0 betyder i praktiken obegränsad lokal arkivretention för sparade konversationsposter
• när arkivet växer över en konfigurerad icke-nollgräns behåller Tools de senaste sparade historikraderna
• botten kan också behålla lokalt genererad reply-text i samma arkiv, så senare uppföljningar fortfarande kan syfta på vad botten redan sagt även om den externa tråden blivit ofullständig

Publik bot-identitet / versionsetikett

X-botten kan nu identifiera sig med en publik versionsetikett när någon uttryckligen frågar.

Nuvarande beteende:

• namn-delen hämtas nu från den synkade X-kontoidentiteten (display_name, annars username)
• versions-suffixet är fortfarande operatörskonfigurerbart via bottens inställningar/runtimekonfiguration

Beteende:

• när en användare uttryckligen frågar vem/vilken version botten är kan den svara med något som ToolsGPT-v0.1.0, där ToolsGPT hämtas från själva X-kontot
• versionsetiketten är inte tänkt att hamna i vanliga svar, utan bara i uttryckliga frågor av typen “vem är du / vilken version är du?”

Watch keywords / trigger-word-polling

Botten kan nu ingestera två olika publika X-källor:

• direkta @mentions / replies till botkontot
• publika poster som matchar konfigurerade bevakningsord som Tornevall

Relevanta inställningar:

• Only explicit @mentions
• Watch keywords / trigger words

Beteende:

• när Only explicit @mentions är Yes ignoreras watch-keyword-listan och det äldre mention-only-beteendet ligger kvar
• när den är No kör Tools också en recent-search-fråga mot de konfigurerade bevakningsorden under poll-varven
• matchande keyword-poster lagras i samma x_bot_interactions-flöde som direkta mentions
• därefter används samma svarsprioriteringsutvärdering för dessa poster så att Tools kan avgöra vilken svarsriktning som är mest hjälpsam först

Detta passar till exempel för att routa mentions om:

• billing/betalning
• support/problem/error
• klagomål/abuse
• skämtsam/banter-ton

Auto-approve-delayfönster

Botten kan nu auto-approva replies efter ingest/processing även när du normalt vill behålla manuell approval synlig.

Inställningar:

• Auto-approve after ingest
• Auto-approve min delay (seconds)
• Auto-approve max delay (seconds)

Beteende:

• Tools väljer ett slumpat delay inom detta intervall
• det förfallna svaret postas från det normala poll-varvet i stället för att alla replies skjuts iväg på exakt samma sekund i cron
• om Manual approval required sätts till No är replies redan tillåtna att postas i nuvarande/nästa poll-varv även när den explicita randomiserade auto-approve-togglen är av
• om manuell approval fortfarande är på och auto-approve är av ligger svaret kvar i review-läge som tidigare

Lokala Tools-rate-limits kontra X-rate-limits

Reply-capparna i X-bottens inställningar är lokala Tools-säkerhetsgränser:

• replies per användare och timme
• replies per konversation och timme
• globalt antal replies per dag

Dessa är separata från eventuella rate limits hos X-plattformen.

Nuvarande beteende:

• om den konfigurerade AI-ägaren är en adminanvändare bypassar Tools nu dessa lokala limits helt
• externa X API-rate-limits kan fortfarande slå till och hanteras fortfarande av X självt

Notifieringar under manuell approval

När manuell approval krävs kan botten nu notifiera operatören om riktiga runtime-händelser.

Nuvarande notifieringskontroller:

• Notify on manual-review events
• Mail notifications
• Slack notifications

Mail använder den konfigurerade support-/varningsmottagaren när den notifieringsvägen är aktiverad.

Slack använder den dedikerade Slack-loggroutningskategorin audit_x_bot.

Webhook-ingest (primär realtidsväg)

X-botten stödjer nu också en första publik webhook-endpoint som kan registreras i X developer portal.

Webhook-URL:

• https://tools.tornevall.net/api/x-bot/webhook
• lokal/dev-variant beror på aktuell host, men adminpanelen visar nu också den exakt beräknade URL:en

Routes:

GET  /api/x-bot/webhook
POST /api/x-bot/webhook

Nuvarande beteende:

• webhook-ingest kan slås på/av från X-bottens admininställningar
• signerade webhook-POST:ar är den föredragna realtidsvägen för ingest
• polling finns kvar som fallback, manuell synk och recovery
• om samma mention hittas både via webhook och polling används fortfarande samma x_post_id för dedupe, så webhook-metadata vinner utan att en andra interaktion skapas

Förutsättningar för webhook-stöd:

• giltiga X-appcredentials med stöd för webhook/CRC på operatörssidan
• botkonfigurationen webhook_enabled=true i Tools admin

Nuvarande implementation auto-registrerar inte webhook-subscriptionen åt dig i X-portalen. Själva registration/subscription-steget görs alltså fortfarande i X developer dashboard, där du anger URL:en ovan och låter X verifiera CRC-svaret.

Inställningsfält som nu också exponeras i botens config/status är:

• webhook_enabled
• webhook_url
• webhook_last_received_at
• webhook_last_processed_at
• webhook_last_error_at
• webhook_last_error

CRC-verifiering

GET /api/x-bot/webhook?crc_token=... returnerar det CRC-svar som X kräver.

Tools använder den konfigurerade X-apphemligheten för att bygga svaret.

Signerad POST-verifiering

Webhook-POST:ar verifieras innan payloaden litas på.

Nuvarande beteende:

• Tools läser rå request body
• verifierar X webhook-signaturen med consumer secret
• lagrar en XBotEvent
• dispatchar köhantering för payloaden
• returnerar snabbt med HTTP 200 när leveransen accepteras

Webhook-controllern genererar inte AI-svar och postar inte direkt till X. Den ingestar bara och lägger arbete på kö.

Queue worker-notering

Webhook-ingest blir snabbast när en riktig queue worker kör.

Exempel:

php artisan queue:work

Om miljön fortfarande använder QUEUE_CONNECTION=sync fungerar webhookflödet ändå, men köhoppet sker då inline under samma request i stället för via en separat worker.

Okända eventgrupper

Okända eller ännu ej hanterade eventgrupper lagras fortfarande som XBotEvent för diagnostik, men de behandlas inte som replybara interaktioner.

Direct-message-event kan loggas, men auto-besvaras inte som standard.

X-rate-limits och automatiska retryfönster

X-botten lagrar nu de senaste X rate-limit-headers den sett för read- och write-anrop.

Fält som nu också exponeras i config/status är:

• remote_read_rate_limit
• remote_write_rate_limit

Varje sparat block kan innehålla värden som:

• limit
• remaining
• reset_at
• next_allowed_at
• last_checked_at
• last_status
• source

Beteende:

• om polling tidigare slog i ett externt X read-rate-limit-fönster pausar senare poll-körningar nu automatiskt tills reset-tiden har passerat
• om reply-postning slår i ett externt X write-rate-limit-fönster hålls interaktionen retrybar i stället för att behandlas som permanent failad
• adminpanelen visar nu också senaste kända read/write-fönster så operatören ser när det är säkert att försöka igen

Konsol- och cronkörning

Du kan polla botten manuellt från projektroten med Artisan:

php artisan x-bot:poll-mentions

Om du vill läsa in/spara nya mentions utan att köa vidare processing-jobb ännu använder du:

php artisan x-bot:poll-mentions --no-dispatch

Om du vill åsidosätta den lagrade lokala poll-interval-gaten en gång från shell använder du:

php artisan x-bot:poll-mentions --now

Det finns nu också enkla wrapper-skript i repository-roten:

./run-x-bot
./run-x-bot --now
./run-x-bot --no-dispatch
./run-x-bot.sh
./run-x-bot.sh --now
./run-x-bot.sh --no-dispatch

I vanliga Windows-konsoler utanför WSL använder du:

run-x-bot.bat
run-x-bot.bat --now
run-x-bot.bat --no-dispatch

Normal produktionskörning går fortfarande via Laravel-schedulern, där x-bot:poll-mentions redan är schemalagd varje minut genom php artisan schedule:run.

Samma poll-varv kontrollerar nu också förfallna auto-approve-fönster, så fördröjda replies fortfarande kan postas även med nuvarande sync-queue-upplägg.

Mention-polling går nu också igenom flera X-resultatsidor per körning i stället för bara första sidan, vilket minskar risken att burstig mention-trafik bara delvis ingestas och sedan missas.

AI-defaults och fallback

Nuvarande operatorriktning är nu:

• primär reply-modell: gpt-5.4
• primär fact-check-modell: gpt-5.4
• default reasoning effort: high
• huvudsaklig strukturerad fallback-/alternativmodell: gpt-4o

Om det primära GPT-5-spåret fallerar, fortsätter returnera icke-svarbar JSON, nekar reasoning-flaggan eller producerar tom output försöker X-botten nu säkrare om med stegvis starkare reasoning och faller sedan tillbaka till gpt-4o i stället för att lämna interaktionen utan kandidatsvar. Lägre hjälprutiner för förkortning/reparation kan fortfarande använda mindre fallbackmodeller när de bara komprimerar ett redan genererat svar.

ToolsAPI

Den första ToolsAPI-ytan innehåller endpoints för:

• botstatus/config
• diagnostik
• senaste interaktioner
• en interaktion
• reprocess
• approve/post
• skip
• opt-outs

Status/config-svaren innehåller nu också additiva X-bot-regler plus de nya fallback-/notifierings-/auto-approve-inställningarna, så behöriga operatörsklienter kan hållas i synk med webbpanelen.

Inställningspayloaden innehåller nu också:

• context_format (text|json)
• image_url_forwarding_enabled (true|false)

Interaktioners context_meta kan nu också innehålla:

• context_format
• image_url_forwarding_enabled
• forwarded_image_urls[]

Viktigt om postning

Att posta svar till X kräver user-context-skrivcredentials.

Om bara bearer/app-credentials är konfigurerade kan mention-läsning/lookup fortfarande fungera beroende på plan, men reply-postningsdiagnostiken kommer att rapportera att write credentials saknas.

Om credentials finns men X svarar med ett oauth1 app-permissions-fel betyder det normalt att Tools når X korrekt — den återstående fixen ligger då vanligen i X developer-appens konfiguration, inte i Tools självt.

Publika referenser för allmänna frågor

Om någon ställer breda eller tekniska frågor på publik nivå är dessa referenser säkrast:

• https://tools.tornevall.net
• X mention-bot / ToolGPT-dokumentationen
• ToolGPT-ändringslogg

Publika svar ska fokusera på:

• synligt beteende
• publik dokumentation
• kvalitetsförbättringar som redan märks i botens publika beteende

Publika svar ska inte innehålla dolda prompts, credentials, intern infrastruktur eller exakt privat runtime-konfiguration.