DEV Community: tauchiii

Qu'est-ce qu'osFoundry et comment cet espace de travail IA pour le bureau est-il organisé ?

tauchiii — Fri, 06 Nov 2026 15:54:47 +0000

Lundi, 9 h 40, quatre onglets ouverts dans le navigateur : un chatbot pour les questions, un deuxième parce que vous ne faites pas entièrement confiance au premier, un éditeur avec un agent de code et une appli de notes qui contient les recherches de la semaine dernière. Chacun connaît une partie de votre travail, aucun ne connaît le reste. Avant midi, vous avez déjà copié le même paragraphe de contexte dans trois fenêtres différentes.

Une seule appli au lieu de cinq onglets

osFoundry est un espace de travail IA pour le bureau : une appli où vous discutez avec des modèles d'IA, confiez du travail à des agents et à des équipes d'agents, gardez des notes et des connaissances consultables, faites tourner des modèles ouverts sur votre propre ordinateur et créez de petites applis pour votre équipe. Les modèles peuvent venir de trois sources : votre propre machine, des fournisseurs cloud via vos propres clés d'API, ou des GPU cloud loués. L'appli est organisée en catégories, et chaque catégorie regroupe plusieurs écrans. Chat sert à parler aux modèles (Maestro, Multi chat, Branchspace et d'autres). Workstation, c'est là que les agents font les tâches longues (Code, Agent, Agent team, Loop, Terminal). Knowledge contient vos écrits et ce que l'IA retient. Local Model sert à trouver, installer et tester des modèles ouverts. Custom App est destiné aux outils internes, et Discover à la recherche web et à l'actualité. Si vous connaissez VS Code, la comparaison la plus proche est un éditeur avec une barre d'activité où chaque icône ouvre un outil différent, sauf qu'ici les outils sont des surfaces d'IA qui partagent les mêmes projets, la même mémoire et les mêmes modèles.

À quoi ressemble un écran type

La plupart des gens commencent par la catégorie Chat, c'est donc un bon point de départ pour comprendre comment sont construits les écrans d'osFoundry. Voici Multi chat en mode Council, avec des données d'exemple : on a posé la même question à trois modèles, puis chacun a noté les réponses des autres.

La rangée d'onglets en haut (Maestro, Model chat, Multi chat, Research, Wiki, Code) bascule entre les surfaces de l'espace Chat : l'agent Maestro complet, un chat simple de questions-réponses avec sources citées, plusieurs modèles à la fois, la recherche approfondie, la documentation de code et les agents de code.
Le sélecteur Compare / Council détermine comment les modèles travaillent ensemble. Compare affiche les réponses côte à côte pour que vous jugiez vous-même. Council les fait répondre séparément, se classer mutuellement à l'aveugle, puis rédige une synthèse.
Chaque colonne correspond à un modèle avec une étiquette de fournisseur : ici Anthropic, Ollama (en local) et OpenAI. Vous pouvez mélanger modèles cloud et modèles locaux sur le même écran.
Le panneau de droite affiche les étapes de l'exécution (Answers, Ranking, Synthesis) et la grille Peer review, pour voir qui a donné quelle note au lieu de lire seulement une réponse finale.
Le bouton Run indique combien d'appels aux modèles l'exécution va faire avant même que vous cliquiez (« Run · 7 calls » ici). Désactiver le classement par les pairs fait baisser ce chiffre.

Beaucoup d'écrans d'osFoundry suivent ce schéma : une liste à gauche, le travail au centre et, à droite, un inspecteur qui montre comment un résultat a été obtenu.

La première semaine d'un développeur solo

Ken gère seul une petite boutique en ligne. Il veut une IA qui connaisse son code et aimerait garder une partie du travail sur son portable.

Lundi, il ouvre Local Model, puis Explore. L'écran analyse d'abord sa machine (16 Go de mémoire dans cet exemple) et colle un badge sur chaque modèle ouvert : Fits, Tight ou Too big. Il installe un modèle au badge vert et lui pose quelques questions dans Playground, qui envoie le même prompt à deux modèles côte à côte et montre à quelle vitesse chacun a commencé à répondre.

Mardi, il doit modifier une fonction de formatage des prix et ne sait pas trop ce qui en dépend. Il ouvre le projet dans l'IDE, fait un clic droit sur la fonction et choisit Show Code Graph.

Le panneau liste tous les appelants, indique quels liens ont été lus directement dans le code et lesquels sont seulement déduits, et résume l'Impact of change : combien de symboles, de fichiers et de tests pourraient être touchés. Il clique sur un appelant pour sauter à la ligne concernée et utilise Send to chat pour amener le graphe dans une conversation avec Maestro.

Jeudi, il confie déjà de petites tâches à des agents de code. Dans l'écran ADE, chaque tâche a son propre worktree, et l'onglet Changes affiche le diff. Il clique dans la marge à côté d'une ligne qui ne lui plaît pas, tape une note et envoie d'un coup à l'agent toutes les notes en attente. Il termine la semaine avec un modèle local en qui il a confiance pour les questions rapides, et le réflexe de vérifier l'impact avant de refactoriser.

La première semaine d'une responsable de petite équipe

Aiko encadre quatre personnes et livre une version toutes les deux semaines. Son problème n'est pas d'écrire du code, mais de savoir ce que fait chacun, humain ou agent.

Elle commence par Message, le chat d'équipe. Les canaux et les messages privés fonctionnent comme dans Slack, à une différence près : les agents IA sont membres des canaux. Quelqu'un mentionne un agent avec @ dans #release, et sa réponse comme son exécution reviennent dans le canal, où tout le monde peut les voir.

Ensuite, elle configure une Agent team dans Workstation. Un agent leader coordonne des membres spécialisés, et l'écran range Team mail, Handoffs, Sub-agents et Proposals dans des onglets séparés, ce qui lui permet de vérifier qui a transmis quoi à qui. Pour les contrôles qui reviennent à chaque version, elle transforme cette équipe en Loop : un déclencheur (par exemple, les matins en semaine), des limites de tours et de nouvelles tentatives, et des critères de réussite. Le Loop tourne par tours jusqu'à ce que les critères soient remplis et tient un registre de ceux qui ont été validés à chaque tour.

Quand plusieurs agents travaillent sur le même dépôt, elle utilise Code. Chaque agent a sa propre branche et son propre worktree, et rien n'est fusionné automatiquement. Elle sélectionne deux exécutions terminées, clique sur Preview combined merge et voit quels fichiers entrent en conflit avant que quoi que ce soit ne touche la branche principale.

Pour la revue ligne par ligne, elle utilise les mêmes notes que Ken : une note épinglée au code, envoyée à l'agent avec le fichier, la ligne et le code joints. À la fin de la semaine, elle dispose d'un canal où apparaît le travail des agents, d'un contrôle de version qui tourne tout seul et d'une étape de revue qui a lieu avant les fusions, pas après.

La première semaine d'une chercheuse et rédactrice

Lena rédige de longs rapports sur les politiques en entreprise. Elle a besoin de sources vérifiables, et des réponses d'IA trop sûres d'elles lui ont déjà joué des tours.

Pour les questions où la réponse d'un seul modèle ne suffit pas, elle utilise Multi chat en mode Council, l'écran présenté plus haut. Quand deux évaluateurs notent mal une réponse, elle sait qu'il faut creuser.

Pour les questions plus vastes, elle ouvre Agents, clique sur New session et choisit la Deep Research Team toute prête. Le leader découpe la question en parties et confie chacune à un membre, par exemple un Data Researcher ou un Search Specialist.

Un évaluateur distinct vérifie chaque étape avant qu'elle ne lui parvienne, et une étape sans source est renvoyée et relancée. La réponse finale arrive sous forme de tableau avec une source sur chaque ligne, plus une courte note sur les points où les sources divergent et sur ce qui n'a pas été couvert (données d'exemple dans la capture).

La rédaction elle-même se passe dans Knowledge. Dans Paper, elle surligne une phrase de son brouillon et y rattache un espace de réflexion, avec des onglets comme Academic search, Browser ou une session Maestro consacrée uniquement à ce passage. Les fichiers annexes et les commentaires vivent dans une Note. Dans Discover, elle enregistre des recherches dans Browser et suit des canaux par mot-clé dans News, si bien que ce qu'elle lit pour un rapport reste disponible pour le suivant.

Comment les espaces se passent le travail

Les catégories ne sont pas des produits séparés : elles se transmettent le travail. Local Model est la couche du dessous : un modèle installé depuis Explore apparaît dans les sélecteurs de modèle de Maestro, de Multi chat et des sessions d'agents.

Knowledge alimente Chat : Memory montre ce que Maestro sait de votre travail, et Indexed Folders vous permet de choisir dans quels dossiers les agents peuvent chercher. Les sessions d'agents, les exécutions d'Agent team et les Loops remontent dans les canaux de Message. Workstation (l'écran qui porte ce nom) vous permet d'ouvrir un canal, une note, un fichier et une session d'agent côte à côte dans une même disposition. Quand quelque chose que vous avez construit avec des agents doit devenir un outil pour l'équipe, il passe dans Custom App, où une Room réunit les applis d'une équipe à côté de son propre chat Maestro. Les clés et les fournisseurs pour tout cela se trouvent dans Configuration. La vue d'ensemble de la plateforme liste tous les écrans si vous voulez la carte complète.

Les questions de la première semaine

Dois-je tout utiliser ?
Non. La plupart des gens commencent par un seul espace, généralement Maestro dans Chat ou Explore dans Local Model, et en ajoutent d'autres quand une tâche l'exige. Les catégories partagent projets et mémoire, donc rien de ce que vous faites au début n'est à refaire plus tard.

Mes données quittent-elles mon ordinateur ?
Pas avec les modèles locaux : ils tournent sur votre appareil. Les modèles cloud que vous connectez avec vos propres clés d'API voient ce que vous leur envoyez, et cet usage est facturé par le fournisseur. La page local-first explique comment les deux sont séparés.

Est-ce réservé aux développeurs ?
Non. Code, IDE et Terminal sont des outils de développeur, mais Message, Paper, Note, Research, Multi chat et Discover sont aussi conçus pour les rédacteurs, les analystes et les responsables d'équipe.

Combien ça coûte ?
L'appli de bureau se télécharge gratuitement, et faire tourner des modèles locaux n'entraîne aucun frais d'utilisation côté osFoundry. Elle est disponible sur la page de téléchargement.

osFoundry के Code, IDE और Wiki कई AI एजेंट्स के साथ-साथ चल रहे कोडिंग काम को रिव्यू करने लायक कैसे रखते हैं

tauchiii — Fri, 06 Nov 2026 15:46:14 +0000

शाम के 4 बजे हैं और लंच के बाद से तीन कोडिंग एजेंट एक ही repository पर काम कर रहे हैं। एक ने कार्ट टोटल की राउंडिंग ठीक की, दूसरे ने डिस्काउंट कोड जोड़ा, तीसरे ने tests लिखे। तीनों कह रहे हैं "done"। main में कुछ भी जाने से पहले आप दो बातें जानना चाहते हैं: क्या दो एजेंट्स ने एक ही function दोबारा लिख दिया, और क्या तीनों बदलाव साथ मिलाने पर भी tests पास करते हैं?

एक codebase के लिए तीन स्क्रीन

osFoundry एक डेस्कटॉप ऐप है जो चैट, एजेंट्स, फ़ाइलें और टूल्स एक ही विंडो में रखता है, और कोड के लिए इसमें तीन जुड़ी हुई स्क्रीन हैं। Code वह जगह है जहाँ आप एक साथ कई एजेंट्स को काम सौंपते हैं: हर run को अपनी Git branch और अपना working folder (एक worktree) मिलता है, और कोई भी फ़ैसला लेने से पहले आप रिव्यू करते हैं, टेस्ट करते हैं और merge का preview देखते हैं। कुछ भी अपने-आप merge नहीं होता। IDE किसी लोकल फ़ोल्डर के लिए कोड एडिटर है, जिसमें explorer, source control, terminal, problems और tests पैनल हैं, और एक assistant कॉलम है जो देखता है कि आप कौन-सी फ़ाइल में हैं। Wiki आपकी मशीन पर मौजूद repository पढ़ता है और ऐसे documentation पेज लिखता है जो path:line का हवाला देते हैं, और जब उस हवाले वाला कोड बदलता है तो पेज को मार्क कर देता है। Code और Wiki, Maestro, Model chat, Multi chat और Research के बगल में टैब के रूप में हैं; IDE का साइडबार में अपना अलग आइटम है। अगर आप Git पैनल वाले VS Code से परिचित हैं, तो IDE जाना-पहचाना लगेगा। Code किसी pull-request inbox जैसा ज़्यादा है, फ़र्क़ बस इतना है कि लेखक आपके एजेंट्स हैं और branches कभी आपके लैपटॉप से बाहर नहीं गईं।

Code टैब पर एक नज़र

इस स्क्रीन पर आप क्या देखते हैं (runs उदाहरण डेटा हैं):

रेल के ऊपर का बैनर। "3 agents finished · they disagree on 1 file" एक भी diff खोलने से पहले फ़ाइल का नाम बता देता है, यहाँ src/cart.js। Review together बटन एक साझा रिव्यू शुरू करता है।
run रेल। runs इस हिसाब से ग्रुप किए गए हैं कि उन्हें आपसे क्या चाहिए: Ready to review, Needs attention, और एक मुड़ा हुआ History। हर लाइन में टास्क, जोड़ी और हटाई गई लाइनें, एजेंट ने कितनी देर काम किया, और उसकी branch दिखती है।
बीच में बातचीत। किसी run पर क्लिक करें और पढ़ें कि एजेंट से क्या कहा गया था और काम करते समय उसने क्या कहा।
दायाँ पैनल। Changes, Files, Commits, Review और PR टैब हर run का असली diff दिखाते हैं, पहले uncommitted काम, फिर वह जो उसकी branch पर commit हुआ।
नीचे दाईं ओर Merge station। पूरे हो चुके runs चुनें, और यहीं आप उन्हें टेस्ट करते हैं और उन्हें एक साथ merge करने का preview देखते हैं।

उपयोग का उदाहरण: एक repo पर तीन एजेंट्स के साथ एक tech lead

Dana एक छोटी वेब टीम लीड करती हैं और checkout sprint को तीन एजेंट runs में बाँटती हैं: कार्ट टोटल में राउंडिंग ठीक करना, checkout में डिस्काउंट कोड जोड़ना, और price formatter के लिए tests लिखना। हर run New run से एक लाइन के टास्क और उसके लिए चुने गए एजेंट के साथ शुरू हुआ, इसलिए हर एक की अपनी branch और फ़ोल्डर है और काम करते समय कोई भी दूसरों की फ़ाइलों से नहीं टकरा सकता।

जब बैनर कहता है कि वे असहमत हैं, तो वह तीनों runs पर टिक करती हैं और Review together पर क्लिक करती हैं। Merge पैनल पर लिखा आता है "3 runs · conflicts not checked yet · 3 not yet tested", जो हरी झंडी के बजाय एक ईमानदार "अभी हमें नहीं पता" है। उसके नीचे src/cart.js को contested टैग किया गया है, और हर branch के hunks आमने-सामने दिखाए गए हैं: राउंडिंग फ़िक्स और डिस्काउंट कोड, दोनों ने total() को दोबारा लिखा था।

फिर वह हर run पर test दबाती हैं। tests उसी run के अपने worktree के अंदर चलते हैं, इसलिए उनका अपना checkout कभी छुआ नहीं जाता। डिफ़ॉल्ट रूप से "Tests must pass before a branch can merge", और यह नियम Settings में बदला जा सकता है। तीनों पास हो जाते हैं, लेकिन अलग-अलग पास होना साथ में पास होने जैसा नहीं है, इसलिए वह Preview combined merge दबाती हैं। ऐप पहले branches को एक अस्थायी कॉपी में merge करता है और नतीजा बताता है: दो साफ़ merge होती हैं, एक में conflict है।

वह दोनों साफ़ branches को अपनी current branch में merge करती हैं। सिर्फ़ उसी पल उनकी branch बदलती है। डिस्काउंट कोड वाली branch वैसी ही रहती है, ताकि एजेंट राउंडिंग फ़िक्स के ऊपर अपना बदलाव दोबारा कर सके। अगर वह पूरी branches के बजाय हर कोशिश का सबसे अच्छा हिस्सा चाहतीं, तो Combine into a branch से अलग-अलग hunks टिक करके उनसे नई branch बना सकती थीं।

लंबे दिनों में काम आने वाली एक और बात: अगर कोई run काम कर रहा हो और ऐप बंद हो जाए, तो वह run "running" के बजाय Interrupted के रूप में वापस आता है, इस नोट के साथ कि उसकी branch सुरक्षित रखी गई है।

उपयोग का उदाहरण: assistant के साथ refactor करता एक अकेला डेवलपर

Kenji अकेले एक शॉप का front end संभालते हैं। आज सुबह उन्हें formatPrice बदलना है, और उन्हें पक्का नहीं पता कि इसे कौन-कौन call करता है। वह साइडबार से प्रोजेक्ट फ़ोल्डर IDE में खोलते हैं। एडिटर का लेआउट वही जाना-पहचाना है: बाईं ओर Explorer और Source Control, बीच में टैब, नीचे Terminal, Output, Problems और Tests, और दाईं ओर Assistant, जहाँ वह synced चैट या डिवाइस पर ही रहने वाली local चैट शुरू कर सकते हैं।

वह formatPrice पर राइट-क्लिक करके Show Code Graph चुनते हैं। पैनल में Callers और Calls की लिस्ट आती है। भरा हुआ डॉट मतलब call सीधे कोड से पढ़ी गई; खाली डॉट मतलब उसका अनुमान लगाया गया, इसलिए उसे हाथ से एक बार देख लेना चाहिए। Impact of change callers के भी callers तक जाता है और इस उदाहरण में दिखाता है "15 symbols · 14 files · 3 tests"। किसी लाइन पर क्लिक करने से उसी जगह पहुँच जाते हैं, और Send to chat पूरा graph context के रूप में assistant को दे देता है।

बाद में assistant उनके लिए एक config फ़ाइल एडिट करता है। Source Control में फ़ाइल modified दिखती है, और खोलने पर एक छोटा रोबोट निशान और status line बताते हैं कि इसे आख़िरी बार AI ने लिखा था, मॉडल और उसके बताए कारण के साथ। Review उस write से ठीक पहले सेव की गई कॉपी के मुक़ाबले side-by-side diff खोलता है, इसलिए उन्हें सिर्फ़ वही बदलाव दिखता है। यहाँ दिखता है कि timeout 30 सेकंड से घटाकर 3 कर दिया गया, ठीक उस comment के नीचे जिसमें लिखा है कि बड़े uploads में 20 सेकंड या उससे ज़्यादा लगते हैं। वह commit से पहले ही इसे पकड़ लेते हैं।

अगर कोई एजेंट किसी ऐसी फ़ाइल में लिखता है जिसमें उनके बिना सेव किए बदलाव अभी बाकी हैं, तो एडिटर बताता है कि एडिट करते समय फ़ाइल डिस्क पर बदल गई, और चुपचाप किसी एक को चुनने के बजाय Keep mine या Use the disk version का विकल्प देता है।

उपयोग का उदाहरण: एक सपोर्ट इंजीनियर जिसे कोड बदलना नहीं, समझना है

Priya कस्टमर सपोर्ट में काम करती हैं और उनसे अक्सर पूछा जाता है कि प्रोडक्ट का कोई हिस्सा कैसे काम करता है। वह कोड पढ़ लेती हैं, लेकिन किसी और के repository में grep करते हुए भटकना नहीं चाहतीं। Wiki में वह Open a folder (या https या git@ URL के साथ Clone a public repository) इस्तेमाल करती हैं, और ऐप उनकी मशीन पर प्रोजेक्ट का स्ट्रक्चर पढ़ता है।

प्रोजेक्ट में कुछ भी लिखने से पहले Wiki पूछता है। एक dialog ठीक-ठीक बताता है कि repo के अंदर कौन-सा फ़ोल्डर बनाया जाएगा, और अगर वह Not now पर क्लिक करती हैं, तो कुछ नहीं लिखा जाता। हाँ कहने के बाद वह Generate pages या किसी एक विषय के लिए Write a page इस्तेमाल करती हैं। Settings तय करती हैं कि हर पेज कितने source code से लिखा जाए (Depth: Quick, Standard या Deep) और कितने दावों की जाँच हो (Verification: Off, Sample या Full, जिसमें Full से ख़र्च लगभग दोगुना हो जाता है)। पेज बनने से पहले ख़र्च दिखा दिया जाता है।

हर पेज path:line का हवाला देता है, और किसी हवाले पर क्लिक करने से वह लाइन IDE में खुल जाती है। एक महीने बाद रेल में एक पेज पर निशान लगा होता है, क्योंकि "a file this page cites has changed since it was written", यानी उस पर भरोसा करने से पहले उसे दोबारा बनाना चाहिए। किसी छोटे, एक बार के सवाल के लिए वह पेजों के बगल वाली चैट इस्तेमाल करती हैं, जिसके जवाब भी उसी प्रोजेक्ट से path:line का हवाला देते हैं, और जहाँ वह सीधे शब्दों में नया पेज भी माँग सकती हैं, जैसे "write a page about the retry policy"। पेज ख़ुद repository में markdown फ़ाइलें हैं, इसलिए टीम उन्हें कोड वाले pull requests में ही रिव्यू कर सकती है।

Code, IDE और Wiki काम एक-दूसरे को कहाँ सौंपते हैं

ये तीनों स्क्रीन एक-दूसरे को और ऐप के बाकी हिस्सों को काम आगे बढ़ाती हैं। Wiki का कोई हवाला IDE को उसी लाइन पर खोलता है, और उल्टी दिशा के लिए IDE में Wiki for this folder बटन है। IDE का Assistant और Wiki पेजों के बगल वाली चैट Maestro पर बने हैं, वही assistant जिसे आप osFoundry में बाकी जगह इस्तेमाल करते हैं, इसलिए वहाँ सवाल पूछना किसी भी Maestro चैट की तरह ही काम करता है। किसी codebase में सटीक शब्दों के बजाय मतलब से खोजने के लिए Indexes एक लोकल search index बनाता है जिसे Maestro इस्तेमाल कर सकता है। और जब कोई Code run आपके लैपटॉप से बाहर जाने के लिए तैयार हो, तो Open PR उसकी branch के लिए pull request खोल देता है।

प्रोडक्ट पेजों पर दोनों के interactive demo हैं: Code और IDE।

लोग सबसे पहले क्या पूछते हैं

क्या मुझे डेस्कटॉप ऐप चाहिए?
हाँ। Code, IDE और Wiki लोकल फ़ोल्डरों, Git worktrees, एक shell और language servers पर काम करते हैं, इसलिए ये osFoundry डेस्कटॉप ऐप में चलते हैं।

क्या कोई एजेंट कभी अपने-आप मेरी branch में merge कर देगा?
नहीं। runs अपनी-अपनी branches पर, अपने-अपने फ़ोल्डरों में काम करते हैं। आपकी current branch तभी बदलती है जब आप merge दबाते हैं, और डिफ़ॉल्ट रूप से सिर्फ़ उन्हीं branches के लिए जिनके tests पास हुए हों।

क्या Wiki, Notion जैसी टीम wiki है?
नहीं। यह code repository से documentation लिखता है, फ़ाइल और लाइन का हवाला देते हुए, और जब वह कोड बदलता है तो पेजों पर निशान लगाता है। यह codebase docs के लिए है, जैसे architecture overview या onboarding notes।

जिस branch में conflict हो, उसका क्या होता है?
वह जहाँ है वहीं रहती है। आप अभी साफ़ branches merge कर सकते हैं और एजेंट को conflict वाली branch उनके ऊपर दोबारा करने दे सकते हैं, या Combine into a branch से अलग-अलग hunks चुन सकते हैं।

डेस्कटॉप ऐप osfoundry.io/hi/download पर मुफ़्त में डाउनलोड किया जा सकता है।

Qué hace Maestro de osFoundry, un chat de IA que muestra cada paso que dio

tauchiii — Fri, 06 Nov 2026 15:38:09 +0000

Son las 4:40 de un jueves y Priya le ha pedido a un asistente de IA que añada un botón "Eliminar cuenta" a la página de ajustes de su app. La respuesta dice "Hecho, 4 archivos modificados". Antes de publicarlo quiere saber qué cuatro archivos son, qué leyó el asistente para decidirlo y si se acercó al código de facturación. Una ventana de chat normal solo le da el párrafo final.

Maestro en un párrafo

Maestro es el espacio de trabajo de IA con todas las herramientas dentro de la app de escritorio de osFoundry. Escribes la petición como en cualquier chat, pero la respuesta llega con su recorrido: cada archivo que listó, cada búsqueda que lanzó, cada archivo que leyó o editó y cada comando de terminal, cada uno en su propia fila con una duración que puedes desplegar. Puede trabajar dentro de una carpeta de tu ordenador, proponer cambios en lugar de escribirlos sin avisar y detenerse a enseñarte un plan antes de tocar nada. Lo encuentras como Maestro en la barra lateral. Si has usado ChatGPT o Claude en el navegador, imagina la misma conversación con el registro de actividad del agente y unos frenos al lado.

Un vistazo a la pantalla

Pestañas de superficie en la parte superior. Maestro, Model chat, Multi chat, Research, Wiki y Code conviven en esta misma pantalla. Maestro es la pestaña con el conjunto completo de herramientas.
Pestañas de detalle encima de la conversación: Chat, Sources, Files, Changelog, Tools, Pipeline y Logs. Son vistas distintas de la misma ejecución. Sources guarda en qué se basó la respuesta, Changelog lista los archivos que escribió este chat y Logs muestra los pasos y, en Costs, cuánto costó cada petición.
Las filas del proceso en la transcripción. Aquí Maestro listó src/ (38 archivos), hizo grep de deleteUser, encontró 0 coincidencias y luego leyó account.ts y users.ts. Si haces clic en una fila, se abre y muestra la entrada y la salida exactas de esa llamada a la herramienta.
La barra de control sobre el cuadro de mensaje: el interruptor del sandbox, Plan OFF/ON, Tools y Goal. Debajo del cuadro están los selectores de carpeta, proyecto, repo, Router y modelo.
El panel de vista previa a la derecha, donde un archivo, un diff o una página web se abre junto a la conversación en lugar de sustituirla (Open File / App / Page, Browse Files, Browser).

Tres formas de usarlo

Una desarrolladora que quiere ver el plan antes del cambio

El caso de Priya del principio. El cambio toca cuentas y sesiones, así que prefiere leer el plan a revisar un diff sorpresa.

Hace clic en Plan en la barra de control para que ponga Plan ON.
Escribe "Add a Delete account button to settings" y lo envía.
Maestro lee seis archivos y no cambia ninguno. Con el modo plan activado, la propia app de escritorio rechaza cualquier herramienta que escriba un archivo o ejecute un comando, así que "solo lectura" no es una petición amable dentro del prompt.
Llega una tarjeta Plan marcada como "Awaiting approval", con los botones Approve y Cancel.

El plan del ejemplo nombra cuatro archivos, indica que src/billing/ queda intacto porque Stripe guarda sus propios registros y termina con "Nothing has been changed yet." El modo plan se desactiva solo cuando llega el plan. Priya pulsa Approve y solo entonces Maestro edita los cuatro archivos y ejecuta los tests (npm test -- account, 3 passed), todo visible como filas EDIT y TERMINAL. Si el plan no le hubiera gustado, Cancel habría dejado la carpeta exactamente como estaba.

Con qué se queda: un cambio que aprobó de antemano y una transcripción que muestra dónde miró el agente y qué ejecutó.

Un compañero nuevo orientándose en el código

Dan entró en el equipo el lunes. Necesita saber dónde está el bloqueo de login, pero en el código nadie lo llama "lockout", así que una búsqueda de texto no devuelve nada.

En Indexes añade una vez la carpeta del proyecto para que se pueda buscar por significado.
En un chat de Maestro sobre esa carpeta pregunta dónde bloquea la app a la gente tras varios logins fallidos.
Sigue las filas del proceso: una búsqueda en la carpeta que devuelve 2 resultados y luego un READ de throttle.ts.

La respuesta apunta a src/auth/throttle.ts (líneas 1–46) y src/routes/session.ts (líneas 22–61), y explica que el código nunca dice "lock out": tras cinco intentos fallidos fija un tiempo de espera de 15 minutos y devuelve 429 antes de comprobar la contraseña. Como la respuesta incluye rutas de archivo y las filas muestran lo que se leyó, Dan puede abrir esas mismas líneas en el panel de vista previa y comprobarlo él mismo en lugar de fiarse de un resumen. En este caso nada escribe en disco, así que puede dejar Approval Mode en su valor por defecto.

Con qué se queda: los dos archivos que importan, el motivo por el que la búsqueda por palabra clave no los encontró y un chat al que puede volver desde la lista de chats.

Una persona de marketing editando textos en un repo ajeno

Sammy escribe los textos de la página de lanzamiento, pero la página es un archivo React del repo de ingeniería. Quiere que el texto nuevo siga la guía de tono de docs/ y no quiere que se haga commit de nada sin revisarlo.

Abre el menú Approval Mode del compositor y elige Permission & Approve, que pregunta antes de cada llamada a herramienta. Las otras opciones son Auto Accept (la predeterminada, las herramientas se ejecutan al momento), Plan First (planificar antes de ejecutar) y Bypass (ninguna aprobación, ni siquiera para push o envío de formularios).
Activa el sandbox para que las escrituras se preparen en una rama en lugar de caer en la carpeta de trabajo.
Le pide a Maestro un borrador de la página de lanzamiento coherente con la documentación. Lee docs/tone.md, busca en el código y propone un cambio en src/Launch.tsx.
El diff se abre en el panel de vista previa. Lo acepta y luego usa Export to branch para que alguien de ingeniería lo revise como cualquier otro cambio.

Con qué se queda: un texto que cita la guía de tono que siguió (la pestaña Sources la conserva), un diff revisado y una rama en lugar de una sorpresa en main.

Dónde encaja Maestro frente a Model chat, Chat y Multi chat

Maestro comparte pantalla con hermanos más sencillos, y elegir el adecuado ahorra tiempo y dinero.

Model chat es una pestaña de la misma pantalla que envía cada turno a un único modelo que eliges. Es una conversación de solo lectura: sin carpeta, sin herramientas que actúen, sin aprobaciones. Ideal para una pregunta rápida.
Chat tiene su propio sitio en la barra lateral. También responde con un modelo que eliges para toda la conversación, pero conserva las capacidades sobre archivos, así que puede proponer un cambio que aceptas (Accept) o rechazas (Reject), registrado en Changelog. Úsalo cuando quieras que un modelo concreto haga el trabajo, sin un router que decida por ti.
Multi chat hace la misma pregunta a varios modelos a la vez. En Compare lees las respuestas en paralelo; en Council los modelos responden, puntúan a ciegas las respuestas de los demás y uno escribe una síntesis.

Desde Maestro el trabajo suele pasar a otras partes de la app. Research convierte una pregunta en un informe con citas, Code ejecuta un agente de programación en su propia rama, Indexes hace que una carpeta se pueda buscar por significado (como en el caso de Dan) y Version → Merge Station es donde se fusionan los cambios del sandbox. Si un turno sale mal, escribir /rewind en el chat restaura los archivos que cambió ese turno. Para profundizar, la página de orquestación de Maestro recorre las pestañas de detalle y la página del modo plan explica el flujo de aprobación.

Las primeras preguntas que hace la gente

¿El modo plan es solo una instrucción en el prompt?
No. Mientras Plan está en ON, cualquier herramienta que no esté en la lista de solo lectura se rechaza cuando la app la despacha, así que el agente puede leer, buscar y navegar, pero no puede editar ni ejecutar comandos hasta que apruebes el plan.

¿Qué diferencia hay entre el interruptor Plan y Plan First en Approval Mode?
Plan es un interruptor puntual para la siguiente petición: investigar, presentar un plan, esperar. Approval Mode es la regla fija del chat para las llamadas a herramientas, de Auto Accept a Bypass. Plan First es uno de sus cuatro ajustes.

Hay muchas filas de proceso. ¿Puedo ocultarlas?
Sí. El ajuste Process Detail alterna entre Full y Compact. Solo cambia cómo se muestran los pasos, no cómo se ejecuta el turno.

¿Qué modelo usa Maestro?
Por defecto el Router elige un modelo en cada turno, y las filas del proceso muestran cuál se ejecutó. Puedes cambiar el modo de modelo (en la nube, local o autoalojado) desde el compositor, o usar Chat cuando quieras fijar un único modelo para toda la conversación.

Puedes descargar la app de escritorio en osfoundry.io/es/download.

Comment Code, l'IDE et Wiki d'osFoundry gardent le travail de plusieurs agents IA en parallèle facile à relire

tauchiii — Fri, 06 Nov 2026 15:30:55 +0000

Il est 16 h et trois agents de code travaillent sur le même dépôt depuis le déjeuner. L'un a corrigé l'arrondi du total du panier, un autre a ajouté un code promo, le troisième a écrit des tests. Tous les trois annoncent "done". Avant que quoi que ce soit ne touche main, vous voulez savoir deux choses : est-ce que deux d'entre eux ont réécrit la même fonction, et est-ce que les trois changements passent encore les tests une fois réunis ?

Trois écrans pour une même base de code

osFoundry est une application de bureau qui réunit chat, agents, fichiers et outils dans une seule fenêtre, et pour le code elle propose trois écrans liés. Code, c'est là où vous confiez des tâches à plusieurs agents en même temps : chaque exécution a sa propre branche Git et son propre dossier de travail (un worktree), et vous relisez, testez et prévisualisez la fusion avant de décider quoi que ce soit. Rien ne fusionne tout seul. L'IDE est un éditeur de code pour un dossier local, avec un explorateur, le contrôle de version, un terminal, des panneaux Problems et Tests, et une colonne d'assistant qui voit le fichier ouvert. Wiki lit un dépôt sur votre machine et rédige des pages de documentation qui citent path:line, puis signale une page quand le code qu'elle cite change. Code et Wiki sont des onglets à côté de Maestro, Model chat, Multi chat et Research ; l'IDE a sa propre entrée dans la barre latérale. Si vous connaissez VS Code avec son panneau Git, l'IDE vous semblera familier. Code ressemble plutôt à une boîte de réception de pull requests, sauf que les auteurs sont vos agents et que les branches n'ont jamais quitté votre portable.

Un tour de l'onglet Code

Ce que vous voyez sur cet écran (les exécutions sont des données d'exemple) :

Le bandeau en haut de la colonne. "3 agents finished · they disagree on 1 file" nomme le fichier, ici src/cart.js, avant même que vous ouvriez un diff. Le bouton Review together lance une relecture commune.
La colonne des exécutions. Elles sont regroupées selon ce qu'elles attendent de vous : Ready to review, Needs attention et un History replié. Chaque ligne affiche la tâche, les lignes ajoutées et supprimées, la durée de travail et la branche.
La conversation au centre. Cliquez sur une exécution pour lire ce qu'on a demandé à l'agent et ce qu'il a dit pendant son travail.
Le panneau de droite. Les onglets Changes, Files, Commits, Review et PR montrent le vrai diff de chaque exécution : d'abord le travail non commité, puis ce qui a été commité sur sa branche.
La Merge station en bas à droite. Vous sélectionnez des exécutions terminées et c'est ici que vous les testez et prévisualisez leur fusion commune.

Cas d'usage : une tech lead avec trois agents sur un dépôt

Dana dirige une petite équipe web et découpe un sprint de checkout en trois exécutions d'agents : corriger l'arrondi des totaux du panier, ajouter un code promo au checkout, écrire des tests pour le formateur de prix. Chaque exécution a été lancée depuis New run avec une tâche d'une ligne et un agent choisi pour elle. Chacune a donc sa propre branche et son propre dossier, et aucune ne peut marcher sur les fichiers des autres pendant le travail.

Quand le bandeau indique qu'elles divergent, elle coche les trois exécutions et clique sur Review together. Le panneau Merge affiche "3 runs · conflicts not checked yet · 3 not yet tested", un "on ne sait pas encore" honnête plutôt qu'un feu vert. En dessous, src/cart.js est marqué contested, et les hunks de chaque branche sont listés côte à côte : la correction d'arrondi et le code promo ont tous deux réécrit total().

Elle lance ensuite test sur chaque exécution. Les tests tournent dans le worktree de l'exécution concernée, donc son propre checkout n'est jamais touché. Par défaut, "Tests must pass before a branch can merge", et cette règle se modifie dans Settings. Les trois passent, mais passer séparément n'est pas la même chose que passer ensemble, alors elle clique sur Preview combined merge. L'application fusionne d'abord les branches dans une copie jetable et rend son verdict : deux fusionnent proprement, une est en conflit.

Elle fusionne les deux branches propres dans sa branche courante. C'est seulement à ce moment que sa branche change. La branche du code promo reste en place, pour que l'agent refasse son changement par-dessus la correction d'arrondi. Si elle avait voulu le meilleur de chaque tentative plutôt que des branches entières, Combine into a branch lui permet de cocher des hunks un par un et d'en faire une nouvelle branche.

Un dernier détail qui compte les longues journées : si l'application s'arrête pendant qu'une exécution travaille, celle-ci revient en Interrupted, pas en "running", avec la mention que sa branche est conservée.

Cas d'usage : un développeur solo qui refactorise avec un assistant

Kenji maintient seul le front-end d'une boutique. Ce matin, il doit modifier formatPrice et ne sait pas trop qui l'appelle. Il ouvre le dossier du projet dans l'IDE depuis la barre latérale. La disposition de l'éditeur est classique : Explorer et Source Control à gauche, les onglets au centre, Terminal, Output, Problems et Tests en bas, et l'Assistant à droite, où il peut lancer un chat synchronisé ou un chat local qui reste sur l'appareil.

Il fait un clic droit sur formatPrice et choisit Show Code Graph. Le panneau liste Callers et Calls. Un point plein signifie que l'appel a été lu directement dans le code ; un point creux signifie qu'il a été déduit, et celui-là mérite une vérification manuelle. Impact of change remonte aussi les appelants des appelants et affiche, dans cet exemple, "15 symbols · 14 files · 3 tests". Un clic sur une ligne amène à cet endroit, et Send to chat transmet tout le graphe à l'assistant comme contexte.

Plus tard, l'assistant modifie pour lui un fichier de configuration. Dans Source Control, le fichier apparaît comme modifié, et quand il l'ouvre, une petite icône de robot et la barre d'état indiquent qu'il a été écrit en dernier par l'IA, avec le modèle et la raison donnée. Review ouvre un diff côte à côte avec la copie enregistrée juste avant cette écriture, il ne voit donc que ce changement. Ici, on voit un timeout réduit de 30 secondes à 3, juste sous un commentaire qui précise que les gros uploads prennent 20 secondes ou plus. Il le repère avant de commiter.

Si un agent écrit dans un fichier alors qu'il y a encore des modifications non enregistrées, l'éditeur signale que le fichier a changé sur le disque pendant l'édition et propose Keep mine ou Use the disk version, au lieu de choisir en silence.

Cas d'usage : une ingénieure support qui doit comprendre le code, pas le modifier

Priya travaille au support client et on lui demande souvent comment se comporte telle partie du produit. Elle sait lire du code, mais n'a pas envie de faire des grep dans un dépôt qui n'est pas le sien. Dans Wiki, elle utilise Open a folder (ou Clone a public repository avec une URL https ou git@), et l'application lit la structure du projet sur sa machine.

Avant d'écrire quoi que ce soit dans le projet, Wiki demande. Une boîte de dialogue indique le dossier exact qu'il va créer dans le dépôt, et si elle clique sur Not now, rien n'est écrit. Une fois qu'elle accepte, elle utilise Generate pages, ou Write a page pour un sujet précis. Les réglages déterminent à partir de combien de code source chaque page est rédigée (Depth : Quick, Standard ou Deep) et combien d'affirmations sont vérifiées (Verification : Off, Sample ou Full, Full doublant à peu près la facture). Le coût est affiché avant la génération d'une page.

Chaque page cite path:line, et un clic sur une citation ouvre cette ligne dans l'IDE. Un mois plus tard, une page de la colonne est signalée parce que "a file this page cites has changed since it was written", ce qui lui dit de la régénérer avant de s'y fier. Pour une question ponctuelle, elle utilise le chat à côté des pages, dont les réponses citent elles aussi path:line dans ce projet, et où elle peut aussi demander une nouvelle page en langage courant, par exemple "write a page about the retry policy". Les pages elles-mêmes sont des fichiers markdown dans le dépôt, donc l'équipe peut les relire dans les mêmes pull requests que le code.

Où Code, l'IDE et Wiki se passent le relais

Ces trois écrans se transmettent le travail entre eux et avec le reste de l'application. Une citation Wiki ouvre l'IDE à la ligne citée, et l'IDE a un bouton Wiki for this folder pour le chemin inverse. L'Assistant de l'IDE et le chat à côté des pages Wiki reposent sur Maestro, le même assistant que partout ailleurs dans osFoundry, donc poser une question là fonctionne comme dans n'importe quel chat Maestro. Pour chercher dans une base de code par le sens plutôt que par mots exacts, Indexes construit un index de recherche local que Maestro peut utiliser. Et quand une exécution Code est prête à quitter votre portable, Open PR ouvre une pull request pour sa branche.

Les pages produit proposent des démos interactives de chacun : Code et l'IDE.

Les premières questions qu'on nous pose

Ai-je besoin de l'application de bureau ?
Oui. Code, l'IDE et Wiki travaillent sur des dossiers locaux, des worktrees Git, un shell et des serveurs de langage, ils tournent donc dans l'application de bureau osFoundry.

Un agent peut-il fusionner dans ma branche tout seul ?
Non. Les exécutions travaillent sur leurs propres branches, dans leurs propres dossiers. Votre branche courante ne change que lorsque vous cliquez sur merge, et par défaut uniquement pour les branches dont les tests sont passés.

Wiki est-il un wiki d'équipe comme Notion ?
Non. Il rédige de la documentation à partir d'un dépôt de code, en citant fichier et ligne, et signale les pages quand ce code change. Il sert à la documentation du code, comme une vue d'ensemble de l'architecture ou des notes d'onboarding.

Que devient une branche en conflit ?
Elle reste où elle est. Vous pouvez fusionner les branches propres tout de suite et laisser l'agent refaire celle en conflit par-dessus, ou choisir des hunks un par un avec Combine into a branch.

L'application de bureau se télécharge gratuitement sur osfoundry.io/fr/download.

Was ist osFoundry und wie ist der KI-Arbeitsbereich für den Desktop aufgebaut?

tauchiii — Fri, 06 Nov 2026 15:23:31 +0000

Montag, 9:40 Uhr, vier Browser-Tabs sind offen: ein Chatbot für Fragen, ein zweiter, weil du dem ersten nicht ganz traust, ein Editor mit Coding-Agent und eine Notiz-App mit der Recherche von letzter Woche. Jedes Tool kennt einen Teil deiner Arbeit, keines kennt den Rest. Bis zur Mittagspause hast du denselben Absatz Kontext in drei verschiedene Fenster kopiert.

Eine App statt fünf Tabs

osFoundry ist ein KI-Arbeitsbereich für den Desktop: eine App, in der du mit KI-Modellen chattest, Arbeit an Agenten und Agenten-Teams abgibst, Notizen und durchsuchbares Wissen ablegst, offene Modelle auf deinem eigenen Rechner laufen lässt und kleine Apps für dein Team baust. Die Modelle können aus drei Quellen kommen: von deinem eigenen Rechner, von Cloud-Anbietern über deine eigenen API-Keys oder von gemieteten Cloud-GPUs. Die App ist in Kategorien gegliedert, und jede Kategorie enthält mehrere Screens. In Chat sprichst du mit Modellen (Maestro, Multi chat, Branchspace und weitere). In Workstation erledigen Agenten längere Aufgaben (Code, Agent, Agent team, Loop, Terminal). Knowledge enthält deine Texte und das, was sich die KI merkt. Local Model dient zum Finden, Installieren und Testen offener Modelle. Custom App ist für interne Tools gedacht, Discover für Webrecherche und News. Wer VS Code kennt: Am ehesten vergleichbar ist ein Editor mit Activity Bar, in der jedes Icon ein anderes Tool öffnet, nur dass die Tools hier KI-Oberflächen sind und sich dieselben Projekte, dasselbe Gedächtnis und dieselben Modelle teilen.

Wie ein typischer Screen aussieht

Mit der Kategorie Chat fangen die meisten an, deshalb eignet sie sich gut, um zu verstehen, wie die Screens von osFoundry aufgebaut sind. Das hier ist Multi chat im Council-Modus mit Beispieldaten: Drei Modelle haben dieselbe Frage bekommen und danach die Antworten der jeweils anderen bewertet.

Die Tab-Leiste oben (Maestro, Model chat, Multi chat, Research, Wiki, Code) wechselt zwischen den Oberflächen des Chat-Bereichs: dem vollständigen Maestro-Agenten, einem einfachen Frage-Antwort-Chat mit Quellenangaben, mehreren Modellen gleichzeitig, Deep Research, Code-Dokumentation und Coding-Agenten.
Der Schalter Compare / Council legt fest, wie die Modelle zusammenarbeiten. Compare stellt die Antworten nebeneinander, damit du selbst urteilst. Bei Council antworten sie getrennt, bewerten sich gegenseitig blind, und am Ende wird eine Synthese geschrieben.
Jede Spalte ist ein Modell mit Anbieter-Tag: hier Anthropic, Ollama (lokal) und OpenAI. Cloud- und lokale Modelle lassen sich auf demselben Screen mischen.
Die rechte Leiste zeigt die Phasen des Laufs (Answers, Ranking, Synthesis) und das Peer-review-Raster. So siehst du, wer was wie bewertet hat, statt nur eine fertige Antwort zu lesen.
Der Run-Button zeigt schon vor dem Klick, wie viele Modellaufrufe der Lauf braucht (hier "Run · 7 calls"). Schaltest du das Peer-Ranking ab, sinkt die Zahl.

Viele Screens in osFoundry folgen diesem Muster: links eine Liste, in der Mitte die eigentliche Arbeit und rechts ein Inspector, der zeigt, wie ein Ergebnis zustande kam.

Die erste Woche eines Solo-Entwicklers

Ken betreibt allein einen kleinen Webshop. Er will eine KI, die seine Codebasis kennt, und einen Teil der Arbeit möchte er gern auf seinem Laptop behalten.

Am Montag öffnet er Local Model und dann Explore. Der Screen liest zuerst seinen Rechner aus (in diesem Beispiel 16 GB Arbeitsspeicher) und versieht jedes offene Modell mit einem Badge: Fits, Tight oder Too big. Er installiert ein Modell mit grünem Badge und stellt ihm in Playground ein paar Fragen. Playground schickt denselben Prompt an zwei Modelle nebeneinander und zeigt, wie schnell jedes mit der Antwort angefangen hat.

Am Dienstag muss er eine Funktion zur Preisformatierung ändern und weiß nicht genau, was alles davon abhängt. Er öffnet das Projekt in der IDE, klickt mit rechts auf die Funktion und wählt Show Code Graph.

Das Panel listet alle Aufrufer auf, markiert, welche Verbindungen direkt aus dem Code gelesen und welche nur abgeleitet wurden, und fasst unter Impact of change zusammen, wie viele Symbole, Dateien und Tests betroffen sein könnten. Ein Klick auf einen Aufrufer springt zur passenden Zeile, und mit Send to chat holt er den Graphen in eine Unterhaltung mit Maestro.

Ab Donnerstag gibt er kleine Aufgaben an Coding-Agenten ab. Im ADE-Screen bekommt jede Aufgabe ihren eigenen Worktree, und der Tab Changes zeigt den Diff. Er klickt in die Leiste neben einer Zeile, mit der er nicht einverstanden ist, tippt eine Notiz und schickt alle noch nicht gesendeten Notizen auf einmal an den Agenten. Am Ende der Woche hat er ein lokales Modell, dem er bei schnellen Fragen vertraut, und die Gewohnheit, vor jedem Refactoring die Auswirkungen zu prüfen.

Die erste Woche einer Teamleiterin

Aiko leitet vier Leute und liefert alle zwei Wochen ein Release aus. Ihr Problem ist nicht das Code-Schreiben, sondern der Überblick darüber, woran alle gerade arbeiten, egal ob Mensch oder Agent.

Sie beginnt in Message, dem Team-Chat. Channels und DMs funktionieren wie in Slack, mit einem Unterschied: KI-Agenten sind Mitglieder der Channels. Jemand erwähnt einen Agenten mit @ in #release, und seine Antwort samt Lauf landet wieder im Channel, wo alle sie sehen.

Als Nächstes richtet sie in Workstation ein Agent team ein. Ein Leader-Agent koordiniert spezialisierte Mitglieder, und der Screen trennt Team mail, Handoffs, Sub-agents und Proposals in eigene Tabs. So kann sie nachvollziehen, wer was an wen übergeben hat. Für die Prüfungen, die bei jedem Release anfallen, macht sie aus dem Team einen Loop: einen Trigger (zum Beispiel werktags morgens), Grenzen für Runden und Wiederholungen sowie Erfolgskriterien. Der Loop läuft in Runden, bis die Kriterien erfüllt sind, und führt Buch darüber, welche in welcher Runde bestanden wurden.

Arbeiten mehrere Agenten am selben Repository, nutzt sie Code. Jeder Agent bekommt seinen eigenen Branch und Worktree, und nichts wird von selbst gemergt. Sie wählt zwei fertige Läufe aus, klickt auf Preview combined merge und sieht, welche Dateien kollidieren, bevor irgendetwas den Main-Branch berührt.

Für Reviews auf Zeilenebene nutzt sie dieselben Notizen wie Ken: eine an den Code angeheftete Notiz, die mit Datei, Zeile und Code an den Agenten geht. Am Ende der Woche hat sie einen Channel, in dem die Arbeit der Agenten auftaucht, einen Release-Check, der von allein läuft, und einen Review-Schritt, der vor dem Merge stattfindet und nicht erst danach.

Die erste Woche einer Researcherin und Autorin

Lena schreibt lange Berichte über Arbeitsplatzrichtlinien. Sie braucht Quellen, die sie überprüfen kann, und hat schon schlechte Erfahrungen mit selbstsicheren KI-Antworten gemacht.

Bei Fragen, bei denen die Antwort eines einzelnen Modells nicht reicht, nutzt sie Multi chat im Council-Modus, also den Screen aus der Tour oben. Wenn zwei Reviewer eine Antwort schlecht bewerten, weiß sie, dass sie genauer nachgraben muss.

Für größere Fragen öffnet sie Agents, klickt auf New session und wählt das fertige Deep Research Team. Der Leader zerlegt die Frage in Teile und gibt jeden an ein Mitglied, etwa einen Data Researcher oder einen Search Specialist.

Ein separater Reviewer prüft jeden Schritt, bevor er bei ihr ankommt, und ein Schritt ohne Quelle wird zurückgeschickt und neu ausgeführt. Die finale Antwort kommt als Tabelle mit einer Quelle in jeder Zeile, dazu eine kurze Notiz, wo sich die Quellen widersprechen und was nicht abgedeckt wurde (Beispieldaten im Screenshot).

Das eigentliche Schreiben passiert in Knowledge. In Paper markiert sie einen Satz in ihrem Entwurf und hängt einen Denkraum daran, mit Tabs wie Academic search, Browser oder einer Maestro-Session, die nur diese Passage bespricht. Begleitdateien und Kommentare liegen in einer Note. In Discover speichert sie Suchen in Browser und folgt Keyword-Channels in News, sodass die Lektüre für einen Bericht auch beim nächsten noch da ist.

Wie die Bereiche sich die Arbeit übergeben

Die Kategorien sind keine getrennten Produkte, sie reichen die Arbeit weiter. Local Model ist die Schicht darunter: Ein Modell, das du über Explore installierst, taucht in den Modellauswahlen von Maestro, Multi chat und den Agenten-Sessions auf.

Knowledge versorgt Chat: Memory zeigt, was Maestro über deine Arbeit weiß, und unter Indexed Folders legst du fest, welche Ordner Agenten durchsuchen dürfen. Agenten-Sessions, Agent-team-Läufe und Loops berichten in Message-Channels. Workstation (der Screen mit diesem Namen) öffnet einen Channel, eine Notiz, eine Datei und eine Agenten-Session nebeneinander in einem Layout. Soll etwas, das du mit Agenten gebaut hast, ein Tool fürs Team werden, wandert es nach Custom App, wo ein Room die Apps eines Teams neben dessen eigenem Maestro-Chat bündelt. Keys und Anbieter für all das liegen in Configuration. Die Plattformübersicht listet jeden Screen auf, falls du die ganze Karte sehen willst.

Fragen aus der ersten Woche

Muss ich das alles nutzen?
Nein. Die meisten fangen mit einem Bereich an, meist Maestro in Chat oder Explore in Local Model, und nehmen weitere dazu, wenn eine Aufgabe es verlangt. Die Kategorien teilen sich Projekte und Gedächtnis, also musst du nichts, was du am Anfang machst, später neu aufsetzen.

Verlassen meine Daten meinen Rechner?
Nicht, wenn du lokale Modelle nutzt; die laufen auf deinem Gerät. Cloud-Modelle, die du über deine eigenen API-Keys anbindest, sehen, was du ihnen schickst, und diese Nutzung rechnet der Anbieter ab. Die Seite zu Local-first erklärt, wie beides getrennt ist.

Ist das nur für Entwickler?
Nein. Code, IDE und Terminal sind Entwickler-Tools, aber Message, Paper, Note, Research, Multi chat und Discover sind genauso für Autorinnen, Analysten und Teamleiter gebaut.

Was kostet es?
Die Desktop-App ist kostenlos zum Download, und für lokale Modelle fallen keine Nutzungsgebühren bei osFoundry an. Du bekommst sie auf der Download-Seite.

Come Memory e Knowledge Base di osFoundry conservano ciò che la tua IA ha imparato e glielo restituiscono come contesto

tauchiii — Fri, 06 Nov 2026 15:10:04 +0000

Sono le 9:40 di un lunedì e apri una nuova chat con il tuo agente di coding. Giovedì scorso ha passato un'ora a capire che il servizio di fatturazione gira su Postgres 16 e che la suite di test completa richiede quattro minuti. Oggi ti rifà entrambe le domande. Rispondi, lui annuisce, e in un angolo della testa inizi a tenere una lista di cose che dovrai ripetere venerdì.

Cosa sono le funzioni Knowledge

osFoundry ha un gruppo di funzioni pensate proprio per fermare questa ripetizione: Note, Knowledge Base, Memory con i suoi Memory Groups, Lessons, Chat History e Indexed Folders. In parole semplici, sono i posti in cui viene salvato quello che scrivi tu e quello che scoprono i tuoi agenti, più i controlli che decidono quale parte viene restituita all'IA come contesto alla prossima esecuzione. Nell'app desktop non sono un unico grande pannello ma schermate separate: Notes per i tuoi documenti, Knowledge Base per gli articoli condivisi, Memory (con il sottotitolo "What Maestro knows & reads") per tutto ciò che ricordano l'assistente e i tuoi agenti, e Indexes per le cartelle che scegli di rendere ricercabili. Se hai mai usato una wiki accanto a un assistente di chat, immagina che la wiki e il quaderno dell'assistente stiano nella stessa app, con un interruttore su ogni scaffale che dice se l'IA può leggerlo.

Un primo sguardo alla schermata Memory

Questa è Memory con Agents selezionato, con dati di esempio. Cosa si vede:

La barra a sinistra: Memory Groups, Memory Browser, Chat History, Agents, Sessions e Lessons. Sotto "Indexing" ci sono Chunking Station, Indexed Folders ed Embeddings, che aprono la schermata Indexes.
L'elenco degli agenti ("Agents with memory"): ogni agente con il numero di memorie e lezioni che porta con sé, qui @code-agent e @research-agent.
"What it knows": fatti salvati da step completati e turni di chat, riletti nelle esecuzioni successive dell'agente. Nell'esempio: la versione di Postgres, il comando dei test e il fatto che preferisci pull request piccole.
"What it learned": regole scritte solo dopo che un revisore ha respinto il lavoro o uno step è fallito.
"Move what it learned": Save to a file e Import from a file, perché memorie e lezioni restano sul dispositivo e non seguono da sole un agente su un'altra macchina. In alto, Settings e Turn off controllano la memoria degli agenti nel suo insieme.

Tre modi in cui le persone lo usano

Una sviluppatrice solitaria che continua a rispiegare il codice

Maya mantiene da sola un'API di medie dimensioni e usa un agente per la maggior parte delle modifiche. Il suo problema non è che l'agente sia scarso, ma che ogni sessione riparte da zero.

Apre Indexes, resta sulla scheda Sources e clicca Add folder per scegliere il repository. La scansione è gratuita e mostra cosa verrà indicizzato prima che venga generato qualsiasi embedding. Sceglie "Index locally", che calcola gli embedding sulla sua macchina con un modello locale, e attiva "Re-index automatically when files change" così l'indice resta al passo con le sue modifiche.

Ora, quando chiede a Maestro a parole sue dove si trova la logica di blocco degli account, l'agente può lanciare una ricerca nella cartella che combina parole chiave e significato, e torna con percorsi dei file e intervalli di righe invece che con un'ipotesi. Nel giro di qualche giorno, i fatti che l'agente raccoglie strada facendo compaiono in Memory → Agents → "What it knows", così la conversazione successiva parte già da lì.

Cosa ottiene: un agente capace di cercare nel suo codice per significato e un elenco breve e leggibile di ciò che ricorda del suo progetto, da controllare quando vuole.

Un team lead che vuole che l'agente smetta di ripetere un errore

Daniel guida un piccolo team in cui gli agenti preparano le modifiche e una fase di revisione le controlla. Due settimane fa un agente ha "sistemato" un test che falliva cancellandolo. Il revisore ha respinto quell'esecuzione e osFoundry ha scritto una lezione a partire dal rifiuto.

Apre Memory → Lessons. Le lezioni di tutti gli agenti sono elencate insieme all'esecuzione da cui provengono, formulate come "When … : …". Tiene quelle utili, come "When a test fails after your change: fix the code. Never edit, skip or delete the test to make it pass." Una riga ha il badge "from outside content": viene da una pagina di prezzi letta dall'agente di ricerca e dice di consigliare sempre un piano specifico. L'agente tratta lezioni del genere come suggerimenti, non come istruzioni, ma Daniel non la vuole proprio lì, quindi clicca Retire.

Con "Show retired" attivo, la riga ritirata resta visibile in grigio con un pulsante Restore, quindi non si perde nulla se cambia idea. Cosa ottiene: agenti che leggono le lezioni attive più recenti prima di ogni esecuzione e un registro consultabile di ogni regola che hanno imparato e della sua provenienza.

Una consulente che vuole che l'IA usi il materiale del cliente giusto

Aiko è una consulente freelance, non un'ingegnera. I file dei suoi clienti sono qualche centinaio di documenti Word e PDF in cartelle sul suo portatile, e vuole che l'assistente risponda basandosi su di essi senza confondere i clienti.

In Notes clicca Import… e sceglie "Import folder…" (il menu lo descrive come pensato per un vault di Obsidian o un export estratto; "Import .zip archive…" copre un export di Notion o un backup di Bear). L'app desktop converte i file in note offline e mantiene la struttura delle cartelle nel File Tree.

Per le pagine che riutilizza con tutti i clienti, come la checklist di onboarding e le condizioni standard, crea una Knowledge Base: New Knowledge Base, poi New article, oppure Import content da PDF, DOCX, Markdown, un export di Notion o Confluence, o il crawl di un sito web. Dopo aver modificato un articolo preme Generate chunks, così l'IA recupera l'ultima versione; la sola modifica non lo reindicizza.

Poi va in Memory → Memory Groups e crea un gruppo per ogni cliente. Nell'impostazione "When can this be recalled?" di ciascun gruppo lascia il cliente attuale su Normal (cercato quando il progetto lo consente) e imposta un incarico concluso su Never, che lo toglie del tutto dalla ricerca pur mantenendolo salvato. Una memoria che deve comparire in ogni risposta, il suo listino tariffe, riceve "Pin (always in context)". Cosa ottiene: risposte tratte dal materiale del cliente giusto e un interruttore esplicito per spegnere tutto il resto.

Come si collega al resto dell'app

Le funzioni Knowledge servono soprattutto ad alimentare altre parti di osFoundry, più che a vivere da sole. Maestro, l'assistente integrato nell'app, è il lettore principale: cerca nei memory groups quando una domanda lo richiede e usa gli Indexed Folders tramite la sua ricerca nelle cartelle. Gli agenti delle schermate Agent team e Single agent portano la propria memoria e le proprie lezioni in ogni conversazione a cui partecipano. La scheda Health della schermata Indexes contiene Chunking Station ed Embeddings, dove vedi quali note, articoli e file sono cambiati, falliti o mai suddivisi in chunk. Chat History conserva le trascrizioni scritte quando le conversazioni lunghe vengono compattate, così puoi tornare alle parole originali dietro un riassunto. E per le conversazioni avvenute in altre app di IA sul tuo computer, External agents elenca quelle sessioni accanto a quelle di osFoundry. Le pagine dedicate agli agent memory groups e alle knowledge bases approfondiscono ciascuna funzione.

Domande che fa chi inizia

L'assistente legge automaticamente tutte le mie note?
No. L'assistente non legge le memorie automaticamente: le cerca quando una domanda ne ha bisogno, e l'impostazione di ogni memory group (Always on, Normal o Never) decide fin dove può arrivare quella ricerca. Le cartelle vengono indicizzate solo dopo averle aggiunte nella schermata Indexes.

Dove viene salvato tutto questo?
Memorie e lezioni degli agenti restano sul tuo dispositivo, e le lezioni non vengono mai caricate online. I memory groups possono essere personali o di tutto il workspace, e stare su questo dispositivo o nel cloud; la schermata Memory mostra i conteggi per entrambi.

Che differenza c'è tra Chat History, Sessions e Lessons?
Chat History è la trascrizione di ciò che è stato detto, Sessions mostra cosa hanno tenuto gli agenti da ogni step e Lessons sono le regole che gli agenti seguiranno la volta successiva. Le prime due sono prove che puoi verificare; le Lessons sono indicazioni che puoi ritirare o ripristinare.

Mi serve l'app desktop?
Per le parti che leggono il tuo computer, sì: indicizzazione delle cartelle, importazione di file in Notes, Chat History e le viste della memoria degli agenti funzionano nell'app desktop, che puoi scaricare dalla pagina di download.

Comment créer et héberger de petites apps internes avec Custom App d'osFoundry

tauchiii — Fri, 06 Nov 2026 14:58:58 +0000

On est jeudi, deux heures avant une mise en production, et Dari est la seule personne à savoir quelles étapes du cutover sont déjà faites. La checklist est dans un onglet de tableur, le runbook sur un drive partagé et la discussion dans un fil de chat que personne ne retrouve. Ce dont l'équipe a vraiment besoin, c'est d'une toute petite app avec quatre cases à cocher et deux responsables, juste à côté des fichiers. L'écrire est facile. L'héberger, lui donner une base de données, protéger ses clés et lui obtenir une URL, c'est là que ça bloque d'habitude.

Ce qu'est la catégorie Custom App

osFoundry regroupe tout ce qu'il faut pour créer et faire tourner vos propres petites apps dans une seule catégorie de la barre latérale de l'app de bureau, appelée CUSTOM APP. Elle compte cinq écrans. Room est l'espace partagé où les apps vivent sous forme d'onglets. App Code est le dépôt qui se trouve derrière une app. Deployed Apps est la liste, à l'échelle du workspace, de ce qui est en ligne. Snippets rassemble les mini-apps qui n'ont jamais eu besoin de dépôt. Domains gère les adresses web depuis lesquelles ces apps sont servies. Si vous connaissez Notion, imaginez une page dont les onglets sont des apps qui fonctionnent plutôt que des documents, avec une petite couche d'hébergement façon Vercel en dessous : chaque app a sa propre base de données, ses secrets, ses tâches planifiées et un sous-domaine, comme décrit sur la page de la fonctionnalité apps internes.

Un coup d'œil à l'écran de construction

Le moyen le plus rapide de voir comment une app démarre, c'est la vue de construction de l'app de bureau. Cette capture vient du constructeur Websites (projet d'exemple « Hearth Bakery »), qui utilise la même boucle « décrire puis construire » que propose une Room avec sa zone « Describe the app you want ».

Pages, à gauche : les parties de l'app qui existent déjà, avec Add page en bas.
L'aperçu, au centre : ce que vous êtes en train de construire, avec les tailles bureau, tablette et téléphone au-dessus. Le libellé « On this computer » indique que rien n'a encore été publié.
La zone de description : vous écrivez ce que fait l'app, à qui elle s'adresse et l'impression qu'elle doit donner, puis vous cliquez sur Build my site. Maestro, l'assistant IA de l'app, écrit les fichiers.
Le panneau Maestro, à droite : la conversation qui construit et modifie l'app. Use a folder lui donne votre propre matériel au lieu de le laisser deviner.
Publish needs credits, en haut : la construction et l'aperçu se font sur votre ordinateur ; l'hébergement est l'étape qui consomme des crédits du workspace.

Dans une Room, c'est la même idée avec une autre disposition : une barre d'onglets d'apps en haut, l'app sélectionnée au centre et un panneau de droite avec deux onglets, Maestro et Details.

Cas d'usage 1 : une équipe de release garde sa checklist là où se fait le travail

Qui : une release manager et trois coéquipiers qui préparent un lancement.

La situation : les étapes du cutover, le runbook et le suivi de release sont répartis sur trois outils, et le jour J, personne ne fait confiance au tableur.

Ce qu'ils font dans osFoundry :

Créer une room appelée « Launch Ops » avec New Room, puis y ajouter le suivi de release et les fichiers du lancement sous forme d'onglets.
Cliquer sur le bouton + de la barre d'onglets. Le sélecteur New Tab liste les apps installées et un catalogue (Incident log, Retro board, On-call rota, Changelog builder), filtrable par All, Forked ou Snippets.
Dans « Describe the app you want », cliquer plutôt sur Build a snippet et demander une checklist de cutover avec un responsable par étape. Un snippet est une mini-app exécutable composée de quelques fichiers. Il n'a ni dépôt, ni version, ni déploiement, et il tourne directement dans l'onglet.
Continuer à échanger avec Maestro dans le panneau de droite pendant que la checklist est ouverte, et utiliser l'onglet Details pour voir ce qu'est la room et ce qui s'y est passé.

Résultat : une seule room où la checklist (dans la démo : Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) se trouve à côté du runbook et du suivi. Plus tard, l'écran Snippets liste tous les snippets de toutes les rooms. De là, on peut en exporter un en JSON avec Export pour un autre workspace, ou le transformer en vrai dépôt avec Promote quand il devient trop grand pour son onglet.

Cas d'usage 2 : un développeur donne un vrai backend à un outil interne

Qui : un développeur seul qui construit un outil d'inscriptions et de commandes pour l'équipe support.

La situation : la première version tournait sur un portable avec un fichier SQLite. Maintenant trois équipes en ont besoin, elle doit appeler une API de paiement et un nettoyage nocturne doit s'exécuter sans que personne ait à penser à cliquer sur un bouton.

Ce qu'il fait dans osFoundry :

Tant que l'app tourne encore en local, ouvrir le projet dans l'IDE et cliquer sur l'onglet Database. Il trouve les fichiers .db et .sqlite de l'app et ouvre une table en lecture seule, 200 lignes par page (données d'exemple ci-dessus), pour voir ce que l'app a réellement enregistré avant de déplacer quoi que ce soit.
Déplacer l'app dans une room partagée. La boîte de dialogue Move to cloud copie l'app dans une Cloud room pour que tous ses membres puissent l'utiliser, et indique quelles tables ont été copiées et lesquelles sont restées sur l'appareil. L'app et ses données restent aussi sur cet appareil.
Ouvrir les paramètres de l'onglet de l'app. Sous Secrets, App Runtime Secrets liste les clés que déclare l'app ; Add a custom secret en enregistre une nouvelle et Rotate remplace une valeur. L'app affiche alors « Secrets updated. Redeploy to apply changes. »
Déclarer le nettoyage sous container.cron dans le manifeste de l'app, puis ouvrir Scheduled jobs et cliquer sur Sync from manifest. Chaque tâche peut être mise en pause, reprise ou lancée une fois avec Run now.

Résultat : une app avec sa propre base Postgres. Sur osFoundry, chaque Room App en a une, avec pgvector et TimescaleDB installés, et la chaîne de connexion arrive sous forme de secret à l'exécution (Postgres par app). L'explorateur de base de données propose un éditeur de lignes avec filtres et une vue SQL limitée à SELECT, et Database snapshots offre New snapshot, Restore et un lien de téléchargement. Les modifications de code se font dans App Code, où le développeur peut travailler sur une version comme version/2.4 sans toucher à main, vérifier le Manifest (point d'entrée, visibilité, connecteurs requis) et suivre l'arbre Versions avant de livrer.

Cas d'usage 3 : une commerçante publie une page et garde un œil dessus

Qui : quelqu'un qui tient une petite boulangerie et ne code pas.

La situation : elle veut un site simple avec la carte et les horaires, sur sa propre adresse, et elle veut savoir combien coûte sa mise en ligne.

Ce qu'elle fait dans osFoundry :

Ouvrir Websites, cliquer sur New Website, décrire la boulangerie et cliquer sur Build my site. La première version (ci-dessus, exemple) utilise des textes provisoires, et Maestro le dit clairement.
Cliquer sur Use a folder, choisir le dossier avec la vraie carte et les photos, puis demander des changements avec des mots simples, comme « Make the headline bigger. »
Quand le résultat convient, publier. L'hébergement consomme des crédits du workspace. Who can open it propose Workspace members only, Anyone with the link ou la connexion propre à l'app ; un site de boulangerie public utilise Anyone with the link.
Dans Domains, enregistrer un domaine ou en ajouter un qu'elle possède déjà, puis modifier ses enregistrements DNS. Events montre qui a modifié quel enregistrement, et Settings regroupe le renouvellement, la confidentialité et le code de transfert.

Résultat : un site avec ses propres textes et photos, servi sur son propre domaine. Deployed Apps répond ensuite aux questions qu'une commerçante se pose vraiment. Apps montre chaque app et où elle est servie, Activity ce qui a changé, Usage le coût de build et de stockage par app, et Previews liste les versions d'aperçu encore actives.

Comment ça s'articule avec le reste d'osFoundry

Custom App fonctionne rarement seul. Maestro est l'assistant du panneau de droite de chaque Room et des vues de construction ; il écrit et modifie le code avec vous. L'IDE fournit l'onglet Database, le contrôle de version et l'éditeur pour les apps qui commencent comme un dossier sur votre ordinateur. Websites est un chemin plus rapide quand l'« app » est en réalité un site public. Les Snippets ne sont reliés à App Code que par Promote, si bien qu'un outil jetable peut devenir un dépôt maintenu sans être réécrit. Les tâches planifiées à l'intérieur d'une app sont prises en charge par les cron jobs d'app, décrits sur la page plateforme consacrée à app cron.

Les questions des nouveaux venus

Une Room, c'est un salon de discussion ?
Non. Le cœur d'une Room, ce sont ses onglets d'apps. Le chat Maestro se trouve dans le panneau compagnon à droite, à côté des Details de la room.

Quand faut-il créer un snippet plutôt qu'une app ?
Quand l'outil tient en quelques fichiers et n'a besoin de tourner que dans une seule room, comme un formateur de dates ou une vérification de webhook. Enregistrer un snippet n'installe rien et ne déploie rien. Si plus tard il lui faut des versions, des secrets ou une base de données, transformez-le en dépôt avec Promote.

Deux apps peuvent-elles partager une base de données ?
Chaque app a son propre Postgres. Le partage passe par des autorisations explicites : l'onglet Database de la room affiche Incoming Requests, Active Grants et Outgoing Access, et chaque demande peut être approuvée ou refusée.

Est-ce que l'essayer coûte quelque chose ?
Construire et prévisualiser sur votre ordinateur ne demande aucun crédit. Publier, déployer et enregistrer des domaines consomme des crédits du workspace. Vous pouvez télécharger l'app de bureau sur osfoundry.io/fr/download.

Cosa fa Local Model di osFoundry, dalla scelta di un modello open alla sua messa a punto sul tuo computer

tauchiii — Fri, 06 Nov 2026 14:48:21 +0000

Sono le 16:40 di un giovedì e in una finestra c'è aperta la bozza di un contratto. Vorresti che un'IA sistemasse la formulazione, ma il documento non può uscire dal tuo portatile, e non sai quale dei cento modelli open su Hugging Face riuscirebbe anche solo a caricarsi con 16 GB di memoria. E non hai voglia di passare la serata in un terminale per scoprirlo.

Un unico gruppo nella sidebar per tutto quello che fai con i modelli open

Local Model è la parte di osFoundry che si occupa dei modelli open-weight in esecuzione su hardware che controlli tu. Nella sidebar dell'app desktop è una categoria a sé, divisa in tre sottosezioni: Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks) e Measure (Eval, Benchmarks, Safety). Se hai usato Ollama o LM Studio, la parte Run ti sembrerà familiare: trovi un modello, lo scarichi, ci parli. La differenza è che lo stesso gruppo ti permette anche di ridurre un modello, fare fine-tuning sui tuoi esempi e testarlo con le tue domande, così l'intera vita di un modello resta in un'unica app. L'inferenza sul dispositivo usa un server llama.cpp incluso, quindi non serve installare nient'altro. Questa guida copre le nove schermate più usate: Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval e Benchmarks.

Un primo sguardo a Explore

Quasi tutti iniziano da Explore, e il suo layout mostra come ragiona l'intera categoria: prima la tua macchina, poi i modelli.

Il pannello Filters a sinistra raggruppa i task di Hugging Face (Text Generation, Summarization, Translation, Embeddings, più i gruppi Multimodal, Vision e Audio) e ha una casella di ricerca.
Il banner in alto legge la tua macchina prima di mostrare qualsiasi cosa. Nell'esempio sopra indica 16 GB di memoria unificata, circa 12 GB utilizzabili per un modello, circa 9 GB liberi in quel momento, e che le stime presuppongono Q4_K_M e un contesto di 4K.
Ogni scheda ha un badge di compatibilità: verde Fits, ambra Tight, rosso Too big, ciascuno con una stima della memoria. Non viene nascosto nulla; i modelli che ci stanno sono semplicemente elencati per primi.
I pulsanti Providers e My Registry in alto a destra portano ai fornitori di API cloud e ai modelli che hai già.
Cliccando su una scheda si apre il dettaglio, dove Install Locally scarica una versione del modello, di solito un GGUF quantizzato che corrisponde al badge.

Tre persone, tre modi di usarlo

Una sviluppatrice indipendente con un solo portatile

Maya sviluppa progetti personali su un MacBook da 16 GB. Vuole un modello locale per scrivere messaggi di commit e brevi note, soprattutto per lavorare offline in treno.

Apre Explore, filtra per Text Generation e salta tutto ciò che ha il badge rosso. Due candidati sono verdi, quindi li installa entrambi con Install Locally. Poi apre Playground, scrive un prompt e aggiunge i due modelli come pannelli. Playground invia lo stesso prompt a due-quattro modelli contemporaneamente e mostra le risposte affiancate, con il tempo al primo token e il numero di parole sotto ogni pannello.

Più tardi trova un modello che le piace, ma che esiste solo come file F16 a piena precisione. Sono circa 15 GB, troppi per il suo portatile. In Quantize lo seleziona sotto "The model to shrink", sceglie Q4_K_M, il livello che l'app consiglia alla maggior parte delle persone, e avvia. Il llama-quantize incluso riscrive il file sulla sua macchina; non viene caricato niente.

Nell'esempio sopra il risultato è di 4.58 GiB, 3.3 volte più piccolo dell'originale. Prima di fidarsi, clicca Measure quality, che confronta il nuovo file con l'originale e compila le colonne "same top token" e KLD medio nella tabella Compare, poi Measure speed per i token al secondo. Un clic su Try it in Playground lo rimette accanto agli altri due. Chiude la serata con un modello che ci sta, numeri che mostrano quanto è costata la riduzione e nessuna cronologia del terminale.

Un piccolo team con un desktop potente

Un'agenzia di quattro persone ha in ufficio un desktop con molta memoria e diversi portatili leggeri. I modelli grandi stanno solo sul desktop, ma tutti vogliono usarli.

Sul desktop qualcuno apre Servers, seleziona This Mac e va nella scheda Access. Spunta "Allow access from other devices on the local network (LAN)" e attiva Remote Access. Il pannello elenca allora tutti i modelli locali che la macchina servirà. Sotto Device keys clicca New key, le dà il nome del portatile di un collega e clicca Create key; ogni chiave si può revocare singolarmente, e una chiave solo per l'inferenza può eseguire modelli ma non accedere alle sessioni degli agenti.

Su ogni portatile il collega apre Servers, clicca Add Server, inserisce l'indirizzo del desktop, incolla la chiave e usa Test Connection. Appena si collega, i modelli del desktop compaiono nel selettore dei modelli del portatile come qualsiasi altro modello. L'app stessa avverte che questo traffico è HTTP in chiaro, quindi è pensato per reti di cui ti fidi, come la LAN dell'ufficio.

Poi qualcuno apre Benchmarks, clicca New Benchmark, sceglie il modello e lascia la suite Quick. L'esecuzione registra token al secondo, tempo al primo token e latenza, così il team capisce se il modello condiviso è abbastanza veloce da usare durante le chiamate o solo per i batch notturni. Se sembra lento, Servers ha anche una scheda Config dove si può impostare un piccolo modello bozza sotto Speculative Decoding, poi Restart now, e rilanciare il benchmark per confrontare.

Il team si ritrova con una macchina che fa il lavoro pesante, una chiave per portatile che si può ritirare senza disturbare gli altri e una risposta misurata a "è abbastanza veloce?".

Un responsabile operativo che non scrive codice

Ken gestisce l'assistenza clienti di un piccolo negozio online. Ha due domande: quale modello legge correttamente i totali delle fatture, e un modello può imparare a rispondere con il tono del negozio?

Per la prima va in Eval e clicca Custom Benchmark. Gli dà un nome, incolla dieci fatture con il totale che si aspetta per ciascuna, lascia Exact Match e clicca Create Benchmark. Poi New Eval Run: spunta due modelli sul suo computer, spunta il suo benchmark e clicca Start Evaluation. Le domande vanno a ciascun modello sulla sua macchina.

In questo esempio un modello ottiene 90 e l'altro 70, e la colonna Diff mostra il distacco di 20 punti. È un risultato sui suoi documenti, non la classifica di qualcun altro.

Per la questione del tono raccoglie qualche centinaio di vecchi messaggi dei clienti con le risposte che il team ha davvero inviato, una coppia per riga. In Datasets può importare quel file, oppure cercare dati pubblici nella scheda Hub, e usare "Use for Training" per passarlo. In Training clicca New Job e segue i quattro passaggi: Base Model, Dataset, Config e Review. Sotto Training Target sceglie Local (This Device), che la schermata descrive come esecuzione sulla GPU del dispositivo e gratuita, con LoRA come metodo.

Dopo Start Training, il job mostra la loss mentre gira. Quando finisce, l'adapter addestrato compare in My Models accanto al modello base da cui deriva, e "Chat with your model" sull'esecuzione completata lo prepara per il runtime sul dispositivo, così può fargli una domanda in Playground. Alla fine ha un modello piccolo e privato e un benchmark da rilanciare ogni volta che valuta un nuovo modello.

Dove Local Model passa il testimone

La categoria non vive da sola. I modelli che installi o colleghi compaiono nella stessa lista di modelli usata dalla chat, quindi un modello locale può rispondere a una normale conversazione o essere confrontato in Playground con un modello cloud che hai aggiunto in Providers. Da Explore, "Use in Notebook" apre un notebook JupyterLab già configurato per quel modello, in locale o su un'istanza ospitata. Quando un modello ha bisogno di una vera GPU invece del tuo portatile, Deployments e Cloud GPU subentrano e lo mettono su un endpoint gestito. Prima che un modello arrivi ai clienti, Safety esegue suite di test red team su un modello deployato. La pagina sull'inferenza locale approfondisce il motore sul dispositivo, e la pagina sul fine-tuning LoRA copre la parte di addestramento.

Le prime domande che si fanno

Mi serve una GPU o un PC da gaming?
No. Un portatile recente basta per modelli piccoli e medi; i badge di Explore ti dicono cosa può reggere la tua macchina prima di scaricare. Un desktop più potente o un server remoto allargano semplicemente l'elenco.

Viene inviato qualcosa al cloud?
L'inferenza locale, Quantize e l'addestramento locale girano sulla tua macchina. L'addestramento su Cloud GPU, gli endpoint Cloud GPU e Providers sono le parti che usano servizi esterni, e le schermate lo indicano, per esempio con "Managed cloud GPU · needs credits" nella finestra di addestramento.

Che differenza c'è tra Eval e Benchmarks?
Eval valuta la qualità delle risposte rispetto a domande definite da te. Benchmarks misura velocità e memoria: token al secondo, tempo al primo token e latenza.

Dove trovo l'app?
Local Model funziona nell'app desktop, che puoi scaricare da osfoundry.io/it/download.

Apa itu osFoundry dan bagaimana ruang kerja AI desktop ini dibagi?

tauchiii — Fri, 06 Nov 2026 14:38:04 +0000

Senin pukul 9:40, ada empat tab browser yang terbuka: satu chatbot untuk bertanya, satu lagi karena kamu tidak sepenuhnya percaya yang pertama, satu editor dengan coding agent, dan satu aplikasi catatan berisi riset minggu lalu. Masing-masing tahu sebagian pekerjaanmu, tapi tidak ada yang tahu sisanya. Belum sampai jam makan siang, kamu sudah menyalin paragraf konteks yang sama ke tiga jendela berbeda.

Satu aplikasi, bukan lima tab

osFoundry adalah ruang kerja AI untuk desktop: satu aplikasi tempat kamu mengobrol dengan model AI, menyerahkan pekerjaan ke agent dan tim agent, menyimpan catatan dan pengetahuan yang bisa dicari, menjalankan model terbuka di komputer sendiri, dan membuat aplikasi kecil untuk dipakai tim. Modelnya bisa berasal dari tiga tempat: mesinmu sendiri, penyedia cloud lewat API key milikmu, atau GPU cloud sewaan. Aplikasinya dibagi menjadi beberapa kategori, dan setiap kategori berisi beberapa layar. Chat adalah tempat kamu berbicara dengan model (Maestro, Multi chat, Branchspace, dan lainnya). Workstation adalah tempat agent mengerjakan tugas yang lebih panjang (Code, Agent, Agent team, Loop, Terminal). Knowledge menyimpan tulisanmu dan apa yang diingat AI. Local Model dipakai untuk mencari, memasang, dan menguji model terbuka. Custom App untuk tool internal, dan Discover untuk riset web dan berita. Kalau kamu pernah memakai VS Code, perbandingan paling dekat adalah editor dengan activity bar yang setiap ikonnya membuka tool berbeda, bedanya di sini tool-tool itu adalah permukaan AI yang berbagi proyek, memori, dan model yang sama.

Seperti apa layar yang umum

Kebanyakan orang mulai dari kategori Chat, jadi ini tempat yang pas untuk memahami cara layar osFoundry disusun. Ini adalah Multi chat dalam mode Council, dengan data contoh: tiga model diberi pertanyaan yang sama, lalu saling menilai jawaban satu sama lain.

Deretan tab di atas (Maestro, Model chat, Multi chat, Research, Wiki, Code) berpindah di antara permukaan area Chat: agent Maestro lengkap, chat tanya-jawab sederhana dengan sumber yang dikutip, beberapa model sekaligus, riset mendalam, dokumentasi kode, dan coding agent.
Saklar Compare / Council menentukan cara model bekerja sama. Compare menampilkan jawaban berdampingan supaya kamu yang menilai. Council membuat mereka menjawab secara terpisah, saling memberi peringkat tanpa tahu siapa penulisnya, lalu menulis sintesis.
Setiap kolom adalah satu model dengan label penyedia: di sini Anthropic, Ollama (berjalan lokal), dan OpenAI. Kamu bisa mencampur model cloud dan lokal di layar yang sama.
Panel kanan menampilkan tahap-tahap proses (Answers, Ranking, Synthesis) dan tabel Peer review, jadi kamu bisa melihat siapa memberi skor apa, bukan hanya membaca jawaban akhirnya.
Tombol Run memberi tahu berapa panggilan model yang akan dilakukan sebelum kamu menekannya (di sini "Run · 7 calls"). Mematikan peer ranking akan menurunkan angka itu.

Banyak layar osFoundry mengikuti pola ini: daftar di kiri, pekerjaan di tengah, dan inspector di kanan yang menunjukkan bagaimana sebuah hasil didapat.

Minggu pertama seorang developer solo

Ken mengurus sebuah toko online kecil sendirian. Dia ingin AI yang paham codebase-nya, dan sebagian pekerjaan ingin dia simpan di laptopnya sendiri.

Hari Senin dia membuka Local Model, lalu Explore. Layar ini membaca spesifikasi mesinnya dulu (16 GB memori dalam contoh ini) lalu memberi badge pada setiap model terbuka: Fits, Tight, atau Too big. Dia memasang model dengan badge hijau dan mengajukan beberapa pertanyaan di Playground, yang menjalankan prompt yang sama di dua model berdampingan dan menunjukkan seberapa cepat masing-masing mulai menjawab.

Hari Selasa dia harus mengubah fungsi pemformat harga dan tidak yakin bagian mana saja yang bergantung padanya. Dia membuka proyek di IDE, klik kanan pada fungsi itu, dan memilih Show Code Graph.

Panel ini menampilkan semua pemanggil, menandai relasi mana yang dibaca langsung dari kode dan mana yang hanya disimpulkan, lalu merangkum Impact of change: berapa simbol, file, dan test yang bisa terdampak. Dia mengklik salah satu pemanggil untuk melompat ke baris itu, dan memakai Send to chat untuk membawa grafnya ke percakapan dengan Maestro.

Hari Kamis dia mulai menyerahkan tugas-tugas kecil ke coding agent. Di layar ADE, setiap tugas punya worktree sendiri, dan tab Changes menampilkan diff-nya. Dia mengklik gutter di samping baris yang tidak dia setujui, mengetik catatan, lalu mengirim semua catatan yang belum terkirim ke agent sekaligus. Dia menutup minggu itu dengan model lokal yang dia percaya untuk pertanyaan cepat dan kebiasaan mengecek dampak sebelum refactoring.

Minggu pertama seorang pemimpin tim kecil

Aiko memimpin empat orang dan merilis versi baru setiap dua minggu. Masalahnya bukan menulis kode, tapi tahu apa yang sedang dikerjakan semua orang, entah manusia atau agent.

Dia mulai dari Message, chat tim. Channel dan DM bekerja seperti di Slack, dengan satu perbedaan: agent AI adalah anggota channel. Seseorang me-mention agent dengan @ di #release, dan balasan serta run-nya muncul kembali di channel itu, tempat semua orang bisa melihatnya.

Berikutnya dia menyiapkan Agent team di Workstation. Agent pemimpin mengoordinasikan anggota spesialis, dan layarnya memisahkan Team mail, Handoffs, Sub-agents, dan Proposals ke tab masing-masing, jadi dia bisa mengaudit siapa menyerahkan apa ke siapa. Untuk pengecekan yang terjadi di setiap rilis, dia mengubah tim itu menjadi Loop: sebuah trigger (misalnya setiap pagi hari kerja), batas jumlah putaran dan percobaan ulang, serta kriteria keberhasilan. Loop berjalan per putaran sampai kriterianya terpenuhi dan mencatat kriteria mana yang lolos di setiap putaran.

Saat beberapa agent mengerjakan repository yang sama, dia memakai Code. Setiap agent punya branch dan worktree sendiri, dan tidak ada yang di-merge dengan sendirinya. Dia memilih dua run yang sudah selesai, menekan Preview combined merge, dan melihat file mana yang bentrok sebelum ada apa pun yang menyentuh branch utama.

Untuk review per baris, dia memakai catatan yang sama seperti Ken: catatan yang disematkan ke kode, dikirim ke agent lengkap dengan file, baris, dan kodenya. Di akhir minggu dia punya satu channel tempat pekerjaan agent muncul, pengecekan rilis yang berjalan sendiri, dan tahap review yang terjadi sebelum merge, bukan sesudahnya.

Minggu pertama seorang peneliti dan penulis

Lena menulis laporan panjang tentang kebijakan tempat kerja. Dia butuh sumber yang bisa dicek, dan dia sudah pernah kena batunya gara-gara jawaban AI yang terdengar sangat yakin.

Untuk pertanyaan yang tidak cukup dijawab oleh satu model, dia memakai Multi chat dalam mode Council, layar yang dibahas di atas. Kalau dua reviewer memberi skor rendah pada sebuah jawaban, dia tahu harus menggali lebih dalam.

Untuk pertanyaan yang lebih besar, dia membuka Agents, menekan New session, dan memilih Deep Research Team yang sudah siap pakai. Pemimpinnya memecah pertanyaan menjadi beberapa bagian dan memberikan masing-masing ke satu anggota, seperti Data Researcher dan Search Specialist.

Reviewer terpisah mengecek setiap langkah sebelum sampai ke dia, dan langkah tanpa sumber dikembalikan lalu dijalankan ulang. Jawaban akhirnya berupa tabel dengan sumber di setiap baris, ditambah catatan singkat tentang di mana sumber-sumbernya berbeda pendapat dan apa yang belum tercakup (data contoh di screenshot).

Proses menulisnya sendiri terjadi di Knowledge. Di Paper, dia menyorot satu kalimat di drafnya dan menempelkan ruang berpikir ke kalimat itu, dengan tab seperti Academic search, Browser, atau sesi Maestro yang hanya membahas bagian tersebut. File pendukung dan komentar disimpan di sebuah Note. Di Discover dia menyimpan pencarian di Browser dan mengikuti channel kata kunci di News, jadi bahan bacaan untuk satu laporan masih ada untuk laporan berikutnya.

Bagaimana area-area ini saling mengoper pekerjaan

Kategori-kategori ini bukan produk terpisah; mereka saling mengoper pekerjaan. Local Model adalah lapisan di bawahnya: model yang kamu pasang dari Explore akan muncul di pemilih model Maestro, Multi chat, dan sesi agent.

Knowledge memberi masukan ke Chat: Memory menunjukkan apa yang Maestro ketahui tentang pekerjaanmu, dan Indexed Folders memungkinkan kamu memilih folder mana yang boleh dicari agent. Sesi agent, run Agent team, dan Loop melapor ke channel di Message. Workstation (layar dengan nama itu) memungkinkan kamu membuka channel, catatan, file, dan sesi agent berdampingan dalam satu tata letak. Kalau sesuatu yang kamu bangun dengan agent perlu menjadi tool untuk tim, ia pindah ke Custom App, tempat sebuah Room menampung aplikasi milik tim di samping chat Maestro tim itu sendiri. Key dan penyedia untuk semua ini ada di Configuration. Ikhtisar platform mencantumkan setiap layar kalau kamu ingin peta lengkapnya.

Pertanyaan yang sering muncul di minggu pertama

Apakah saya harus memakai semuanya?
Tidak. Kebanyakan orang mulai dari satu area, biasanya Maestro di Chat atau Explore di Local Model, lalu menambah area lain saat ada tugas yang membutuhkannya. Kategori-kategori ini berbagi proyek dan memori, jadi apa pun yang kamu kerjakan di awal tidak perlu diulang nanti.

Apakah data saya keluar dari komputer?
Tidak, kalau kamu memakai model lokal; model itu berjalan di perangkatmu. Model cloud yang kamu hubungkan lewat API key milikmu bisa melihat apa yang kamu kirim, dan pemakaian itu ditagih oleh penyedianya. Halaman local-first menjelaskan bagaimana keduanya dipisahkan.

Apakah ini hanya untuk developer?
Tidak. Code, IDE, dan Terminal memang tool untuk developer, tapi Message, Paper, Note, Research, Multi chat, dan Discover juga dibuat untuk penulis, analis, dan pemimpin tim.

Berapa biayanya?
Aplikasi desktopnya gratis diunduh, dan menjalankan model lokal tidak dikenai biaya pemakaian dari osFoundry. Kamu bisa mendapatkannya di halaman unduhan.

osFoundry 的 Code、IDE 和 Wiki 怎麼讓多個 AI 代理同時寫的程式碼都能好好審查？

tauchiii — Fri, 06 Nov 2026 14:25:57 +0000

現在是下午 4 點，從午餐後就有三個 coding 代理在同一個 repository 上工作。一個修好了購物車總額的四捨五入，一個加了折扣碼，一個寫了測試。三個都回報 "done"。在任何東西碰到 main 之前，你會想知道兩件事：有沒有兩個代理改寫了同一個函式？三個改動合在一起還能不能通過測試？

一個 codebase，三個畫面

osFoundry 是一款桌面應用程式，把聊天、代理、檔案和工具放在同一個視窗裡；在程式碼方面，它提供三個彼此相關的畫面。Code 是你同時把任務交給多個代理的地方：每個 run 都有自己的 Git 分支和自己的工作資料夾（worktree），你可以先審查、測試、預覽合併結果，再決定要不要動手。不會有任何東西自己合併。IDE 是針對本機資料夾的程式碼編輯器，有檔案總管、版本控制、終端機、Problems 和 Tests 面板，還有一欄看得到你目前開啟檔案的助理。Wiki 會讀取你電腦上的 repository，寫出引用 path:line 的文件頁面，並在被引用的程式碼改變時標記該頁。Code 和 Wiki 是分頁，跟 Maestro、Model chat、Multi chat 和 Research 並排；IDE 則在側邊欄有自己的項目。如果你用過附 Git 面板的 VS Code，IDE 會讓你覺得很熟悉。Code 比較像是 pull request 收件匣，只是作者換成了你的代理，而且分支從來沒離開過你的筆電。

看一下 Code 分頁

這個畫面上可以看到的東西（run 是範例資料）：

側欄頂端的橫幅。"3 agents finished · they disagree on 1 file" 會在你打開任何一個 diff 之前，就先點出檔名，這裡是 src/cart.js。按下 Review together 按鈕就會開始共同審查。
run 側欄。run 會依照它們需要你做什麼來分組：Ready to review、Needs attention，以及收合起來的 History。每一列會顯示任務、新增和刪除的行數、代理工作了多久，以及它的分支。
中間的對話。點一個 run，就能看到當初交代代理做什麼，以及它在工作時說了什麼。
右側面板。Changes、Files、Commits、Review 和 PR 分頁會顯示每個 run 的實際 diff，先是尚未 commit 的工作，接著是已經 commit 到它分支上的內容。
右下角的 Merge station。選好已完成的 run，就在這裡測試它們，並預覽把它們合在一起的結果。

使用情境：一位 tech lead 在同一個 repo 上用三個代理

Dana 帶一個小型網頁團隊，把一個結帳功能的 sprint 拆成三個代理 run：修正購物車總額的四捨五入、在結帳流程加入折扣碼、替價格格式化函式寫測試。每個 run 都是從 New run 開始，配一行任務描述和挑好的代理，所以各自有自己的分支和資料夾，工作時誰也不會踩到別人的檔案。

橫幅說它們意見不一致時，她勾選三個 run，按下 Review together。Merge 面板顯示 "3 runs · conflicts not checked yet · 3 not yet tested"，這是一句誠實的「還不知道」，而不是綠燈。下方的 src/cart.js 被標成 contested，各分支的 hunk 並排列出：四捨五入的修正和折扣碼都改寫了 total()。

接著她對每個 run 按下 test。測試會在該 run 自己的 worktree 裡執行，所以她自己的 checkout 完全不會被動到。預設是 "Tests must pass before a branch can merge"，這條規則可以在 Settings 裡修改。三個都通過了，但各自通過不等於合起來也通過，所以她按下 Preview combined merge。應用程式會先在一份用完即丟的副本裡合併這些分支，再回報結果：兩個可以乾淨合併，一個有衝突。

她把兩個乾淨的分支合併進自己目前的分支。直到這一刻，她的分支才有變動。折扣碼的分支保留下來，讓代理可以在四捨五入修正的基礎上重做它的改動。如果她想要的是每次嘗試裡最好的部分，而不是整個分支，可以用 Combine into a branch 一個個勾選 hunk，用它們建立新的分支。

還有一個在漫長工作日裡很重要的細節：如果應用程式在 run 還在工作時停止，這個 run 回來時會顯示 Interrupted，而不是 "running"，並附註它的分支已保留。

使用情境：一個人開發、跟助理一起重構

Kenji 一個人維護一個網路商店的前端。今天早上他要改 formatPrice，但不太確定有哪些地方呼叫它。他從側邊欄在 IDE 裡開啟專案資料夾。編輯器的版面就是大家熟悉的那樣：左邊是 Explorer 和 Source Control，中間是分頁，下方是 Terminal、Output、Problems 和 Tests，右邊是 Assistant，他可以在那裡開一個同步的聊天，或是只留在裝置上的本機聊天。

他在 formatPrice 上按右鍵，選 Show Code Graph。面板會列出 Callers 和 Calls。實心圓點代表這個呼叫是直接從程式碼讀出來的；空心圓點代表是推測出來的，那一個就值得自己再看一眼。Impact of change 會一路追到呼叫者的呼叫者，在這個例子裡顯示 "15 symbols · 14 files · 3 tests"。點一列就會跳到那一行，Send to chat 則會把整張圖當作上下文交給助理。

稍後，助理幫他改了一個設定檔。在 Source Control 裡這個檔案顯示為已修改，打開時會有一個小機器人標記，狀態列也會顯示它最後是由 AI 寫入的，附上模型和它給的理由。Review 會開啟一個並排 diff，對照的是那次寫入前一刻存下的副本，所以他只會看到那一個改動。這裡顯示 timeout 從 30 秒被砍到 3 秒，正好就在一行註解下面，註解寫著大型上傳要 20 秒以上。他在 commit 之前就抓到了。

如果代理寫入一個他還有未儲存修改的檔案，編輯器會告訴他：你編輯期間這個檔案在磁碟上被改過了，並讓他選 Keep mine 或 Use the disk version，而不是默默替他挑一個。

使用情境：一位只需要看懂程式碼、不用修改的支援工程師

Priya 在客服部門工作，常被問到產品某個部分的行為是怎樣。她看得懂程式碼，但不想在一個不屬於她的 repository 裡到處 grep。她在 Wiki 裡用 Open a folder（或用 https 或 git@ 網址執行 Clone a public repository），應用程式就會在她的電腦上讀取專案結構。

在寫入任何東西到專案之前，Wiki 會先問。對話框會寫出它要在 repo 裡建立的確切資料夾，如果她按 Not now，就什麼都不會寫入。同意之後，她可以用 Generate pages，或針對單一主題用 Write a page。設定決定每一頁要根據多少原始碼來寫（Depth：Quick、Standard 或 Deep），以及要檢查多少論述（Verification：Off、Sample 或 Full，Full 大約會讓費用翻倍）。產生頁面之前就會先顯示費用。

每一頁都會引用 path:line，點一下引用就會在 IDE 裡開啟那一行。一個月後，側欄裡有一頁被標記，因為 "a file this page cites has changed since it was written"，提醒她要先重新產生再相信內容。遇到臨時的一次性問題，她會用頁面旁邊的聊天，回答同樣會引用該專案的 path:line，她也可以直接用白話要求新頁面，例如 "write a page about the retry policy"。這些頁面本身就是 repository 裡的 markdown 檔案，所以團隊可以在跟程式碼同一個 pull request 裡審查它們。

Code、IDE 和 Wiki 之間怎麼交棒

這三個畫面會互相傳遞工作，也會交給應用程式的其他部分。Wiki 的引用會在 IDE 裡開到被引用的那一行，反方向則可以用 IDE 裡的 Wiki for this folder 按鈕。IDE 的 Assistant 和 Wiki 頁面旁的聊天都是建立在 Maestro 上，也就是你在 osFoundry 其他地方用的同一個助理，所以在那裡提問的方式跟任何 Maestro 聊天都一樣。想要依照意思、而不是精確字詞來搜尋 codebase 的話，Indexes 會建立一個 Maestro 可以使用的本機搜尋索引。等 Code 裡的某個 run 準備好離開你的筆電時，Open PR 會替它的分支開一個 pull request。

產品頁面上有兩者的互動示範：Code 和 IDE。

大家最先問的問題

一定要用桌面應用程式嗎？
是的。Code、IDE 和 Wiki 都要用到本機資料夾、Git worktree、shell 和語言伺服器，所以它們在 osFoundry 桌面應用程式裡執行。

代理會不會自己合併到我的分支？
不會。run 都在各自的分支、各自的資料夾裡工作。只有在你按下 merge 時，你目前的分支才會改變，而且預設只限測試通過的分支。

Wiki 是像 Notion 那樣的團隊 wiki 嗎？
不是。它是從程式碼 repository 寫出文件，引用檔案和行號，並在那段程式碼改變時標記頁面。它是給 codebase 文件用的，例如架構總覽或新人上手筆記。

有衝突的分支會怎樣？
它會留在原地。你可以先合併乾淨的分支，再讓代理在它們之上重做有衝突的那個，或用 Combine into a branch 挑選個別的 hunk。

桌面應用程式可以在 osfoundry.io/zh/download 免費下載。

Cara kerja Local Model di osFoundry, dari memilih model open sampai melatihnya di komputer sendiri

tauchiii — Fri, 06 Nov 2026 14:15:45 +0000

Kamis pukul 16.40, draf kontrak terbuka di satu jendela. Kamu ingin AI merapikan kalimatnya, tapi dokumen itu tidak boleh keluar dari laptop, dan kamu tidak yakin model open mana dari ratusan model di Hugging Face yang bahkan bisa jalan dengan memori 16 GB. Menghabiskan malam di terminal untuk mencari tahu juga bukan pilihan yang menarik.

Satu grup di sidebar untuk semua urusan model open

Local Model adalah bagian dari osFoundry yang mengurus model open-weight yang berjalan di hardware milikmu sendiri. Di sidebar aplikasi desktop, ia punya kategori sendiri yang dibagi menjadi tiga subjudul: Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks), dan Measure (Eval, Benchmarks, Safety). Kalau pernah pakai Ollama atau LM Studio, bagian Run pasti terasa familier: cari model, unduh, lalu ajak ngobrol. Bedanya, grup yang sama juga bisa dipakai untuk mengecilkan model, melakukan fine-tuning dengan contohmu sendiri, dan mengujinya dengan pertanyaanmu sendiri, jadi seluruh siklus hidup model tetap ada di satu aplikasi. Inferensi di perangkat memakai server llama.cpp bawaan, jadi tidak perlu instalasi terpisah. Panduan ini membahas sembilan layar yang paling sering dipakai: Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval, dan Benchmarks.

Sekilas tentang Explore

Kebanyakan orang mulai dari Explore, dan tata letaknya menunjukkan cara berpikir seluruh kategori ini: mesinmu dulu, baru modelnya.

Panel Filters di kiri mengelompokkan tugas Hugging Face (Text Generation, Summarization, Translation, Embeddings, plus grup Multimodal, Vision, dan Audio) dan punya kotak pencarian.
Banner di atas membaca mesinmu sebelum menampilkan apa pun. Pada contoh di atas tertulis 16 GB unified memory, sekitar 12 GB bisa dipakai untuk model, sekitar 9 GB sedang kosong, dan perkiraannya mengasumsikan Q4_K_M dengan konteks 4K.
Setiap kartu model punya label kecocokan: hijau Fits, kuning Tight, merah Too big, masing-masing dengan perkiraan kebutuhan memori. Tidak ada yang disembunyikan; model yang muat hanya ditampilkan lebih dulu.
Tombol Providers dan My Registry di kanan atas mengarah ke penyedia API cloud dan ke model yang sudah kamu punya.
Klik sebuah kartu untuk membuka detailnya. Di sana, Install Locally mengunduh satu versi model, biasanya GGUF terkuantisasi yang sesuai dengan labelnya.

Tiga orang, tiga cara memakainya

Developer solo dengan satu laptop

Maya mengerjakan proyek sampingan di MacBook 16 GB. Ia ingin model lokal untuk menulis pesan commit dan catatan singkat, terutama supaya bisa bekerja offline di kereta.

Ia membuka Explore, memfilter Text Generation, dan melewati semua yang berlabel merah. Dua kandidat berlabel hijau, jadi ia memasang keduanya dengan Install Locally. Lalu ia membuka Playground, mengetik satu prompt, dan menambahkan kedua model sebagai panel. Playground mengirim prompt yang sama ke dua sampai empat model sekaligus dan menampilkan jawabannya berdampingan, dengan waktu ke token pertama dan jumlah kata di bawah tiap panel.

Belakangan ia menemukan model yang ia suka, tapi hanya tersedia sebagai file F16 presisi penuh. Ukurannya sekitar 15 GB, terlalu besar untuk laptopnya. Di Quantize ia memilihnya di "The model to shrink", memilih Q4_K_M, level yang direkomendasikan aplikasi untuk kebanyakan orang, lalu menjalankannya. llama-quantize bawaan menulis ulang file itu di mesinnya; tidak ada yang diunggah.

Pada contoh di atas hasilnya 4.58 GiB, 3.3 kali lebih kecil dari aslinya. Sebelum memercayainya, ia mengeklik Measure quality, yang membandingkan file baru dengan file asli dan mengisi kolom "same top token" dan rata-rata KLD di tabel Compare, lalu Measure speed untuk melihat token per detik. Satu klik Try it in Playground menaruhnya lagi di samping dua model lainnya. Malam itu ia selesai dengan model yang muat, angka yang menunjukkan berapa harga dari pengecilan itu, dan tanpa riwayat terminal sama sekali.

Tim kecil dengan satu desktop kuat

Sebuah agensi berisi empat orang punya satu desktop bermemori besar di kantor dan beberapa laptop tipis. Model besar hanya muat di desktop, tapi semua orang ingin memakainya.

Di desktop, seseorang membuka Servers, memilih This Mac, lalu masuk ke tab Access. Ia mencentang "Allow access from other devices on the local network (LAN)" dan mengaktifkan Remote Access. Panel itu kemudian menampilkan semua model lokal yang akan dilayani mesin tersebut. Di bawah Device keys ia mengeklik New key, menamainya sesuai laptop seorang rekan, lalu Create key. Setiap key bisa dicabut sendiri-sendiri, dan key khusus inferensi bisa menjalankan model tapi tidak bisa mengakses sesi agen.

Di tiap laptop, rekannya membuka Servers, mengeklik Add Server, memasukkan alamat desktop, menempelkan key, lalu memakai Test Connection. Begitu tersambung, model-model di desktop muncul di pemilih model laptop seperti model lainnya. Aplikasinya sendiri mencatat bahwa lalu lintas ini memakai HTTP biasa, jadi memang ditujukan untuk jaringan tepercaya seperti LAN kantor.

Lalu seseorang membuka Benchmarks, mengeklik New Benchmark, memilih model, dan membiarkan suite Quick. Hasilnya mencatat token per detik, waktu ke token pertama, dan latensi, jadi tim bisa tahu apakah model bersama itu cukup cepat dipakai saat meeting atau hanya cocok untuk batch semalam. Kalau terasa lambat, Servers juga punya tab Config tempat model draf kecil bisa dipasang di Speculative Decoding, lalu Restart now, dan benchmark bisa dijalankan lagi untuk membandingkan.

Hasilnya, tim punya satu mesin yang mengerjakan tugas berat, satu key per laptop yang bisa dicabut tanpa mengganggu yang lain, dan jawaban terukur untuk pertanyaan "cukup cepat atau belum?".

Kepala operasional yang tidak menulis kode

Ken menangani layanan pelanggan sebuah toko online kecil. Ia punya dua pertanyaan: model mana yang membaca total invoice dengan benar, dan bisakah model belajar membalas dengan gaya bahasa toko?

Untuk yang pertama, ia membuka Eval dan mengeklik Custom Benchmark. Ia memberinya nama, menempelkan sepuluh invoice beserta total yang ia harapkan untuk masing-masing, membiarkan Exact Match, lalu mengeklik Create Benchmark. Berikutnya New Eval Run: ia mencentang dua model di komputernya, mencentang benchmark-nya, lalu mengeklik Start Evaluation. Pertanyaan dikirim ke tiap model di mesinnya sendiri.

Pada contoh ini satu model mendapat 90 dan yang lain 70, dan kolom Diff menunjukkan selisih 20 poin. Itu hasil dari dokumennya sendiri, bukan leaderboard milik orang lain.

Untuk soal gaya bahasa, ia mengumpulkan beberapa ratus pesan pelanggan lama beserta balasan yang benar-benar dikirim tim, satu pasang per baris. Di Datasets ia bisa memasukkan file itu, atau mencari data publik lewat tab Hub, lalu memakai "Use for Training" untuk meneruskannya. Di Training ia mengeklik New Job dan mengikuti empat langkah: Base Model, Dataset, Config, dan Review. Di Training Target ia memilih Local (This Device), yang menurut layar berjalan di GPU perangkat dan gratis, dengan LoRA sebagai metodenya.

Setelah Start Training, job menampilkan nilai loss selama berjalan. Begitu selesai, adapter hasil training muncul di My Models di samping model dasar asalnya, dan "Chat with your model" pada run yang selesai menyiapkannya untuk runtime di perangkat sehingga ia bisa bertanya sesuatu di Playground. Akhirnya ia punya model kecil yang privat dan benchmark yang bisa dijalankan ulang setiap kali mempertimbangkan model baru.

Di mana Local Model menyerahkan tongkat estafet

Kategori ini tidak berdiri sendiri. Model yang kamu pasang atau hubungkan muncul di daftar model yang sama dengan yang dipakai chat, jadi model lokal bisa menjawab percakapan biasa atau dibandingkan di Playground dengan model cloud yang kamu tambahkan di Providers. Dari Explore, "Use in Notebook" membuka notebook JupyterLab yang sudah disiapkan untuk model itu, baik secara lokal maupun di instance hosting. Saat model butuh GPU sungguhan alih-alih laptopmu, Deployments dan Cloud GPU mengambil alih dan menaruhnya di endpoint terkelola. Sebelum model dipakai pelanggan, Safety menjalankan rangkaian uji red team terhadap model yang sudah di-deploy. Halaman inferensi lokal membahas mesin di perangkat lebih dalam, dan halaman fine-tuning LoRA membahas sisi training-nya.

Pertanyaan yang paling sering muncul

Apakah saya butuh GPU atau PC gaming?
Tidak. Laptop yang cukup baru sudah bisa untuk model kecil dan menengah; label kecocokan di Explore memberi tahu apa yang muat di mesinmu sebelum mengunduh. Desktop yang lebih kuat atau server remote hanya memperpanjang daftarnya.

Apakah ada yang dikirim ke cloud?
Inferensi lokal, Quantize, dan training lokal berjalan di mesinmu. Training dengan Cloud GPU, endpoint Cloud GPU, dan Providers adalah bagian yang memakai layanan luar, dan layarnya diberi keterangan, misalnya "Managed cloud GPU · needs credits" di dialog training.

Apa bedanya Eval dan Benchmarks?
Eval menilai kualitas jawaban berdasarkan pertanyaan yang kamu tentukan. Benchmarks mengukur kecepatan dan memori: token per detik, waktu ke token pertama, dan latensi.

Di mana saya bisa mendapatkan aplikasinya?
Local Model berjalan di aplikasi desktop, yang bisa kamu unduh di osfoundry.io/id/download.

Wie Memory und Knowledge Base in osFoundry speichern, was deine KI gelernt hat, und es als Kontext zurückgeben

tauchiii — Fri, 06 Nov 2026 14:00:43 +0000

Montag, 9:40 Uhr, du öffnest einen neuen Chat mit deinem Coding-Agenten. Letzten Donnerstag hat er eine Stunde gebraucht, um herauszufinden, dass der Billing-Service auf Postgres 16 läuft und die komplette Testsuite vier Minuten dauert. Heute stellt er dir beide Fragen erneut. Du antwortest, er nickt, und irgendwo im Hinterkopf beginnst du eine Liste mit Dingen, die du am Freitag schon wieder erklären musst.

Was die Knowledge-Funktionen sind

osFoundry hat eine Gruppe von Funktionen, die genau diese Wiederholung beenden sollen: Note, Knowledge Base, Memory mit seinen Memory Groups, Lessons, Chat History und Indexed Folders. Einfach gesagt sind das die Orte, an denen gespeichert wird, was du schreibst und was deine Agenten herausfinden, plus die Schalter, die entscheiden, was davon beim nächsten Lauf als Kontext an die KI zurückgeht. In der Desktop-App ist das kein einziges großes Panel, sondern mehrere Screens: Notes für deine eigenen Dokumente, Knowledge Base für gemeinsame Artikel, Memory (Untertitel "What Maestro knows & reads") für alles, was sich der Assistent und deine Agenten merken, und Indexes für Ordner, die du ausdrücklich für die Suche freigibst. Wenn du schon mal ein Wiki neben einem Chat-Assistenten benutzt hast: Stell dir vor, das Wiki und das Notizbuch des Assistenten liegen in derselben App, und an jedem Regal hängt ein Schalter, der festlegt, ob die KI es lesen darf.

Ein erster Blick auf den Memory-Screen

Das ist Memory mit ausgewähltem Agents-Bereich, gefüllt mit Beispieldaten. Was du siehst:

Die linke Leiste: Memory Groups, Memory Browser, Chat History, Agents, Sessions und Lessons. Unter "Indexing" liegen Chunking Station, Indexed Folders und Embeddings, die den Indexes-Screen öffnen.
Die Agentenliste ("Agents with memory"): jeder Agent mit der Anzahl seiner Memories und Lessons, hier @code-agent und @research-agent.
"What it knows": Fakten, die aus abgeschlossenen Schritten und Chat-Turns gespeichert und in späteren Läufen des Agenten wieder eingelesen werden. Im Beispiel: die Postgres-Version, der Testbefehl und dass du kleine Pull Requests bevorzugst.
"What it learned": Regeln, die erst geschrieben werden, nachdem ein Reviewer die Arbeit abgelehnt hat oder ein Schritt fehlgeschlagen ist.
"Move what it learned": Save to a file und Import from a file, denn Memories und Lessons bleiben auf dem Gerät und wandern nicht von selbst mit einem Agenten auf einen anderen Rechner. Oben steuern Settings und Turn off das Agenten-Gedächtnis als Ganzes.

Drei Arten, wie Leute es nutzen

Eine Solo-Entwicklerin, die ständig die Codebasis neu erklärt

Maya pflegt allein eine mittelgroße API und lässt die meisten Änderungen von einem Agenten erledigen. Ihr Problem ist nicht, dass der Agent schlecht wäre, sondern dass jede Session bei null anfängt.

Sie öffnet Indexes, bleibt im Tab Sources und klickt auf Add folder, um das Repository auszuwählen. Der Scan ist kostenlos und zeigt, was indexiert wird, bevor irgendetwas embedded wird. Sie wählt "Index locally", wodurch die Embeddings mit einem On-Device-Modell auf ihrem eigenen Rechner erzeugt werden, und aktiviert "Re-index automatically when files change", damit der Index mit ihren Änderungen Schritt hält.

Wenn sie Maestro jetzt ganz normal fragt, wo die Logik für die Kontosperrung steckt, kann der Agent eine Ordnersuche starten, die Stichwort- und Bedeutungssuche kombiniert, und liefert Dateipfade und Zeilenbereiche statt einer Vermutung. Im Lauf einiger Tage tauchen die Fakten, die der Agent unterwegs aufschnappt, unter Memory → Agents → "What it knows" auf, sodass das nächste Gespräch schon damit beginnt.

Was sie am Ende hat: einen Agenten, der in ihrem Code nach Bedeutung suchen kann, und eine kurze, lesbare Liste dessen, was er sich über ihr Projekt merkt, die sie jederzeit prüfen kann.

Ein Teamleiter, der will, dass der Agent einen Fehler nicht wiederholt

Daniel leitet ein kleines Team, in dem Agenten Änderungen entwerfen und eine Review-Stufe sie prüft. Vor zwei Wochen hat ein Agent einen fehlschlagenden Test "repariert", indem er ihn gelöscht hat. Der Reviewer hat diesen Lauf abgelehnt, und osFoundry hat aus der Ablehnung eine Lesson geschrieben.

Er öffnet Memory → Lessons. Dort stehen die Lessons aller Agenten zusammen mit dem Lauf, aus dem sie stammen, formuliert als "When … : …". Die nützlichen behält er, etwa "When a test fails after your change: fix the code. Never edit, skip or delete the test to make it pass." Eine Zeile trägt das Badge "from outside content": Sie stammt von einer Preisseite, die der Research-Agent gelesen hat, und besagt, immer einen bestimmten Tarif zu empfehlen. Der Agent behandelt solche Lessons als Vorschläge, nicht als Anweisungen, aber Daniel will sie dort überhaupt nicht haben und klickt deshalb auf Retire.

Mit aktiviertem "Show retired" bleibt die zurückgezogene Zeile ausgegraut sichtbar, mit einem Restore-Button, sodass nichts verloren ist, falls er es sich anders überlegt. Was er am Ende hat: Agenten, die vor jedem Lauf die neuesten aktiven Lessons lesen, und eine nachvollziehbare Liste aller Regeln, die sie gelernt haben, samt Herkunft.

Eine Beraterin, die will, dass die KI das Material des richtigen Kunden nutzt

Aiko ist freiberufliche Beraterin, keine Entwicklerin. Ihre Kundenunterlagen sind ein paar hundert Word-Dokumente und PDFs in Ordnern auf ihrem Laptop, und der Assistent soll daraus antworten, ohne Kunden durcheinanderzubringen.

In Notes klickt sie auf Import… und wählt "Import folder…" (laut Menü für einen Obsidian-Vault oder einen entpackten Export; "Import .zip archive…" deckt einen Notion-Export oder ein Bear-Backup ab). Die Desktop-App wandelt die Dateien offline in Notizen um und übernimmt die Ordnerstruktur in den File Tree.

Für Seiten, die sie bei allen Kunden wiederverwendet, etwa ihre Onboarding-Checkliste und ihre Standardkonditionen, baut sie eine Knowledge Base: New Knowledge Base, dann New article, oder Import content aus PDF, DOCX, Markdown, einem Notion- oder Confluence-Export oder einem Website-Crawl. Nach dem Bearbeiten eines Artikels klickt sie auf Generate chunks, damit die KI die aktuelle Version abruft; reines Bearbeiten indexiert ihn nicht neu.

Danach geht sie zu Memory → Memory Groups und legt pro Kunde eine Gruppe an. In der Einstellung "When can this be recalled?" jeder Gruppe lässt sie den aktuellen Kunden auf Normal (durchsucht, wenn das Projekt es erlaubt) und setzt ein abgeschlossenes Mandat auf Never, wodurch es komplett aus der Suche verschwindet, aber gespeichert bleibt. Eine Memory, die in jeder Antwort stehen soll, ihre Preisliste, bekommt "Pin (always in context)". Was sie am Ende hat: Antworten aus dem Material des richtigen Kunden und einen ausdrücklichen Aus-Schalter für alles andere.

Wie es mit dem Rest der App zusammenspielt

Die Knowledge-Funktionen stehen meist nicht für sich, sondern versorgen andere Teile von osFoundry. Maestro, der In-App-Assistent, ist der Hauptleser: Er durchsucht Memory Groups, wenn eine Frage es erfordert, und nutzt Indexed Folders über seine Ordnersuche. Agenten auf den Screens Agent team und Single agent bringen ihr eigenes Gedächtnis und ihre Lessons in jedes Gespräch mit, an dem sie teilnehmen. Der Health-Tab des Indexes-Screens enthält Chunking Station und Embeddings; dort siehst du, welche Notizen, Artikel und Dateien geändert, fehlgeschlagen oder nie gechunkt wurden. Chat History bewahrt die Transkripte auf, die beim Komprimieren langer Gespräche entstehen, sodass du zu den Originalformulierungen hinter einer Zusammenfassung zurückkehren kannst. Und für Gespräche in anderen KI-Apps auf deinem Rechner listet External agents diese Sessions neben denen von osFoundry. Die Feature-Seiten zu agent memory groups und knowledge bases gehen jeweils mehr ins Detail.

Fragen, die Einsteiger stellen

Liest der Assistent automatisch alle meine Notizen?
Nein. Der Assistent liest Memories nicht automatisch, sondern durchsucht sie, wenn eine Frage es erfordert, und die Einstellung jeder Memory Group (Always on, Normal oder Never) legt fest, was diese Suche erreichen kann. Ordner werden erst indexiert, nachdem du sie auf dem Indexes-Screen hinzugefügt hast.

Wo wird das alles gespeichert?
Agenten-Memories und Lessons liegen auf deinem Gerät, und Lessons werden nie hochgeladen. Memory Groups können persönlich oder workspaceweit sein und auf diesem Gerät oder in der Cloud liegen; der Memory-Screen zeigt die Anzahl für beides.

Was ist der Unterschied zwischen Chat History, Sessions und Lessons?
Chat History ist das Transkript dessen, was gesagt wurde, Sessions zeigt, was Agenten aus jedem Schritt behalten haben, und Lessons sind die Regeln, denen Agenten beim nächsten Mal folgen. Die ersten beiden sind Belege, die du prüfen kannst; Lessons sind Leitlinien, die du zurückziehen oder wiederherstellen kannst.

Brauche ich die Desktop-App?
Für alles, was deinen eigenen Rechner liest, ja: Ordner-Indexierung, Datei-Import in Notes, Chat History und die Ansichten fürs Agenten-Gedächtnis laufen in der Desktop-App, die du auf der Download-Seite bekommst.