Gå till innehållet

Så hanterar mintbot filer

När du skickar ett foto, ett dokument, ett röstmeddelande, ett kalkylark, en skärmbild eller en PDF till din mintbot-agent — via Telegram, webbpanelen eller API:t — sparas filen på din agents egen VPS och ingen annanstans. Den ligger kvar så länge du vill, och LLM:en får en arbetskopia som är förberedd för den.

Det är ett tyst designbeslut med stora följder. Det är värt att förklara, eftersom det är ett av de ställen där mintbot skiljer sig mest från vanliga AI-chattar.

Diagram: en uppladdad fil sparas som original på din agents VPS; en adapter som väljs efter filtyp gör en arbetskopia åt LLM:en
Originalet ligger orört på din VPS — modellen ser bara en arbetskopia som gjorts åt den.

Flödet från början till slut

  1. Uppladdningen når agentens VPS. En PDF som du drar in i webbpanelen går direkt till din VPS. Ett foto eller en fil som du skickar i Telegram hämtas från Telegram av mintbot-boten och skickas direkt vidare till din VPS — den förmedlas bara och lagras aldrig centralt. Agentens lokala API kontrollerar filens magic bytes för att ta reda på vad det egentligen är för fil (telefoner och webbläsare märker filer fel förvånansvärt ofta), beräknar en SHA-256-hash och skriver den till /var/lib/mintbot-agent/uploads/<shard>/<sha256>.<ext>. En rad i en lokal katalog registrerar källan (telegram / panel / api), uppladdarens ID, MIME-typ och ursprungligt filnamn. Skickar du samma fil två gånger sparas den ändå bara en gång.

    Om konversationen sker i ett projekt lägger agenten också en kopia i projektets mapp uploads/, så att den kan arbeta med filen precis bredvid resten av projektet.

  2. Originalet är heligt. Från och med nu ändrar ingenting i mintbot den sparade filen. Adaptrarna som förbereder den för LLM:en gör bara arbetskopior — nedskalade JPEG-filer, avkodad text. Originalet, identiskt in i minsta byte, ligger kvar på disken tills du raderar det. Det finns ingen central lagring, ingen lagringstimer och inget läckage mellan agenter: varje agents VPS känner bara till sin egen ägares filer.

  3. Modellen får en version som är gjord för den. När agenten visar filen för LLM:en väljer en liten dispatcher rätt adapter utifrån MIME-typ och filändelse:

    Adapter Hanterar Vad modellen får
    Bild JPG, PNG, WebP, GIF, HEIC (iPhone), AVIF, TIFF, BMP Nedskalad till 1568 px på långsidan, omkodad som JPEG q85 och inbäddad direkt i anropet. Avkodningen körs i en separat, kortlivad process med en minnesbudget anpassad efter din VPS, så att ett jättestort foto inte kan göra agenten långsam
    PDF .pdf upp till 32 MB Inbäddad som riktig PDF — Claude läser text och layout direkt. En större PDF ligger kvar på disken och agenten plockar själv ut texten (t.ex. med pdftotext)
    Text .txt, .md, .csv, .json, .yaml, .svg, källkod (.py, .js, .ts, .go, .rs, …), loggar, diffar Avkodad som UTF-8 (latin-1 som reserv) och inbäddad upp till 500 KB; en längre fil kapas där, och hela originalet ligger kvar på disken
    Ljud .mp3, .ogg, .opus, .m4a, .wav, .flac, .aac Röstmeddelanden från Telegram och panelens mikrofon kommer redan transkriberade. En ljudfil transkriberas ännu inte automatiskt — agenten får veta var den ligger och hur den ska hanteras, och transkriberar den när du ber om det
    Video .mp4, .mov, .webm, .mkv, .avi Extraheras ännu inte automatiskt. När du ber om det installerar agenten ffmpeg (och berättar först hur mycket diskutrymme det tar) och plockar själv ut bildrutor eller ljudspåret
    Office-dokument .docx, .xlsx, .pptx, äldre .doc / .xls / .ppt, .odt, .ods, .odp Extraheras ännu inte automatiskt. När du ber om det installerar agenten ett litet läsbibliotek och plockar ut texten
    Okänd Allt annat En notering med filens namn, typ, storlek och plats på disken samt de första byten i hex — tillräckligt för att modellen ska känna igen filen och öppna den med sina verktyg när uppgiften kräver det

    Varje arbetskopia cachas bredvid originalet som <sha256>.cache/v<N>.json, så nästa gång modellen behöver filen finns den till hands direkt. När en adapter ändras byggs cachen om av sig själv.

  4. Inga tidsbegränsade URL:er i modellens kontext. När en bild eller en PDF skickas till LLM:en bäddas den in i samma anrop — ingen URL som kan ge 404 senare, ingen signerad länk med utgångstid. Där modellen bara behöver en hänvisning är URL:en en intern https://agent<id>.<domain>/<panel_token>/api/local/uploads/<upload_id>/raw — skyddad av din agents egen paneltoken och giltig så länge filen finns på disken.

Varför det slår vanliga AI-chattar

När du laddar upp ett foto till ChatGPT eller en PDF till Claude.ai hamnar filen i leverantörens lagring, kopplad till den konversationen, och leverantörens lagringspolicy avgör när den försvinner. Efter en viss tid är filen borta, även om du fortfarande kan se konversationen den hörde till. Att byta leverantör innebär att börja om från början.

En vanlig fallgrop för Telegram-bottar gör skillnaden konkret. Telegram behåller ett permanent file_id för varje foto, men nedladdningslänken som en bot får för det är bara garanterat giltig i ungefär en timme. Bottar som bara sparar den länken ger 404 för gårdagens foto. mintbot kopierar filen till din agents arkiv i samma stund som den kommer — och svarar du på ett äldre foto hämtar den det igen via det permanenta file_id. Från och med då är fotot ditt.

Tre saker följer av den här designen:

  • Filerna tillhör dig, inte LLM-leverantören. Byter du från Claude till GPT nästa månad följer din filhistorik med, orörd, eftersom den ligger på din VPS — inte i en leverantörs lagring.
  • Du kan fråga igen senare. ”För tre månader sedan analyserade du ett avtal åt mig — kan du jämföra det med det här nya utkastet?” fungerar, eftersom originalet fortfarande ligger på disken. I en vanlig AI-chatt är den äldre filen oftast borta.
  • Modellen får alltid den version den kan använda bäst. Bildmodeller får den nedskalade JPEG-filen, textläsare får UTF-8, PDF-läsare får riktig PDF. Telefoner kan ladda upp HEIC och det bara fungerar — bildavkodaren laddar Pillows HEIF-plugin, och kontrollen av magic bytes fångar telefoner som felaktigt märker uppladdningen som application/octet-stream.

Var du hanterar dina filer

Agentens webbpanel har en filhanterare under Inställningar → Filhanterare. Den visar hela agentens VPS; uppladdningsarkivet i /var/lib/mintbot-agent/uploads/ är den del som dina konversationer fyller. Där kan du:

  • Bläddra i mappar och ladda ner, byta namn på, flytta eller radera filer
  • Skapa mappar
  • Dra och släppa nya filer — de laddas upp i delar, upp till 4 GB per fil
  • Redigera små textfiler (upp till 1 MB) direkt i webbläsaren

Storleksgränser: en fil som du bifogar i chatten får vara upp till 500 MB; Telegram låter bottar hämta filer på högst 20 MB; Filhanterare tar emot upp till 4 GB per fil. Utöver det är den enda gränsen din disk — mintbot lämnar alltid lite ledigt utrymme så att servern fortsätter att fungera. Om disken blir full säger agenten till och länkar direkt till Filhanterare så att du kan frigöra utrymme — eller så ber du helt enkelt agenten att radera gamla filer.

Raderar du en fil i Filhanterare tas den bort från disken, och agenten kan inte längre visa den för LLM:en. Det är det som gör originalet till ”ditt”: bara du kan radera det.

Sammanfattning

De flesta AI-chattar behandlar dina uppladdningar som engångskontext i en konversation. mintbot behandlar dem som dina data — sparade på din VPS, ägda av dig och omformade vid behov till exakt den form modellen behöver just då. Många av mintbots mer intressanta funktioner vilar på den här grunden.