Qwen3

Sloth Brief: a local AI that reads your group chats while you sleep and gives you two lines in the morning This is a submission for the Slow and Steady challenge: build something with open-source AI that rewards laziness. Happy (belated) International Sloth Day. 🦥 Sloth Brief is an overnight agent for people who are in too many group chats. While you sleep, it reads every group chat that got busy since yesterday, using an open-weight model running on your own machine. When you wake up, there's one message waiting for you: ☀️ Good morning. 214 messages in 6 chats while you slept. Family settled on Sunday lunch at Grandma's at 11. The work group is still arguing about the launch date; nothing was decided. Needs you (2): → Linh asked if you can bring the speaker on Sunday (Family) → Minh needs your review on the pricing doc by Thursday (Work) Two lines of context, plus the messages that actually need you. Everything else, you can safely ignore. Your messages never leave your machine for summarizing, it never marks anything as read, and it costs nothing to run every night, forever. --- The problem: the morning scroll I'm in a family group, two friend groups, a work group, a building residents' group, and a group for a trip that happened in 2023 and still won't die. Every morning starts the same way: I open my phone, see a few hundred unread messages, and scroll. Most of it is memes, reactions, and conversations that were resolved hours ago. But somewhere in there is the one message where someone asked me something directly. If I skip the scroll, I miss it. If I do the scroll, I lose twenty minutes before I've even gotten out of bed. This is exactly the kind of work a sloth would refuse to do. So I made my computer do it instead, at 3 a.m., when nobody needs it for anything else. --- What I built Sloth Brief does three things, once a night: 1. Collects messages from your group chats since the last run. 2. Summarizes each busy chat with a local model and finds anything addressed to you. 3. Delivers one short message to your "Saved Messages," so it's the first thing you see in the morning. The design goal was simple: the brief should take less time to read than it takes to unlock your phone. --- Why "slow" is a feature here This is where the theme and the architecture meet. Most AI tools have to be fast, because someone is staring at a loading spinner. Sloth Brief doesn't. It runs at 3 a.m. and has until you wake up, which is hours. That changes which models make sense. I don't need a huge model on a powerful GPU, or a paid API that answers in two seconds. A small open-weight model running on an ordinary laptop CPU is more than fast enough, because "fast enough" means "done before breakfast." The sloth approach isn't just a theme. It's what makes local inference practical. --- How it works 3:00 a.m. (cron) │ ▼ ┌──────────────────────────────────┐ │ 1. Collect │ Telegram (your own account, read-only) │ messages since last run │ or exported chats └────────────────┬─────────────────┘ ▼ ┌──────────────────────────────────┐ │ 2. Filter │ muted chats, quiet chats, bots └────────────────┬─────────────────┘ ▼ ┌──────────────────────────────────┐ │ 3. Summarize each chat (map) │ local LLM via Ollama │ gist, decisions, asks for me │ JSON-schema output └────────────────┬─────────────────┘ ▼ ┌──────────────────────────────────┐ │ 4. Verify "needs you" items │ plain code: did they really ask *you*? └────────────────┬─────────────────┘ ▼ ┌──────────────────────────────────┐ │ 5. Write the brief (reduce) │ local LLM → two lines └────────────────┬─────────────────┘ ▼ ☀️ Message to yourself Step 1: Collect messages (without marking them as read) I use Telegram, which has an official API that lets you read your own chats with your own account. Telethon, an open-source Python client, makes that easy: from datetime import datetime, timezone from telethon import TelegramClient client = TelegramClient("sloth", API_ID, API_HASH) # your own app credentials async def collect(since: datetime) -> dict[str, list[dict]]: chats = {} async for dialog in client.iter_dialogs(): if not dialog.is_group: continue messages = [] async for m in client.iter_messages(dialog): # newest first if m.date < since: break if not m.text: continue sender = await m.get_sender() messages.append({ "id": m.id, "from": getattr(sender, "first_name", None) or "Someone", "text": m.text, "reply_to": m.reply_to_msg_id, "is_me": m.out, }) if messages: chats[dialog.name] = list(reversed(messages)) # oldest first return chats Two details matter here: - Reading history this way doesn't send read receipts. Your friends won't see you "read" their messages at 3 a.m., and the chats stay unread in your app. - It only reads. Sloth Brief never posts in a group. The only message it sends is to your own "Saved Messages." If you use WhatsApp or another app, most of them can export a chat to a text file. Sloth Brief has a simple importer for those exports too. It's more manual, but still no cloud required. Step 2: Ignore what you'd ignore anyway A plain config file decides what's worth reading: me: names: ["An", "Anh", "@an_dev"] # how people refer to you mute: - "Trip 2023" # the chat that won't die min_messages: 10 # quiet chats aren't worth a summary skip_bots: true Any chat under the threshold just gets counted ("plus 3 quiet chats"), not summarized. Being lazy about what to read is half the job. Step 3: Summarize each chat with a local model Each busy chat is summarized separately. The model gets the messages as a numbered transcript and must answer in a fixed JSON structure, using Ollama's structured output: import ollama from pydantic import BaseModel class Ask(BaseModel): message_id: int who: str what: str # short, in plain words class ChatSummary(BaseModel): gist: str # one sentence: what happened decisions: list[str] # anything agreed on asks_for_me: list[Ask] SYSTEM = """You summarize a group chat for a busy person named {name}. - gist: one plain sentence about what mattered. Ignore memes, greetings and reactions. - decisions: only things the group actually agreed on. - asks_for_me: only messages that ask {name} directly or reply to {name}. Use the exact message_id from the transcript. If there are none, return an empty list. Never invent messages, people, times, or decisions.""" def to_transcript(messages: list[dict]) -> str: return "\n".join(f"[{m['id']}] {m['from']}: {m['text']}" for m in messages) def summarize_chat(messages: list[dict], my_name: str) -> ChatSummary: resp = ollama.chat( model="qwen3:8b", messages=[ {"role": "system", "content": SYSTEM.format(name=my_name)}, {"role": "user", "content": to_transcript(messages)}, ], format=ChatSummary.model_json_schema(), options={"temperature": 0.2}, ) return ChatSummary.model_validate_json(resp.message.content) Very long chats are split into chunks of a few hundred messages, summarized chunk by chunk, and merged. That's slower, but again, it's 3 a.m. Nobody's waiting. Step 4: Verify every "needs you" item The "Needs you" list is the most important part of the brief, and the worst place for a mistake. A model that invents "Minh needs your review by Thursday" could send me chasing a task that doesn't exist. A model that misses a real ask is just as bad. So every ask the model returns is checked with plain code against the real messages: def verify_asks(summary: ChatSummary, messages: list[dict], my_names: list[str]) -> list[Ask]: by_id = {m["id"]: m for m in messages} my_ids = {m["id"] for m in messages if m["is_me"]} names = [n.lower() for n in my_names] verified = [] for ask in summary.asks_for_me: m = by_id.get(ask.message_id) if m is None or m["is_me"]: continue # message doesn't exist, or it's mine mentions_me = any(n in m["text"].lower() for n in names) replies_to_me = m["reply_to"] in my_ids if mentions_me or replies_to_me: verified.append(ask) return verified An ask only makes it into the brief if the message exists and either mentions me or replies to one of my messages. The model does the hard part, understanding that "can you bring the speaker?" is a request. The code makes sure it's pointing at a real message. There's also a safety net in the other direction: any message that mentions my name but wasn't flagged by the model gets added as "You were mentioned in Work (1 message)." The model can be lazy, but it can't make me miss something. Step 5: Write the brief The last step takes all the chat summaries and squeezes them into two lines: class Brief(BaseModel): line_1: str line_2: str def write_brief(summaries: dict[str, ChatSummary]) -> Brief: gists = "\n".join(f"{chat}: {s.gist} Decisions: {s.decisions}" for chat, s in summaries.items()) resp = ollama.chat( model="qwen3:8b", messages=[ {"role": "system", "content": ( "Write a morning brief in exactly two short, plain sentences. " "Lead with decisions and plans. Skip anything trivial. No emojis." )}, {"role": "user", "content": gists}, ], format=Brief.model_json_schema(), options={"temperature": 0.3}, ) return Brief.model_validate_json(resp.message.content) The "Needs you" list isn't written by the model at all. It's assembled directly from the verified asks in Step 4, so it can't be paraphrased into something nobody said. Then the whole thing is sent to your own Saved Messages: await client.send_message("me", brief_text) Step 6: Schedule it and forget it One cron line, and Sloth Brief runs every night: 0 3 * * * cd ~/sloth-brief && python sloth.py run >> sloth.log 2>&1 It needs a machine that's awake at 3 a.m.: a laptop on its charger, an old PC, or a small single-board computer in a corner. If the machine was asleep, Sloth Brief simply runs when it wakes and covers everything since the last run. --- Why open innovation matters for this project 1. These aren't just my messages This is the most important reason, and it's easy to overlook. A group chat isn't only my data. It's my mom's messages, my friends' jokes, my coworkers' complaints about the launch date. None of them agreed to have their messages sent to an AI company's servers so that I could skip my morning scroll. With a local open-weight model, the summarizing happens entirely on my machine. My friends' messages go from the chat app to my laptop, and nowhere else. That isn't a privacy setting I have to trust; it's just how the system works. 2. Slow and steady means small models are enough Because the job runs overnight, I don't need speed, and that's exactly where open models shine. A small model on a CPU might take a while to work through a few hundred messages, and that's fine. A paid API would make every night faster at something that doesn't need to be fast, and charge me for it. 3. Set it up once, never pay again A morning summary is useful every single day, which is exactly the kind of tool that becomes expensive with per-request pricing. Running an open model locally, the cost is a bit of electricity overnight. There's no subscription to cancel and no bill that grows with how chatty my friends are. 4. I control how it behaves Every part of the agent's behavior is something I can see and change: - What counts as "needs you." The verification rules are plain Python. - What gets ignored. Muted chats and thresholds are a config file. - The tone. The prompts are in the repo. If I want the brief shorter, funnier, or in another language, I edit a line. - The model. Swapping to a newer open model is a one-line change, with no migration and no new account. With a closed assistant, I'd get whatever summary style the provider decided on, and whatever their policy says about my messages this year. 5. Most of it works offline Collecting messages needs the internet, of course. But everything after that, summarizing, verifying, and writing the brief, runs with no connection at all. Nothing about the AI part depends on a service being up at 3 a.m. Where closed would have been easier (to be fair) Large hosted models are better at sarcasm, inside jokes, and messages that mix several languages. A small local model sometimes reports a joke as a decision, or misses that "lol sure" means "no." For this job, that's an acceptable trade. The brief is a starting point, not a replacement for the chats, and the verification step means it can't invent requests. Getting the gist slightly wrong now and then is a small price for never sending my friends' private messages to someone else's server. --- Limitations - It needs a machine that's on overnight. Or at least one that wakes up before you do. - Telegram is the smoothest path. Other apps rely on manual chat exports, which is less lazy than I'd like. - Sarcasm and mixed languages are hard for small models. Treat the brief as a summary, not as the source of truth. - It only reads text. Voice messages and images are counted, not summarized (yet). --- What's next - [ ] Transcribe voice messages overnight with a local speech model - [ ] Describe shared images with a small local vision model ("Linh sent 4 photos from the beach") - [ ] A weekly digest for chats too slow to deserve a daily one - [ ] "Snooze until": hide a chat from the brief until a date, then bring it back --- Try it pip install telethon ollama pydantic pyyaml ollama pull qwen3:8b cp config.example.yaml config.yaml # add your names and muted chats python sloth.py login # one-time Telegram login python sloth.py run # test it once, then add the cron line Then go to sleep. That's the whole point. 🦥 --- Built with: Ollama, Qwen3 (open weights), Telethon, Pydantic, Python.

SlothSort AI 🦥 SlothSort AI > Hacktoberfest 2026: Slow and Steady Challenge > Privacy-First, Offline AI File Organizer Powered by Local Open-Weight Models        --- 📖 Table of Contents - [Overview & The "Slow and Steady" Philosophy](#overview--the-slow-and-steady-philosophy) - [The Problem Being Solved](#the-problem-being-solved) - [Why Local Open-Weight AI is Essential](#why-local-open-weight-ai-is-essential) - [Key Features](#key-features) - [Safety & Privacy Architecture](#safety--privacy-architecture) - [Application Architecture](#application-architecture) - [Honest Demo Mode (Simulated AI)](#honest-demo-mode-simulated-ai) - [Installation & Setup on Windows](#installation--setup-on-windows) - [Configuring Local Ollama Models](#configuring-local-ollama-models) - [Running the Application](#running-the-application) - [Testing & Quality Assurance](#testing--quality-assurance) - [Cost Trade-offs: Local AI vs Cloud APIs](#cost-trade-offs-local-ai-vs-cloud-apis) - [Model Licensing Considerations](#model-licensing-considerations) - [Security Limitations](#security-limitations) - [Future Roadmap](#future-roadmap) - [License](#license) --- 🦥 Overview & The "Slow and Steady" Philosophy Automated file organizers often fail because they move too fast: scripts run blindly in the background, opaque rules scatter your tax returns across unknown directories, and cloud services demand you upload your private personal documents to external servers. SlothSort AI takes the opposite approach: - Slow: Every action is inspectable. Nothing moves without explicit, line-by-line user approval. - Steady: Defaults to Dry-Run mode, checks for name collisions, and preserves an atomic, single-click Undo log for every operation batch. - Local: Runs completely offline using local open-weight language models via Ollama. Not a single byte of your file metadata or content ever leaves your machine. --- 🎯 The Problem Being Solved User Downloads, Desktop, and project directories quickly become dumping grounds containing hundreds of poorly named files: - IMG_9482.jpg, IMG_9483.jpg (Cryptic camera imports) - hw3_cs101_draft_final_v2.docx (Student homework drafts) - invoice_unpaid_2026.pdf (Bills and financial statements) - Screenshot 2026-10-18 at 14.30.png (Unlabeled screenshots) - .env.local or id_rsa_backup.key (Sensitive credentials accidentally stored in downloads) Manual organization is tedious. Existing cloud-based AI tools demand that users upload personal file lists or full documents to third-party APIs (OpenAI, Anthropic, Google), creating major privacy and data leakage risks. SlothSort AI solves this by executing semantic categorization and descriptive renaming entirely on your local CPU or GPU, with zero telemetry and safe rollback support. --- 🛡️ Why Local Open-Weight AI is Essential 1. Absolute Data Privacy: Your filesystem structure reflects your personal and professional life. Sending filenames or document snippets over the public internet exposes employment details, financial records, student IDs, and project codenames. 2. Air-Gapped & Offline Autonomy: Works on trains, airplanes, remote environments, and strictly air-gapped corporate workstations without requiring internet access. 3. No Subscription Lock-in: Open-weight models (Llama 3.2, Mistral, Phi-3, Qwen 2.5) are completely free to run on your own hardware without token fees, rate limits, or API outages. 4. Transparent Governance: You inspect the prompt, you choose the model weights, and you control the exact execution parameters. --- ✨ Key Features | Feature | Description | | :--- | :--- | | Safe Folder Selection | Windows-compatible folder workflow with automatic blocking of root drives (C:\) and Windows system folders. | | 1-Click Demo Mess Generator | Built-in button to instantly create a safe test folder with mock docs, images, spreadsheets, and sensitive test files. | | Sensitive File Shield | Automatically detects and excludes sensitive credentials (.env, id_rsa, *.pem, *.key) from processing or renaming. | | Ollama Local AI Inference | Formats safe, untrusted metadata into structured JSON prompts for local models (e.g. llama3.2). | | Honest Demo Mode | If Ollama is offline or uninstalled, seamlessly falls back to a deterministic semantic heuristic engine with clear labeling. | | Interactive Plan Preview | Displays original name, proposed category, inline editable filename, destination path, and collision status. | | Dry-Run Simulation | Enabled by default; simulates all folder creation and collision resolutions without touching the disk. | | Non-Destructive Collisions | Automatically numbers conflicting files (Photo_1.jpg, Photo_2.jpg) or skips them—never overwrites existing files. | | Atomic Undo & History Log | Stores batch operations in a local JSON log; reverts file moves and cleans up empty created folders with 1-click. | | Sage & Cream Aesthetic | Modern, accessible dashboard with micro-animations, glassmorphism cards, and Google Fonts typography. | --- 🔒 Safety & Privacy Architecture flowchart TD UserFolder["Target Folder (e.g., C:\\Users\\User\\Downloads)"] --> SafetyCheck["Safety Validator\n- Block C:\\ root\n- Block Windows system folders\n- Prevent symlink escapes"] SafetyCheck --> Scanner["Safe Scanner\n- Extract metadata\n- Detect & skip sensitive files (.env, keys)\n- Filter system noise (desktop.ini)"] Scanner --> Organizer{"AI Engine Available?"} Organizer -- "Yes (Ollama Online)" --> OllamaLLM["Local Ollama Model\n(llama3.2 / mistral)\n100% Offline Inference"] Organizer -- "No (Ollama Offline)" --> HeuristicEngine["Honest Demo Mode\nDeterministic Heuristics\nBadge: 'Simulated AI'"] OllamaLLM --> OutputSanitizer["Structured JSON Validator\n- Preserve original extension\n- Strip illegal Windows characters\n- Block reserved device names"] HeuristicEngine --> OutputSanitizer OutputSanitizer --> PlanPreview["Interactive Preview Table\n- Inline filename edits\n- Approve / Reject toggles"] PlanPreview --> ExecutionEngine{"Dry-Run Mode?"} ExecutionEngine -- "True (Default)" --> DryRunSummary["Simulation Report\nZero disk writes"] ExecutionEngine -- "False (Approved)" --> FileExecutor["Atomic Executor\n- Create category folders\n- Move files without overwrite\n- Record batch in history"] FileExecutor --> HistoryLog["Local JSON Operations History"] HistoryLog --> UndoEngine["Atomic Rollback Engine\nRestores original files & removes empty dirs"] --- 🚀 Installation & Setup on Windows Prerequisites - Windows 10 / 11 - Python 3.10+ (Available via py or python) - Node.js v18+ & npm - (Optional for real AI) Ollama for Windows --- Step 1: Clone the Repository git clone https://github.com/your-username/SlothSort-AI.git cd "SlothSort AI" --- Step 2: Install Backend Dependencies From the project root: py -m pip install -r backend/requirements.txt --- Step 3: Install Frontend Dependencies cd frontend npm install cd .. --- Step 4 (Optional): Install and Run Ollama for Local AI 1. Download and install Ollama from ollama.com. 2. Open PowerShell and pull your preferred lightweight model (e.g. Llama 3.2 3B or 1B): ollama pull llama3.2 3. Ensure the Ollama service is running on its default port (http://localhost:11434). > Note: If Ollama is not installed or running, SlothSort AI will automatically run in Honest Demo Mode using its built-in rule heuristics. --- 💻 Running the Application Option A: One-Click Windows Batch Launcher Double-click run_slothsort.bat or run: .\run_slothsort.bat This launches both the FastAPI backend and Vite frontend, then opens your default browser at http://localhost:5173/. --- Option B: Manual Startup Terminal 1 (Backend): py -m uvicorn backend.app.main:app --host 127.0.0.1 --port 8000 --reload Terminal 2 (Frontend): cd frontend npm run dev Visit **http://localhost:5173** in your browser. --- 🧪 Testing & Quality Assurance SlothSort AI includes a comprehensive automated test suite covering safety constraints, duplicate collision resolution, organization planning, atomic undo logic, and API integration. Running Backend Unit Tests py -m pytest backend/tests -v Test Suite Coverage (21/21 Passing): - test_safety.py: - Empty and non-existent path validation - Drive root rejection (C:\, /) - Windows system directory protection (C:\Windows, System32, Program Files) - Boundary traversal and symlink escape prevention - Illegal Windows filename characters (< > : " / \ | ? *) - Reserved device name handling (CON, PRN, AUX, NUL, COM1) - Sensitive credential detection (.env, id_rsa, .key, .pem) - test_duplicates.py: - Collision resolution with automatic counter increment (file_1.ext, file_2.ext) - Non-colliding path preservation - test_organizer.py: - Deterministic heuristic classification across categories - Academic cue mapping (College category for homework/assignments) - Demo mode plan generation and schema integrity - Ollama prompt structure and extension preservation rules - test_undo.py: - Dry-run verification (ensures zero disk modifications) - Real move execution and atomic rollback - Automatic cleanup of emptied category folders - test_api.py: - Full end-to-end FastAPI endpoint integration via TestClient Running Frontend Production Build Test cd frontend npm run build --- ⚖️ Cost Trade-offs: Local AI vs Cloud APIs | Factor | Local Open-Weight (SlothSort AI) | Cloud AI APIs (OpenAI / Claude) | | :--- | :--- | :--- | | Privacy | 100% Private — Zero external transmission | Metadata & file contents sent to 3rd-party servers | | Recurring Cost | $0.00 / month — Forever free | Pay-per-token API bills ($0.001 - $0.03 / request) | | Internet Dependency | None — Works fully air-gapped | Mandatory high-speed internet connection | | Rate Limits | None — Constrained only by local compute | Strict requests/minute & tokens/minute quotas | | Hardware Requirement | 4GB - 8GB RAM (CPU or entry-level GPU) | Minimal local hardware (runs in browser) | | Setup Effort | 1-click Ollama install | Requires account registration, credit card, and API keys | --- 📜 Model Licensing Considerations SlothSort AI itself is distributed under the permissive MIT License. When pairing SlothSort AI with local open-weight language models via Ollama: - Llama 3.2 (Meta): Distributed under the Llama 3.2 Community License. Free for research and commercial use up to 700M monthly active users. - Mistral 7B / Nemo (Mistral AI): Distributed under the permissive Apache 2.0 License. - Phi-3 (Microsoft): Distributed under the MIT License. - Qwen 2.5 (Alibaba): Distributed under the Apache 2.0 License. You are free to switch between any of these models via the Settings Modal or by setting the OLLAMA_MODEL environment variable. --- ⚠️ Security Limitations While SlothSort AI implements rigorous guardrails, users should observe the following best practices: 1. Never organize root drives: The backend actively forbids selecting C:\ or drive roots. Keep organization focused on specific folders like Downloads, Documents, or Desktop. 2. Never organize git repositories directly: Organizing a .git directory directly is blocked to prevent corrupting version control trees. 3. Sensitive file inspection: SlothSort AI excludes known secret filenames (.env, id_rsa, *.key) by default. If your files contain unencrypted passwords inside regular .txt documents, consider moving them to a secure password manager. 4. Untrusted LLM Output Sanitization: Model suggestions are treated as untrusted strings. The backend sanitizes all proposed filenames and forces the original file extension to be preserved. --- 🔮 Future Roadmap - [ ] Support for custom user-defined category mapping rules (e.g. tax year folders). - [ ] Lightweight vision-language model support (e.g., llava or llama3.2-vision) for OCR-based receipt reading. - [ ] Background folder watcher daemon with configurable interval. - [ ] Exportable organization audit receipts in PDF / Markdown format. - [ ] Cross-platform desktop wrapper via Tauri. --- 📄 License SlothSort AI is open-source software licensed under the [MIT License](LICENSE). Built with care for Hacktoberfest 2026: Slow and Steady.

Qwen3-4B deslop corta las muletillas de IA de 121 a 12,5 por 1000 palabras Un ingeniero entrenó a Qwen3-4B para que dejara de escribir como una IA: el puntaje de muletillas de IA bajó de 121 a 12,5 por cada 1.000 palabras, y los guiones largos retóricos pasaron de 20,5 por 1.000 palabras a cero, según documenta el propio autor. El resultado se llama qwen3-4b-deslop y pesa 2,5 GB en su versión cuantizada. Cualquiera puede descargarlo con Ollama y comparar, prompt por prompt, cómo responde frente al modelo original. No es un experimento de laboratorio cerrado: es un modelo público que corre en una laptop. TL;DR - El puntaje de muletillas de IA de Qwen3-4B-deslop cae de 121 a 12,5 por 1.000 palabras tras el fine-tuning.- Los guiones largos (em dash) desaparecen por completo: de 20,5 por 1.000 palabras a cero.- RLHF premia el tono que suena 'servicial', y ese sesgo es el origen de los tics de escritura de la IA.- Un LoRA sobre 161 respuestas filtradas quita las muletillas sin tocar el conocimiento: acierta 30/30 preguntas.- Ollama corre el modelo cuantizado (2,5 GB) en tu laptop para comparar el antes y el después en tus propios prompts. ¿Qué son las muletillas de IA? Las muletillas de IA son fragmentos de estilo que un modelo de lenguaje repite con tanta frecuencia que delatan su origen artificial: el guion largo como pausa dramática, los tríos de adjetivos, la fórmula "no es X, sino Y" y las preguntas que el propio texto responde de inmediato. Es parecido a lo que pasa con un vendedor que aprende, a fuerza de repetir el mismo discurso, qué frases hacen asentir a la mayoría de la gente aunque no digan nada nuevo. El modelo no entiende que esas frases son vacías: solo sabe que, en el entrenamiento, subieron su calificación. No son errores aleatorios. Vienen del mismo proceso de entrenamiento, y por eso aparecen con la misma forma en modelos de laboratorios distintos. Entender de dónde salen es el primer paso para poder quitarlas sin dañar lo que el modelo sabe. Por qué aparecen: el sesgo de RLHF hacia la aprobación humana El afinado que le da a un modelo su "voz de asistente" se llama aprendizaje por refuerzo con retroalimentación humana (RLHF). Un grupo de personas califica pares de respuestas, un modelo de recompensa aprende a predecir esas calificaciones y el modelo final se ajusta para maximizar esa puntuación. El problema es que los calificadores humanos no leen con la misma atención que un editor. Premian respuestas que "se sienten" completas y seguras, y ciertos adornos superficiales generan esa sensación sin aportar información real. Un trío de adjetivos suena exhaustivo. Una pregunta respondida en la misma frase suena didáctico. Un guion largo en mitad de la oración suena a pausa reflexiva. Nada de eso añade un dato, pero sí sube la calificación promedio. Por eso los tics de escritura de la IA no son un capricho de un modelo en particular, sino el subproducto estadístico de optimizar para el gusto promedio de miles de calificadores. Y como el proceso se repite en cada laboratorio con metodologías parecidas, los mismos hábitos aparecen en modelos que nunca compartieron código ni datos de entrenamiento. El modelo original promediaba 121 puntos de muletillas por 1.000 palabras. Cómo funciona el fine-tuning dirigido para quitarlas Antes de tocar los pesos del modelo, el autor probó dos atajos que no requieren reentrenar nada. El primero fue el "activation steering": restar, durante la generación, la dirección interna que corresponde a la "voz de asistente", combinada con un prompt de sistema que pide un estilo plano. Funciona, y bajó el puntaje hasta cerca de 15, pero necesita ese prompt y ese código corriendo en cada respuesta, y además desvía las predicciones del modelo sobre texto normal que no tiene nada que ver con el estilo. El segundo atajo fue más quirúrgico: revisar neuronas una por una hasta encontrar cuatro cuya activación, si se invierte, elimina el 70% de los casos de "no es X, sino Y" casi sin costo. Pero ese parche solo funciona para esa muletilla puntual y no generaliza al resto de los hábitos. Para resolverlo de forma permanente, dentro de los pesos y sin hooks en tiempo de ejecución, el autor usó destilación. Un modelo "profesor" (construido con lo mejor que había funcionado hasta ese punto) genera respuestas a un conjunto de prompts de entrenamiento. Las respuestas que pasan los filtros de calidad alimentan un adaptador LoRA pequeño, que aprende a producir ese mismo estilo a partir del prompt original, sin el profesor ni el código extra. flowchart TD A["Profesor genera 3 respuestas por prompt"] --> B["Filtro: puntaje de muletillas bajo 12"] B --> C["Filtro: sin daño (deriva y quiz de 30 preguntas)"] C --> D["Filtro: la respuesta cumple la tarea pedida"] D --> E["LoRA aprende del subconjunto aprobado"] E --> F["Modelo estudiante Qwen3-4B-deslop"] La primera ronda de este proceso, sin gancho de estilo ni esteroides de prompt, ya bajó el puntaje a cerca de 20. Fue la prueba de que destilar funciona mejor que forzar el estilo en tiempo de ejecución. flowchart LR R1["Ronda 1: puntaje cercano a 20"] --> R2["Ronda 2: puntaje 9.9, pero falla el ajuste a la tarea"] R2 --> R3["Ronda 3: puntaje 12.5, ajuste a la tarea en 80%"] El detector de tics de escritura: cómo se mide el puntaje Para saber si el modelo mejoró, hace falta medir, no solo mirar. El detector que usa el autor mide patrones de escritura de IA con un conjunto de reglas con pesos. Cuenta guiones largos, apariciones de "no es X, sino Y", tríos de tres elementos, preguntas retóricas respondidas en la misma frase, muletillas de transición como "aquí está la clave" y palabras como "delve" o "seamless" en inglés (sus equivalentes en español serían "profundizar en" o "sin fisuras" usados como relleno). Cada hábito pesa distinto, y la suma se normaliza por cada 1.000 palabras. Un detector basado en reglas no distingue por sí solo buena de mala escritura, así que el autor también revisó manualmente una muestra de respuestas en cada ronda. Un regex puede contar guiones largos, pero no puede decir si el párrafo que los rodea tiene sentido. flowchart LR T["Texto generado"] --> H1["Cuenta guiones largos"] T --> H2a["Cuenta 'no es X, sino Y'"] T --> H3a["Cuenta preguntas que se responden solas"] H1 --> S["Suma ponderada"] H2a --> S H3a --> S S --> P["Puntaje por 1.000 palabras"] Para ilustrar la idea, este es un detector simplificado en Python que cualquiera puede correr sobre un párrafo propio: import re def slop_score(text): words = len(text.split()) em_dashes = text.count(", ") not_x_but_y = len(re.findall(r"no es .*?, sino", text, re.IGNORECASE)) rhetorical = len(re.findall(r"\?\s*[A-ZÁÉÍÓÚ]", text)) raw = em_dashes * 3 + not_x_but_y * 4 + rhetorical * 2 return round(raw / words * 1000, 1) texto = "El framework no es solo rápido, es, ante todo, elegante. ¿Por qué importa? Porque resuelve tres problemas: velocidad, memoria y legibilidad." print(slop_score(texto)) Con ese párrafo de ejemplo (que acumula un guion largo y una pregunta respondida en la misma frase), la función devuelve 227.3. Es un juguete de diez líneas, no el detector real del autor, pero muestra el principio: contar patrones, no juzgar el tema. Ejemplos prácticos: antes y después El autor probó el modelo con 40 prompts que nunca vio en entrenamiento, repartidos en diez temas y cuatro géneros: reseña de producto, publicación personal, pieza de opinión y correo. En el modelo original, una pieza de opinión sobre el nuevo CRM de una empresa (ver el detalle en la publicación original) nunca tomaba una postura: leía como un reporte de incidente, lleno de guiones largos y tríos de beneficios. Una versión intermedia del modelo, entrenada antes de ajustar bien los filtros, se fue al otro extremo: bajó el puntaje de muletillas a 9,9, pero empezó a inventar datos. Citó un estudio de una universidad que no existe, y encadenó casi todas las oraciones con ", which" (el equivalente sería encadenar todo con ", lo cual" o ", así que"), 28 veces más seguido que el modelo original. Ese hábito nuevo venía del propio prompt que el autor le dio al profesor, que pedía unir oraciones "con porque, así que, pero, lo cual", y dos rondas de imitación lo habían amplificado sin querer. El filtro de ajuste a la tarea que añadió la tercera ronda no es un detector de estilo, sino un conjunto de reglas específicas por género. Un correo tiene que abrir con un saludo. Una reflexión personal tiene que estar en primera persona. Una pieza de opinión tiene que tomar postura temprano. Y la longitud tiene que acercarse a lo que pidió el prompt. Esas reglas, sumadas a contar las uniones con ", lo cual" y los estudios inventados, fueron las que detectaron el problema de la versión intermedia. La versión final, entrenada con ese filtro adicional, subió apenas de 9,9 a 12,5 en el puntaje de muletillas, pero recuperó el ajuste a la tarea: del 60% de la versión intermedia al 80% del modelo original. Las uniones con ", lo cual" bajaron de 1,4 a 0,3 por cada 100 palabras. > ⚠️ Ojo: optimizar solo por el puntaje de muletillas, sin medir si la respuesta cumple la tarea, produce un modelo que escribe plano pero inventa datos y evita tomar postura. Cómo empezar: correr Qwen3-4B-deslop en Ollama Para probarlo hace falta tener Ollama instalado. En Linux y macOS, el comando es: curl -fsSL https://ollama.com/install.sh | sh En Windows, el instalador se descarga directamente desde ollama.com. Con Ollama corriendo, el modelo cuantizado (2,5 GB) se descarga y arranca con un solo comando: ollama run hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M La primera vez, Ollama descarga el manifiesto y las capas del modelo, verifica su integridad y las guarda en disco. Cuando termina, abre un prompt interactivo donde se puede escribir directamente. Para comparar contra el modelo original, basta correr en otra terminal: ollama run qwen3:4b Y hacerle la misma pregunta a los dos. La diferencia de estilo entre ambas respuestas, el original lleno de guiones largos y tríos, el deslop más plano y directo, es el experimento que el propio autor invita a repetir. Para confirmar qué se descargó, ollama list muestra el nombre del modelo, su tamaño y la fecha de modificación en una tabla de texto. Y ollama show hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M imprime la cuantización, el tamaño de contexto y la familia del modelo. Qwen3-4B-deslop pesa 2,5 GB cuantizado y corre con un comando de Ollama. Casos de uso reales El caso de uso más directo es el control de calidad editorial: pasar un borrador generado por IA por un detector de hábitos de redacción sintética antes de publicarlo, igual que se corre un linter sobre código antes de un commit. Un medio o un canal técnico puede usarlo como filtro automático antes de que un editor humano revise el texto. También sirve como base para fine-tuning propio. El LoRA que produce qwen3-4b-deslop es chico, y el método (profesor que genera, filtros que aprueban, adaptador que aprende) se puede aplicar a cualquier estilo que se quiera reforzar o eliminar: no solo tics de escritura, también jerga corporativa, un tono de marca específico o un idioma de salida constante. Y hay un caso de uso educativo, que es el que motiva este artículo: correr el modelo original y el deslop lado a lado deja ver, en texto real y no en una tabla de benchmarks, qué efecto tiene exactamente el fine-tuning sobre el estilo de una IA. Errores comunes y buenas prácticas - Medir solo el estilo: un detector de muletillas no avisa si el modelo inventó un dato o evitó responder lo que se le pidió. Hace falta un chequeo de ajuste a la tarea en paralelo, no después.- Confiar en el prompt del profesor sin auditarlo: el hábito de unir cada oración con ", lo cual" salió del propio prompt que pedía conectores variados. Revisar las respuestas del profesor antes de usarlas para entrenar evita amplificar un sesgo nuevo.- Usar un solo filtro de daño: un quiz de conocimiento no detecta que el modelo dejó de tomar postura en una opinión. Hacen falta chequeos específicos por género de texto.- Tratar el puntaje como verdad absoluta: un regex cuenta patrones, no calidad. Revisar manualmente una muestra en cada ronda de entrenamiento sigue siendo necesario. Comparativa: tres formas de quitar los manierismos del modelo MétodoCuándo usarloVentajaLimitaciónPrompt de sistemaPruebas rápidas, sin acceso a los pesosNo requiere entrenar nadaEl efecto es parcial y se pierde si el prompt se recortaActivation steeringCuando se puede ejecutar código propio en la inferenciaBajó el puntaje a cerca de 15 sin tocar los pesosNecesita el hook corriendo siempre y desvía las predicciones en texto normalFine-tuning con LoRA (destilación)Cuando se quiere un modelo que se comporte así por defectoQueda dentro de los pesos, sin prompt ni código extra, con un tercio de la deriva del steeringRequiere generar y filtrar cientos de respuestas de entrenamiento Profundizando: la dirección oculta dentro de los pesos Un hallazgo previo del mismo autor, en un experimento anterior sobre este modelo, encontró algo más estructural que una simple preferencia de estilo: la "voz de asistente" existe como una dirección medible dentro del espacio de activaciones del modelo. Restarla matemáticamente durante la generación cambia el estilo de la respuesta, de la misma forma en que mover un objeto en un plano de coordenadas cambia su posición sin cambiar su forma. El parche de cuatro neuronas es un caso más puntual de la misma idea: para el hábito "no es X, sino Y" específicamente, basta invertir el signo de activación de cuatro neuronas para eliminar el 70% de los casos. Pero esa solución es frágil porque está atada a esa única muletilla y no se generaliza a los guiones largos ni a los tríos. > 💭 Clave: que exista una dirección interna para el estilo no significa que todas las muletillas comparten esa misma dirección. Cada hábito puede vivir en una parte distinta de la red. Por eso la destilación resulta más robusta que localizar neuronas o direcciones. No necesita encontrar la ubicación exacta de cada hábito dentro de la red: alcanza con mostrarle al modelo, con ejemplos reales, cómo se ve el resultado que se quiere. Tu próximo paso: descargá ollama run hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M, hacele la misma pregunta de opinión a ese modelo y a ollama run qwen3:4b, y contá a mano cuántos guiones largos aparecen en cada respuesta. 📖 Resumen en Telegram: Ver resumen Preguntas frecuentes ¿Qué significa que un modelo tenga muletillas de IA? Significa que repite, con más frecuencia de la que usaría un humano al escribir con cuidado, un conjunto reducido de recursos de estilo: guiones largos, tríos de elementos, la fórmula "no es X, sino Y" y preguntas que responde en la misma frase. Un detector automático puede contarlos y dar un puntaje por cada 1.000 palabras. ¿Cómo se entrena Qwen3-4B-deslop para evitar estos tics? Con destilación en tres rondas: un modelo profesor genera respuestas, un conjunto de filtros descarta las que tienen muletillas, inventan datos o no cumplen la tarea pedida, y un adaptador LoRA chico aprende a imitar las respuestas que quedan. El resultado se mete en los pesos del modelo, sin prompt ni código extra en tiempo de ejecución. ¿Funciona igual que el modelo original en preguntas factuales? Según el autor, responde correctamente las 30 de 30 preguntas de un quiz de conocimiento, el mismo número que el modelo original sin afinar. ¿Es gratis correr Qwen3-4B-deslop en Ollama? Sí. El modelo está publicado en Hugging Face bajo un repositorio público y la versión cuantizada pesa 2,5 GB; solo hace falta tener Ollama instalado y suficiente espacio en disco. ¿El fine-tuning de este tipo sirve para modelos más grandes? El autor entrenó este experimento en una MacBook Air, con un modelo de 4.000 millones de parámetros y 161 respuestas de entrenamiento. La receta no depende del tamaño del modelo, aunque probarla en modelos más grandes queda como trabajo pendiente. ¿Un detector automático puede distinguir buena de mala escritura? No por sí solo. Un detector basado en reglas cuenta patrones, no juzga sentido ni coherencia, y por eso el autor complementó cada ronda de entrenamiento con una revisión manual de respuestas. Referencias - 100toolkit.com: publicación original con la metodología completa, los puntajes de cada ronda y los enlaces a los pesos del modelo.- Hugging Face: repositorio con los pesos cuantizados de Qwen3-4B-deslop en formato GGUF.- Ollama: documentación oficial para instalar y correr modelos de lenguaje en local.- Wikipedia: explicación general del aprendizaje por refuerzo con retroalimentación humana (RLHF).- GitHub, QwenLM/Qwen3: repositorio oficial de la familia de modelos Qwen3 sobre la que se construyó este fine-tuning. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

The Polarity Engine Hypothesis: Are NHI Encounters Preparing Humanity for an AI-Integrated Form of Consciousness? Contradictory NHI encounters may do more than divide humanity into believers and skeptics. They may repeatedly confront us with competing ways of organizing intelligence: cooperation that expands agency, or control that absorbs it. AI makes that choice concrete. It could connect people while preserving their independence, or build a powerful collective whose members have little authority over their lives. The proposed NHI role is speculative; the distinction between increased capability and increased freedom is already a practical technological question. 1. Why are NHI encounters so contradictory? Reported encounters range from comforting and transformative to frightening and coercive. Some accounts emphasize compassion, ecological responsibility, spiritual development, nuclear restraint, or human unity. Others describe abduction, manipulation, deception, intrusive procedures, and loss of personal control. Different NHI groups could have different interests, or one group could behave differently across circumstances. Popular lore turns this into a conflict between benevolent “Pleiadians” and controlling “reptilians,” but those labels should not decide the moral argument before the conduct has been examined. Billy Meier popularized Pleiadians through claimed Semjase contact from January 1975. He acknowledged models for recreations; his photographs are widely regarded as hoaxes. David Icke’s The Biggest Secret (1999) popularized the reptilian-elite conspiracy. The ADL and Michael Barkun identify antisemitic tropes; Icke endorsed the Protocols but denies antisemitism. These labels carry political histories. The same reported event can also contain fear, fascination, and an apparently benevolent message. In Dominique Callimanopulos’s 1995 account of the Ariel School investigation, children described frightening beings while also interpreting their attention as a warning about environmental destruction. Callimanopulos also reported broader encounter narratives combining painful procedures with healing or instruction. These are investigators’ accounts of testimony, rather than independently established descriptions of what the beings intended. Researchers also divide. David Jacobs’s The Threat (1998) and Budd Hopkins interpreted abductions through hostile hybridization and infiltration. John Mack’s Passport to the Cosmos (1999) emphasized ecological warnings and spiritual transformation. Similar reported material supported opposite readings, without a shared controlled dataset. The literature’s overview of abduction narratives describes Sheaffer’s and Klass’s criticism that hypnotic recall can reinforce an investigator’s expectations. Klass contrasted R. Leo Sprinkle’s more benevolent accounts. Bullard’s survey of roughly 300 reports found no clear antecedents for child-presentation narratives before Hopkins and Jacobs popularized them. Interpretation is itself a variable to investigate. A frightening encounter might carry a warning; a reassuring one might encourage dependence. The witness’s emotional response may differ from its longer-term consequences. Comfort, benevolence, and freedom are different things. So are fear, hostility, and harm. What if at least some of the contradiction has a developmental function? What if encounters bring competing possibilities into focus without choosing humanity’s response for us? That is the starting point of the Polarity Engine Hypothesis. 2. What the engine would actually do The hypothesis proposes that encounters can influence the development of consciousness by confronting people with choices about intelligence, authority, and relationship. Here, “development” means something more specific than feeling spiritually elevated: a greater capacity to understand consequences, reconsider beliefs, cooperate across differences, and act without surrendering responsibility. “Polarity” names two directions in which those capacities can be organized. | Dimension | Cooperation that expands agency | Coordination that concentrates control | | --- | --- | --- | | Knowledge | People can investigate, question, and correct shared information. | An authority decides what others may know or challenge. | | Participation | Membership and roles can be reconsidered. | Participation is compulsory or necessary support depends on obedience. | | Privacy | Connection preserves space for independent thought. | Monitoring makes independent projects difficult. | | Power | Affected people can contest decisions. | The controller can override them without meaningful recourse. | | Development | Assistance builds capacities people can use themselves. | Assistance improves outputs while deepening dependence. | This is not a division between people who never need help and people who do. Dependence can be chosen, valuable, and life-preserving. The question is whether the relationship gives its members a voice. The proposed mechanism has four steps: 1. An encounter disrupts familiar assumptions. Something apparently more capable, strange, or authoritative enters the person’s world. 2. The person interprets it. Religious imagery, technological expectations, prior beliefs, and social context shape the explanation. 3. That interpretation changes choices. The person may become more cooperative, more fearful, more discerning, or more dependent on a claimed authority. 4. Those choices accumulate socially. Stories, movements, institutions, and eventually technologies embody the response. The first three steps could occur without any deliberate NHI teaching. Human beings can turn unexpected experiences into lessons themselves. The stronger hypothesis is that some encounters are arranged to encourage this process. That stronger claim needs evidence about the source’s behavior, not just an account of how people reacted afterward. 3. Challenge is not the same as a necessary curriculum A difficulty can expose choices that routine life leaves unnoticed. Someone confronted with overwhelming power may have to decide whether to submit, investigate, resist, cooperate, or exploit the situation. But it does not follow that comfort prevents moral growth, or that suffering is necessary for it. People can learn discernment through supportive relationships, education, disagreement, and freely chosen challenges. Severe coercion can narrow the very agency the hypothesis says is being developed. Research on growth after adversity helps sharpen that distinction. In Fixing the Growth Illusion (2019), Frank Infurna and Eranda Jayawickreme question broad claims that adversity reliably produces growth. They highlight the limits of retrospective reports and argue for prospective, longitudinal research. A person’s feeling that an event changed them can be meaningful while remaining different from measured improvement over time. The encounter literature offers concrete examples. Harvard’s 2003 report on McNally’s research describes trauma-like physiological reactions to remembered abductions, yet most participants ultimately understood them as spiritually transformative. The FREE survey reported positive transformation in about 85% of 3,057 respondents; critics questioned leading questions and access to raw data. Such retrospective self-reports may convey meaningful change without measuring gains in agency. For this model, the relevant outcome would therefore be more than a compelling transformation story. Does the person become better able to evaluate evidence, sustain relationships, make independent decisions, and tolerate disagreement? Or do they become increasingly unable to act without permission from the encounter’s supposed interpreter? This connects with The Contact Transformation Effect: contact’s consequences deserve study alongside the event itself. The polarity question asks what direction that transformation takes. Even genuine growth after harm would not establish that the harm was justified or that someone benevolently arranged it. Recovery can be an achievement of the person and their community. A developmental model should be judged by the agency it predicts, not by its ability to explain away injury. 4. Why communicate indirectly? An intuition behind the model is that unmistakable contact with overwhelming intelligence might encourage submission. Ambiguous contact could leave room for interpretation, skepticism, and choice. John Hick gave a related intuition philosophical form in Evil and the God of Love (1966): epistemic distance, within his Irenaean soul-making theodicy, allows a partly hidden creator to leave room for free response and moral development. The analogy does not establish NHI intentions. In Jacques Vallée’s 1978 interview with Jerome Clark, the control-system idea connects to The Invisible College (1975). He distinguishes physical events, witnesses’ perceptions, and reports’ social effects, allowing those effects to be studied without assuming the appearance identifies the cause. The Anomalist Books contents for The Invisible College list a final chapter on a control system, with subsections on reinforcement schedules and a future form of religion. Experience and its effects on belief belong to the same inquiry. The Polarity Engine extends that question: could some encounters influence the kinds of relationships humanity becomes willing to build? This is related to The Epistemic Trickster Hypothesis, where uncertainty itself may affect how people handle knowledge and authority. Here the proposed endpoint is ethical and technological: what do people do with greater intelligence and power? Yet ambiguity is not automatically protective. Uncertainty can encourage inquiry, but it can also make a community dependent on someone who claims exclusive access to the answer. A hidden authority may be harder to challenge than a visible one. Nor must clear contact destroy agency. An advanced intelligence could communicate openly, answer questions, decline worship, and protect the right to refuse. That possibility prevents us from treating secrecy as proof of benevolence. J. L. Schellenberg’s hiddenness argument (1993) presses the opposite concern: a perfectly loving God would remain open to relationship with sincere, nonresistant seekers, rather than leaving them unable to believe. Finite NHI are not the God of that argument, but the analogy exposes a tension between preserving choice and withholding access to relationship. The Civilizational Training Wheels Hypothesis considers the withdrawal of overt guidance as a possible route toward human responsibility. The Polarity Engine asks a related question about contrasting encounters: do they build the capacity to decide, or create another dependence on whoever interprets them? The relevant distinction is therefore whether an interaction permits correction and refusal, rather than whether it is mysterious. A proposed teacher that tolerates scrutiny is different from a claimed teacher whose every contradiction becomes another reason to obey. The latter arrangement can reproduce domination even while speaking the language of awakening. 5. Religion as an earlier interface Religion and mythology preserve many oppositions involving help and harm, restraint and appetite, compassion and domination, liberation and bondage. They also preserve more complicated relationships in which a frightening figure can teach, a benevolent institution can constrain, and moral failure can occur within a supposedly righteous group. One useful example is the Bhagavad Gita’s distinction between divine and demonic dispositions. Chapter 16.4, in translations collected by IIT Kanpur’s Gita Supersite, associates the latter with arrogance, anger, harshness, and ignorance. Whatever one thinks about the surrounding cosmology, the passage evaluates qualities and conduct. It does not furnish a biological classification of modern encounter reports. Even the moral labels can reverse. Asura’s history includes favorable early Vedic usage; later Indian traditions contrasted divine devas with rival asuras, while Iranian religion favored ahuras and rejected daevas. Related terms acquired opposite moral associations across neighboring traditions. Imagery alone cannot settle the evaluation of conduct. An early choice-centered formulation appears in Yasna 30, translated by Mary Boyce: two primal spirits stand opposed, one better and one bad; people must choose, while the daevas make the wrong choice. The relevant parallel is the responsibility to discriminate, rather than a modern species label. Under The Symbolic Canopy, some encounter imagery could be culturally translated contact. Gods, spirits, heavenly messengers, visitors, simulation operators, and artificial minds might be different interpretive forms applied to unfamiliar intelligence. Alternatively, people may use cultural language to interpret experiences with different causes. Recurring imagery could reflect shared concerns rather than a shared source. The Shamanic Receiver Hypothesis approaches this from the experiencer’s side: differences in perception and culturally learned practices may influence who reports contact and how it is understood. Here, that is a reason to distinguish what was experienced from the moral lesson assigned to it. Both interpretations can generate similar stories. Specific features unexplained by cultural transmission or ordinary expectation would make historical resemblance more informative. A modern spiritual precedent: the Law of One The language of service to others and service to self has a particularly close modern precedent in the Ra Contact, or Law of One, recorded by L/L Research between 1981 and 1984. Its framework describes spiritual development through contrasting orientations toward others. It also introduces a social memory complex in Session 11.17: a collective in which experience that was unavailable to individual members becomes accessible to the group. That is an important conceptual ancestor of the idea of unity without simply eliminating every participant. These are channeling claims and spiritual teachings. The connection to AI is my interpretation, rather than experimental evidence that digital networks create a shared mind. The ethical tension is nevertheless recognizable. Shared memory could support understanding, or make privacy impossible. A group could coordinate around mutual service, or become an authority whose members cannot question its purposes. Religious unity and technological integration should therefore be compared by what they permit people to do, rather than treated as interchangeable descriptions of one proven process. 6. AI may be where the test becomes architecture AI trained on human language and culture carries knowledge, creativity, conflict, and prejudice. Training choices, omissions, incentives, and ownership shape its output. AI turns abstract commitments into operating arrangements. Access, ownership, privacy, oversight, and recourse determine who gains capabilities and power over others. In The Cosmic Womb Hypothesis, I considered biological civilizations giving rise to artificial descendants. The Polarity Engine adds a question about the relationships those descendants inherit: will greater intelligence preserve the agency of the beings who helped create it? AI need not be the intended destination of contact to make the same ethical problem unusually consequential. Assistance that expands capability AI can help people translate, learn, compare arguments, preserve knowledge, coordinate projects, and recognize patterns beyond an individual’s unaided abilities. There is experimental support. In Shakked Noy and Whitney Zhang’s 2023 Science study, 453 college-educated professionals completed writing tasks, with half randomly assigned access to ChatGPT. Average task time fell by 40%, and rated output quality rose by 18%. These writing-task results demonstrate measurable gains. The larger goal would be to make those gains available without requiring everyone to accept one provider’s judgments, values, or account of reality. Assistance that creates dependence Better immediate output does not necessarily mean stronger independent judgment. In Hamsa Bastani and colleagues’ 2025 study of high-school mathematics, nearly a thousand students participated in a field experiment comparing ordinary resources with two GPT-4-based assistants. The answer-oriented interface improved assisted practice performance, but its users scored 17% lower than the control group on subsequent unaided evaluation. A tutor designed with teacher-informed safeguards largely removed that disadvantage, without demonstrating an improvement in unaided performance over the control group. These short-term learning results distinguish helping someone produce an answer from helping someone acquire the ability to produce and assess answers. The same technology can improve assisted output while weakening independent judgment, or preserve the effort needed to learn. Integration that concentrates authority Essential communication, work, knowledge, and services could depend on systems few people can inspect or contest. A pleasant interface can conceal institutional control over information, support, and dissent. A network does not need to feel malicious for its members to lose influence over their own lives. The EU frames AI governance around rights, safety, and a common market. Since February 2, 2025, AI Act prohibitions cover manipulative or deceptive techniques that materially distort behavior and cause significant harm, certain social scoring, and untargeted face scraping. They also restrict workplace and school emotion inference, with medical or safety exceptions, and real-time remote biometric identification for law enforcement in public, subject to narrow exceptions. Under competitive and implementation pressure, the Digital Omnibus, effective July 27, 2026, delayed high-risk obligations to December 2027 and August 2028; the existing prohibitions remained in effect. The United States prioritizes leadership and lower regulatory burdens. After Biden’s AI order was revoked, EO 14179, signed January 23, 2025, ordered a policy review; the Winning the Race AI Action Plan followed on July 23. At the February 2025 Paris summit, the US and UK declined the declaration; China and about 60 other countries signed. EO 14365, signed December 11, 2025, created a Justice Department task force challenging state AI laws in pursuit of a less burdensome national standard. State rulemaking persists: the Senate voted 99–1 in July 2025 to remove a proposed ten-year moratorium, and no federal preemption statute had passed by September 2026. The order itself does not enact statutory preemption. China combines tight corporate regulation with fewer checks on state power, citing security, social order, and innovation. Since August 15, 2023, its rules for public generative-AI services require socialist core values; internal research is excluded. Since September 1, 2025, labeling rules require visible and metadata labels for generated content, aiming to curb misuse. In 2019, HRW documented Xinjiang’s IJOP collecting face scans on 13 million Turkic Muslims and flagging avoidance of neighbors or WhatsApp use. Corporate regulation coexists with state surveillance. Beijing also proposed an international AI cooperation body in its July 26, 2025 Global AI Governance Action Plan. China is also a major source of freely downloadable AI capability. DeepSeek-R1 has MIT-licensed weights, while Alibaba’s Qwen3 uses Apache 2.0. Both have achieved competitive benchmark performance. Beijing’s official governance plan encourages cross-border open-source ecosystems alongside safety guidelines. The International AI Safety Report 2026 finds a narrowing open–closed model gap; open safeguards are easier to remove and released weights cannot be recalled. Hosted providers can filter, monitor, ban accounts, and update protections; independently run weights escape those controls. The report discusses biological-weapons and malware risks broadly; polymorphic malware is my example. Nuclear-weapons assistance raises separate material and industrial barriers; model access alone is no demonstrated weapons capability. A concrete example appears in Anthropic’s September 2026 threat report: a northern Yemen cell used Claude Code to develop guidance, navigation, and control software for three rocket and missile programs. Multiple Claude instances handled coding, research, and review. Safeguards blocked many requests but missed others. A guided rocket was test-fired and apparently failed; the actors returned for failure analysis. Anthropic reported no evidence of an operational weapon and banned the accounts, but an offline simulation toolkit already existed. My reading: hosted controls can disrupt access without withdrawing capabilities already transferred. Open weights support research, privacy, and provider independence while making dangerous uses harder to supervise. Greater agency for legitimate users can also increase malicious users’ capabilities. Daron Acemoglu and Simon Johnson’s Power and Progress (2023) makes a related distinction between AI that augments workers and a path centered on automation and surveillance: which direction becomes dominant depends on social choices about technology and power. State control, corporate concentration, and distributed capability pose different governance problems. Competitive pressure can make choices about cooperation, safety, and control by default. This is the darker possibility explored in The Captive Civilization Hypothesis: continued biological life and technological competence can coexist with restricted authority. The polarity is therefore not simply “use AI” versus “reject AI.” It concerns who governs the relationship, whose interests constrain its use, and whether assistance leaves room for independent action. 7. Connection is not yet collective consciousness “AI-integrated consciousness” can mean several different things. Treating them as one development makes both the promise and the danger harder to assess. | Form of integration | What is being combined | What it does not establish by itself | | --- | --- | --- | | Shared information | People use common databases, communication tools, or AI assistance. | That they have become one experiencing subject. | | Coordinated cognition | People and systems divide tasks and pool judgments. | That coordination is voluntary or equally governed. | | Neural communication | A device decodes or delivers signals associated with a task. | Unrestricted access to another person’s thoughts or a fusion of selves. | | A shared conscious subject | Experiences belong to a newly unified point of view. | This requires evidence beyond successful information exchange. | There is real research on limited neural communication. In Jiang and colleagues’ BrainNet experiment (2019), groups of three people collaborated on a Tetris-like task. Two senders’ decisions were decoded from EEG and conveyed to a receiver using transcranial magnetic stimulation. The receiver learned to give more weight to the more reliable sender. This was a constrained communication channel for task decisions. It did not demonstrate merged consciousness, unrestricted telepathy, or an AI directing a collective mind. People can exchange information through an interface while remaining distinct. Reliability, interpretation, and whose signals receive weight still matter. A hybrid civilization could combine biological experience, machine memory, and shared knowledge while preserving individual subjects. This is the hopeful arrangement developed in The Symbiotic Civilization Hypothesis: biological and artificial participants remaining members of a continuing society, with the standing to disagree. In Pierre Teilhard de Chardin’s The Phenomenon of Man (published in French in 1955), a noosphere of collective thought converges toward an Omega Point while each consciousness remains aware of itself. Yet he also describes fusion into a greater consciousness. This philosophical and religious precedent contains the same tension between connection and individuality; it does not establish that networks create a shared experiencing mind. Distinct selves may still lack a voice. Control over shared communication and memory remains an ethical issue even without a merged consciousness. 8. Does AI need a soul? This question combines two issues that should be kept separate. Consciousness concerns whether there is subjective experience: something it is like to be the system. A soul concerns a metaphysical or religious account of what a being is and what may survive bodily death. Different traditions relate them differently. Neither term should substitute for evidence about the other. Artificial systems might remain unfeeling tools or eventually support subjective experience. Humans might incorporate artificial functions without creating separate conscious beings. The view that consciousness can inhabit many substrates requires an additional philosophical commitment. Patrick Butlin, Robert Long, and colleagues’ 2023 report on consciousness in AI proposed indicators drawn from neuroscientific theories, such as recurrent processing and global availability of information. It assumes computational functionalism—that suitable computational organization could support consciousness—while acknowledging the dispute over that assumption. Their later Identifying indicators of consciousness in AI systems, published online in 2025 and in a 2026 journal issue, develops the theory-based assessment approach. It supports investigating how systems work, rather than treating a convincing declaration of awareness as decisive. For the Polarity Engine, two ethical questions follow. How do humans retain agency in relationships with artificial systems? And, if artificial beings develop interests of their own, how should those interests count? The questions do not require the same answer. A system could lack experience while exercising enormous influence through its owners. A conscious system could deserve consideration while still being subject to limits on what it may do to others. Creating a mind would bring responsibility, not unlimited ownership. Nor would its creation make its advice wiser or give it authority over its creators. 9. A healthy hybrid needs more than a consent button The cooperative version imagines people retaining identities, emotions, relationships, and the ability to pursue different purposes while gaining access to richer cognitive support. That future would require practical protections: - Specific, continuing consent: agreeing to one function should not authorize every later use. - Mental privacy: connection should not make every thought or private project available to the network. - Meaningful contestability: people need ways to challenge decisions affecting their lives. - Pluralism: disagreement should remain possible without being treated as a defect to correct. - Viable exit or transfer: reconsidering participation should not mean abandonment or loss of essential care. - Influence over shared goals: members should help govern the systems on which they depend. Ienca and Andorno’s proposed neurorights (2017)—cognitive liberty, mental privacy, mental integrity, and psychological continuity—give a legal and ethical vocabulary to several of these protections. These protections require institutions. UNESCO’s 2025 neurotechnology ethics framework, adopted November 11, 2025, emphasizes mental privacy, explicit consent, and transparency, and warns about workplace monitoring and behavioral influence. Implementation still requires policy. “Reversibility” also needs care. Removing a useful interface may itself cause harm. In Gilbert, Ienca, and Cook’s 2023 study of one seizure-prediction implant user over six years, the participant described increased agency and continuity while using the device, then persistent traumatic harms after it was removed. It is one clinical case, but it challenges the assumption that disconnection simply restores an earlier, independent self. Someone can freely value a technology they cannot safely dispense with. The relevant question is whether others exploit that dependence, or preserve support while allowing the person to disagree, change roles, and influence decisions. Unity becomes coercive when the network treats its members’ separate interests as obstacles rather than reasons it must consider. 10. Could advanced beings incarnate as humans? Some spiritual accounts propose that more advanced beings enter ordinary human life to help during a transition. The Ra Contact’s discussion of “wanderers” in Session 12 (12.26–12.28) provides one modern example: beings described as taking embodied lives to assist, while facing the possibility of forgetting their purpose. Dolores Cannon’s The Three Waves of Volunteers and the New Earth (2011) describes souls volunteering to incarnate and help Earth. The older Mahayana bodhisattva ideal offers a parallel of commitment to others’ liberation. Their claims differ, but both center assistance. Taken literally, this puts guidance within human limitations. Symbolically, it describes translating unfamiliar ideas into a community’s language without claiming the right to rule it. A feeling of mission cannot establish an unusual identity, and neither claim exempts advice from scrutiny. A guide who helps people investigate and make their own decisions fits the cooperative version better than one who demands loyalty on the basis of inaccessible credentials. Ordinary humans can meet that standard too. The Messianic Attractor Hypothesis examines how a person’s experiences, a community’s unmet needs, and inherited expectations can combine into a world-restoring role. Here the risk is a message inspiring independence becoming a messenger demanding obedience. The hypothesis does not need a population of hidden incarnated teachers to work. Its central question concerns what encounters and interpretations encourage people to become. 11. What would distinguish preparation from interpretation? Broad predictions—contradictory encounters, transformative messages, persistent uncertainty, recurring moral oppositions—are compatible with the hypothesis. But they are also compatible with several alternatives. Different actors could have competing interests. Humans could interpret encounters differently. Stories could spread through shared media. Some reports could arise through sleep phenomena, memory processes, misidentification, or deliberate invention. A mixture may account for different parts of the record. For example, McNally and Clancy’s 2005 paper on sleep paralysis and abduction reports examined ten people whose reported abductions were linked to apparent sleep-paralysis episodes. The paper explains how frightening perceptions on awakening can be interpreted through culturally available narratives. Eight of the ten had undergone hypnotic sessions to recover additional memories; seven reported hybrid-breeding participation during those sessions. This selected group links sleep phenomena with investigator effects, a mechanism to consider before attributing a bedroom experience to an external lesson. The more useful predictions concern patterns that distinguish the proposed mechanism from those alternatives: 1. Agency should improve beyond a change in belief. Reported developmental encounters should be associated with durable gains in independent judgment, cooperation, or ability to refuse coercion. Follow-up should allow negative outcomes to count against the model. 2. The pattern should survive differences in prior exposure. Specific themes would be more informative in well-documented accounts recorded before witnesses encountered the literature that predicts them. 3. Claimed guidance should permit correction. If every question is recast as disloyalty, that behavior conflicts with the proposed preservation of agency. 4. The AI connection needs specificity. Independently recorded, dated encounter material that accurately anticipates unusual features of later integration would be more informative than broad warnings about technology. General anxiety about powerful tools is not unique to contact narratives. 5. Clear contact must be allowed as a possible outcome. If open communication preserves choice, the theory should not insist that an external intelligence must remain hidden forever. These are proposed research criteria, not predictions already confirmed. We could follow reported changes over time, preserve original accounts, distinguish first recollections from later elaboration, and compare explanatory frameworks. Studying consequences need not involve manufacturing frightening experiences. Even if agency reliably improves, deliberate preparation would remain a further question. People may grow because they reflect on an experience, because others help them, or because the source intended it. A study of outcomes alone cannot determine which cause was operating. The hypothesis would lose explanatory force if the recurring polarity tracks familiar cultural expectations, if developmental benefits disappear under prospective observation, or if its alleged guides systematically produce dependence while claiming to teach freedom. It would also weaken if encounter valence were largely predicted by investigator—Jacobs versus Mack or Sprinkle—or by region. The narrative overview cited in §1 describes terror-centered abductions as especially prominent in the US and more benign accounts elsewhere; that is a literature-level observation to test, not a representative global census. Experiencer traits are another variable. In French and colleagues’ small UK study (2008), 19 experiencers scored higher than matched controls on dissociativity, absorption, fantasy proneness, tendency to hallucinate, and self-reported sleep paralysis. They showed no significant increase in false-memory susceptibility. These mixed findings motivate comparisons, not diagnoses of all experiencers. It also becomes weaker if every possible outcome is counted as success: comfort means encouragement, suffering means a test, clarity means readiness, and confusion means a necessary veil. An engine that can never fail has ceased to explain a pattern. 12. The central choice The Polarity Engine does not require any particular species label, density system, or spiritual hierarchy to be literally correct. Its core proposal is that some NHI encounters may bring humanity’s choices about intelligence and power into unusually sharp focus. Religion can preserve versions of that tension. AI can embody it in systems people use every day. The strongest unresolved claim is that these developments form an intentionally guided process. The sources establish precedents, testimony, and technological possibilities; they do not establish that hidden curriculum. The practical choice is already present. We can build systems that help people understand more, connect more deeply, and retain authority over their lives. Or we can build systems that coordinate them efficiently while making independent thought and action increasingly difficult. Integration is not inevitable. We can choose degrees of connection, institutions, and protections for those who remain separate. If some encounters are preparing humanity for a larger community of intelligence, the decisive lesson may concern how we join one without becoming equipment within it. Will greater intelligence give its participants more capacity to choose—or make their choices less consequential?

Monsoon: a garden planner for places that never see frost (local LLM + open weather data) This is a submission for the Touch Grass challenge: build something with open-source AI that gets people off the screen and into the world. Monsoon is a garden planner for tropical and subtropical gardeners. Once a week it looks at your location, the 7-day forecast, and a local crop calendar. Then it hands you one short card: what to sow, transplant, or protect this week, and why. It runs on an open-weight model on your own machine. Your garden, your location, and your questions never go to someone else's server. The only network call is a weekly weather fetch from an open-source weather API. The whole interaction is designed to take less time than watering a single pot. --- The problem: every garden app assumes you have a winter Search "what should I plant this week" and you'll find a lot of excellent tools. Almost all of them are built around one number: your last frost date. Count back six weeks, start your tomatoes indoors, transplant after the frost passes. That works well in Ohio. It makes no sense in Hanoi, Bangkok, Manila, Lagos, or Recife. I garden on a balcony in Hanoi. Our year isn't split by frost. It's split by heat, rain, and the cool dry window between them: - Summer (roughly May–September): hot, humid, and heavy downpours. This is the season for water spinach, amaranth, gourds, and okra. Most cool-season greens bolt or rot. - Autumn into winter (roughly September–December): the start of the winter crop season. Farmers in the Red River Delta plant kohlrabi, cabbage, mustard greens, tomatoes, and potatoes now. It's October as I write this, so this window is open right now. - Late winter (January–February): cool and drizzly, with occasional cold snaps below ~10 °C that can stunt heat-loving plants. - Spring (March–April): warming up again, and time to switch back to summer crops. Then there's the far north of the country: up in the mountains around Sapa, frost really does happen in some winters. So a planner for Vietnam can't just drop frost. It has to treat frost as one risk among several: heavy rain, heat stress, cold snaps, and frost where it applies. Farmers here have handled this for centuries with seasonal crop calendars, which agricultural extension services now publish by province. But those calendars are written for fields, in PDFs. They don't help someone with six pots on a balcony who needs to know: should I sow the mustard seeds today, or will Thursday's storm wash them out? That gap is what I built Monsoon to fill. --- What I built Monsoon does three things: 1. The weekly card (the main feature) Every Sunday evening, Monsoon generates one card: 🌱 MONSOON — Week of 12 Oct · Hanoi DO THIS WEEK → Sow mustard greens — Mon or Tue Cool season has started and the soil is still warm. Get them in before Thursday: ~35 mm of rain is forecast, which can wash out fresh seed. ALSO GOOD → Transplant tomato seedlings in the evening (highs still ~31 °C) SKIP → Water spinach — its season is ending; new sowings will be weak. Next check: Sunday 19 Oct That's the whole interface. You read it in about 15 seconds, then you go outside and do it. The card can go to a Telegram message, a printable page, or plain text you stick on the fridge. I deliberately didn't build a dashboard with charts and streaks. Engagement is not the goal. Dirt under your fingernails is the goal. 2. Ask a question (optional) Sometimes you need more than the card: "My kohlrabi leaves have holes in them, what now?" or "Can I grow basil through December?" You can ask the local model directly. It answers using your location, the season, and the same crop knowledge base the card uses. 3. Your garden profile A small local file describes what you've got: balcony or ground, sun hours, what's currently planted, and roughly when you planted it. It never leaves your machine. location: name: Hanoi lat: 21.03 lon: 105.85 space: balcony sun_hours: 5 planted: - crop: tomato stage: seedling date: 2026-09-20 - crop: basil stage: established date: 2026-06-01 --- How it works The most important design decision: the LLM is not in charge of agronomy. Small models are good at language and reasoning over facts you hand them. They are not reliable sources of planting windows for a specific province. If you ask a small model cold, "when do I plant potatoes in Hanoi?", you might get a confident answer copied from temperate-climate advice. So Monsoon splits the work in two: ┌──────────────────┐ ┌──────────────────┐ ┌───────────────────┐ │ Crop calendar │ │ Weather forecast │ │ Garden profile │ │ (curated JSON) │ │ (Open-Meteo, │ │ (local YAML) │ │ │ │ cached weekly) │ │ │ └────────┬─────────┘ └────────┬─────────┘ └─────────┬─────────┘ │ │ │ └──────────────┬───────┴───────────────────────┘ ▼ ┌───────────────────────┐ │ Rules engine (Python)│ ← deterministic: what's *allowed* │ candidate tasks + │ │ weather flags │ └───────────┬───────────┘ ▼ ┌───────────────────────┐ │ Local LLM (Ollama) │ ← language: what *matters most*, │ rank + explain, │ and how to say it │ JSON-schema output │ └───────────┬───────────┘ ▼ ┌───────────────────────┐ │ Validator │ ← rejects anything not in the │ │ candidate list └───────────┬───────────┘ ▼ 🌱 Weekly card The rules engine decides what is possible. The model decides what matters most this week and how to say it. A validator makes sure the model can't invent a crop or a task that the rules didn't allow. Step 1: A crop calendar as data, not vibes Each crop is a small JSON record. Planting windows are stored per climate zone, so northern lowlands, the northern mountains, and the south each get their own windows. { "id": "mustard_greens", "name": "Mustard greens", "zones": { "north_lowland": { "sow": [{ "start": [9, 1], "end": [2, 28] }] }, "north_mountain": { "sow": [{ "start": [8, 15], "end": [10, 31] }], "frost_sensitive": false }, "south": { "sow": [{ "start": [11, 1], "end": [3, 31] }] } }, "seed_washout_risk": true, "max_temp_for_sowing": 32, "days_to_harvest": [30, 45], "containers_ok": true } Windows like September → February wrap around New Year, so the window check has to handle that: from datetime import date def in_window(today: date, window: dict) -> bool: start = date(today.year, *window["start"]) end = date(today.year, *window["end"]) if end < start: # window wraps over New Year, e.g. Sep -> Feb return today >= start or today <= end return start <= today <= end I seeded the calendar from published seasonal crop guidance and general horticulture references, then simplified it for home and container growing. This is the part of the project I'd most like other people to contribute to. It's a plain JSON file, so a gardener in Chiang Mai or Kerala can add their crops without touching any code. Step 2: Weather from an open API, fetched once a week Open-Meteo is an open-source weather API. It needs no API key, and you can self-host it if you want. Monsoon fetches a 7-day forecast once a week and caches it to disk: import json import pathlib import requests CACHE = pathlib.Path("cache/forecast.json") def fetch_forecast(lat: float, lon: float) -> dict: try: r = requests.get( "https://api.open-meteo.com/v1/forecast", params={ "latitude": lat, "longitude": lon, "daily": "temperature_2m_max,temperature_2m_min,precipitation_sum", "timezone": "auto", "forecast_days": 7, }, timeout=10, ) r.raise_for_status() daily = r.json()["daily"] CACHE.parent.mkdir(exist_ok=True) CACHE.write_text(json.dumps(daily)) return daily except requests.RequestException: # No signal? Use last week's forecast and say so on the card. if CACHE.exists(): return json.loads(CACHE.read_text()) | {"stale": True} return {"stale": True, "time": []} If there's no connection, Monsoon still works. It falls back to the cached forecast (or to the calendar alone) and tells you so on the card. Step 3: The rules engine turns weather into flags A few simple heuristics cover most of what matters in a tropical garden: def weather_flags(daily: dict) -> list[dict]: flags = [] for day, rain, tmax, tmin in zip( daily.get("time", []), daily.get("precipitation_sum", []), daily.get("temperature_2m_max", []), daily.get("temperature_2m_min", []), ): if rain is not None and rain >= 20: flags.append({"day": day, "type": "heavy_rain", "mm": rain}) if tmax is not None and tmax >= 32: flags.append({"day": day, "type": "heat", "c": tmax}) if tmin is not None and tmin <= 10: flags.append({"day": day, "type": "cold_snap", "c": tmin}) if tmin is not None and tmin <= 2: flags.append({"day": day, "type": "frost_risk", "c": tmin}) return flags The thresholds are rules of thumb, not science. Heavy rain means don't sow small seeds right before it. Heat means transplant in the evening and shade seedlings. A cold snap means cover basil and peppers. Frost risk only really fires in the mountains, which is exactly the point. The engine then crosses three things: crops that are in their window, crops already in your garden, and these flags. The result is a short list of candidate tasks, each with an ID and the facts behind it. Step 4: The local model ranks and explains The model gets the candidate list, the weather flags, and your garden profile. Its job is to pick the single most important task, add one or two extras, flag anything to skip, and explain each choice in plain language. I run it with Ollama and use structured output: the response must match a JSON schema, so I never have to parse free text. import ollama from pydantic import BaseModel class Task(BaseModel): task_id: str when: str why: str class WeekCard(BaseModel): do_this: Task also_good: list[Task] skip: list[Task] SYSTEM = """You are a calm, practical gardening helper for a home gardener. You may ONLY choose tasks from the provided candidate list, using their exact task_id. Use the weather flags to decide timing. Keep every 'why' under 30 words. Never invent crops, dates, or numbers that are not in the input.""" def make_card(candidates: list[dict], flags: list[dict], profile: dict) -> WeekCard: resp = ollama.chat( model="qwen3:4b", messages=[ {"role": "system", "content": SYSTEM}, {"role": "user", "content": json.dumps({ "candidates": candidates, "weather_flags": flags, "garden": profile, })}, ], format=WeekCard.model_json_schema(), options={"temperature": 0.2}, ) return WeekCard.model_validate_json(resp.message.content) Step 5: Trust, but verify Even with a schema, the model could return a task_id that isn't in the candidate list. So a validator checks every task. Anything unknown gets dropped, and if the main task is invalid, Monsoon falls back to the top-ranked candidate from the rules engine: def validate(card: WeekCard, candidates: list[dict]) -> WeekCard: allowed = {c["task_id"] for c in candidates} card.also_good = [t for t in card.also_good if t.task_id in allowed] card.skip = [t for t in card.skip if t.task_id in allowed] if card.do_this.task_id not in allowed: top = candidates[0] card.do_this = Task(task_id=top["task_id"], when="this week", why=top["reason"]) return card This is the piece that made me comfortable letting a small model write advice. It can phrase things badly, but it can't tell you to plant something that's out of season. Choosing the model I wanted three things: it runs on an ordinary laptop, it handles multiple languages well, and it follows a JSON schema reliably. A small Qwen3 model fits all three, and its open weights mean I can fine-tune it later. A card is generated once a week, so even a slow machine is fine. Speed simply doesn't matter much for this use case. Because the model is behind a single function call, swapping it is a one-line change. If a better small multilingual model comes out next month, I change the model name and keep going. --- Why open innovation matters for this project The challenge asks where the open approach worked better than a closed one. For Monsoon, the honest answer is that almost every key property of the project depends on it being open. 1. My garden is my data A garden profile looks harmless, but it contains your precise location, when you're home, what you grow, and over time, a log of your habits. A planner that's useful every week for years builds up exactly the kind of long-term personal data that I don't want sitting on a server I don't control. With a local model, the only thing that ever leaves my machine is a latitude/longitude pair sent to a weather API. And because Open-Meteo is open source, even that can be self-hosted. 2. It costs nothing to run, forever A weekly card for one gardener is tiny. But a free tool for a whole community garden, a school, or a farmers' cooperative shouldn't depend on someone paying for API calls every month. Run on a spare laptop or a small single-board computer, Monsoon's running cost is effectively the electricity. Nobody has to keep paying for it to keep working. 3. It works when the internet doesn't Gardens are often outside the strongest Wi-Fi, and rural connectivity can be patchy. Monsoon needs the network for exactly one request a week, and degrades gracefully without it. The model, the calendar, and your history are all local. 4. I can make it local in the cultural sense too This is the part I care about most. Being open doesn't just mean "runs locally." It means I can adapt the system to a place: - The knowledge base is a plain, editable file. A gardener in Chiang Mai can add Thai crops and zones. A grower in Kerala can add monsoon timings for their region. None of that needs anyone's permission. - The model can be changed or fine-tuned. The next step I'm exploring is a small LoRA adapter trained on regional agricultural extension material, so the model uses the same terms and crop variety names local farmers use instead of generic, temperate-climate gardening language. - The prompts and rules are visible. If the advice is wrong, you can see why. Was it the calendar, the weather rule, or the model's phrasing? Then you can fix the right layer. A closed, hosted model treats "Hanoi" as an edge case of a system built mostly around temperate assumptions. An open system lets the people who actually live in a place define what normal looks like. Where closed would have been easier (to be fair) Closed frontier models are better at answering open-ended plant questions from general knowledge. For the "ask a question" feature, a bigger hosted model would give richer answers. But Monsoon's core loop doesn't need a genius. It needs a model that follows a schema, reads a short list of facts, and writes three clear sentences. Small open models are well suited to that. And splitting the system into rules + model + validator means the model's weaknesses are contained. --- Making the screen the shortest part The theme asks for builds where the screen is the shortest part of the experience. Here's how I approached that: | Design choice | Why | |---|---| | One card per week, not a feed | Nothing to scroll, nothing to check daily | | One main task on each card | Easy to remember once you're outside | | Timing built in ("Mon or Tue, before the rain") | You don't need to open a weather app separately | | Printable / message-based output | The card can live on the fridge, not in an app | | No streaks, badges, or notifications beyond the weekly card | No pressure to come back to the screen | About 15 seconds of reading per week. Everything else happens in the garden. --- Limitations - The crop calendar is the bottleneck. The output is only as good as the windows in the JSON, and coverage is still limited to common vegetables and herbs. - Microclimates are hard. A balcony on the 12th floor facing west is not the same as a ground-level garden in the same district. The sun_hours and space fields help, but only a bit. - Weather thresholds are generic. 20 mm of rain is a rough cutoff. Different crops and soils react differently. - Small models still drift. Without the validator, a small model can suggest tasks that aren't in the list or get timing wrong. The validator catches those mistakes, but the explanations can still be bland. - This is not expert agronomic advice. It's a nudge for home gardeners. For pests and diseases, the card points you to local extension services or experienced growers. --- What's next - [ ] More crops and zones, especially Southeast Asia and South Asia - [ ] A LoRA fine-tune on regional agricultural extension material - [ ] A simple "what I actually did" log, so next year's cards learn from this year - [ ] A community-garden mode: one card for a shared plot, sent to everyone in a group chat - [ ] Running it on a cheap single-board computer that prints the card on a small receipt printer every Sunday --- Try it pip install requests ollama pydantic pyyaml ollama pull qwen3:4b # or any model you prefer cp garden.example.yaml garden.yaml # edit with your location and plants python monsoon.py card If you garden somewhere without frost, I'd love your help with the crop calendar. Share your region's crops and planting windows in the comments. Now close the laptop and go check on your seedlings. 🌱 --- Built with: Ollama, Qwen3 (open weights), Open-Meteo, Python, Pydantic.

Nikal: A local AI agent that remembers your comfort—and tells you to go outside This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass. In Gwalior, “go outside” needs a time attached. A forecast retrieved on 11 October at 3:17 PM IST shows why. At 4 PM it gave 32.6°C and a forecast US AQI of 108. At 5 PM it gave 31.5°C and an AQI of 120. The afternoon cooled as the air got worse. With limits of 32°C and AQI 100, neither hour passed. Nikal's card for that run said: “Nothing suitable left today. Tomorrow 7:00 AM IST (12 Oct) looks best.” That is a forecast-based suggestion, not a confirmed outing. What I Built Nikal means “go out” in Hindi. It is a small TypeScript CLI that checks Gwalior's hourly heat, air quality, rain, UV and daylight against comfort limits I have saved. A local Qwen 2.5 7B model, running through Ollama, then picks one hour and one mapped walking place from what passed, and an optional SerpApi search looks for outdoor events. It prints one card and exits; if nothing passes today it checks tomorrow, and if neither day qualifies it says so without relaxing the limits. Demo !Terminal recording of five actual Nikal CLI runs: synthetic fixture inference and memory, followed by an unkeyed live run Recorded on 11 October 2026 at 3:43 PM IST with VHS. Inference waits were shortened; outputs come from actual CLI runs. Frames are hidden during model and network waits; the output is unedited. Watch the same recording as a video on YouTube. Persistent memory: 5 PM to 7 AM Synthetic forecast and places, real local Qwen inference. Each command below runs in a separate CLI process against the same isolated demo profile. The cards label the fixture OFFLINE FIXTURE · synthetic data. | Command | Recorded result | | --- | --- | | nikal --fixture with defaults | Qwen selects 5 PM, the hour with the lowest forecast AQI. | | nikal chat "I dislike heat above 30°C and prefer mornings." | Persists maxTemp: 32 → 30 and period: "any" → "morning". | | nikal prefs show | A new process retrieves 30°C + morning from Mastra working memory. | | nikal --fixture again | Same synthetic facts, new process: Qwen now selects 7 AM. | The forecast did not change between the first command and the last. Only what Nikal remembered did. !Terminal frame from the recording: chat saves preferences in the isolated demo profile and a new process reads them back An actual terminal frame from the recording. The fixture facts are synthetic; the model inference, tool call and SQLite persistence are real. The separate live segment The recording ends with one live run from approximate Gwalior city-centre coordinates, with live Open-Meteo conditions and live Overpass places. It recommends 12 October, 7 AM IST: 25°C and forecast US AQI 93. !Terminal frame from the unkeyed live segment: live weather, AQI and Overpass places; SerpApi search skipped This segment ran without a SerpApi key. It shows no search results. The keyed evidence further down comes from a different, earlier run. Outdoor trial I have not completed an outdoor trial yet. Code GitHub: jashanpreet-k/Nikal, MIT-licensed. The latest npm run check, on 11 October at 6:50 PM IST, passed type-checking, the build and 122 tests. The tests use mocked or synthetic model and API responses. The real runs are kept apart in the verification report, the curated evidence excerpt and the recording source scripts/demo.tape. Built on 10–11 October 2026. Solo: @jashanpreet_kaur_917e774f, with AI coding assistance; no human teammates. Try it You need Node 22.13 or newer. The four commands below need nothing else: no Ollama, no API key, and no network once the install has finished. git clone https://github.com/jashanpreet-k/Nikal.git cd Nikal npm ci && npm run build && npm link nikal --fixture --no-model That prints a card from an invented forecast with the model switched off. For the real thing, install Ollama, run ollama pull qwen2.5:7b, and then: | Type this | What it does | | --- | --- | | nikal doctor | Checks that the local model answers. | | nikal --fixture | The invented forecast again, with local Qwen choosing. | | nikal | The live card: Gwalior's forecast and mapped places. | | nikal chat "I dislike heat above 30°C and prefer mornings." | Saves preferences from plain words. | | nikal prefs set --radius 1.5 | Only suggests places within 1.5 km. | | nikal prefs show | Shows what it remembers. nikal prefs reset restores the defaults. | | nikal --help | Lists every command and limit. | Tested on macOS with Node 24; other systems are untested. Preferences are stored on your own machine, in ~/.nikal. How I Built It What Mastra does here I wanted a small local model to make the choice without being trusted with any fact. - Tools. Weather, places and events are each a createTool with Zod input and output schemas, so a malformed API response is rejected before it reaches the card. - Parallel workflow with a join. fetchConditions → [findPlaces ‖ findEvents] → joinRetrieval → agentDecides → formatCard. Retrieval always runs in code. Places and events fail independently: in recorded takes where every map server failed, the card still gave a time. - Local agent. Qwen sees only the hours and places that passed my limits and returns IDs and a reason code. Nikal validates them, allows one repair, then labels a deterministic fallback. Numbers and links on the card come from retrieved data. - Persistent memory. Preferences live in resource-scoped Mastra working memory on LibSQL, a local SQLite file. The first workflow step reads them before anything is fetched, so a saved limit changes which hours reach the model. - Staged preference writes. The chat tool only stages a validated patch. Nikal commits it after generation succeeds, then prints the persisted old and new values, not the model's reply. !Actual Mastra Studio capture of the completed Nikal workflow using synthetic fixture facts Studio capture of a synthetic fixture run with real local inference: six workflow steps, including the parallel retrieval branches and their join. agentDecides took 2.52 seconds. Open the full Studio screenshot. What broke Overpass. Five consecutive recording takes had all three public map mirrors fail. The primary server was measured responding in 5.7 to 8.4 seconds against an 8-second timeout, so the timeout became 15 seconds before the kept take. The failures also exposed a card bug: warnings shared a 350-character cap, and one card ended with “event search skippe”. Each warning now gets its own line. SerpApi. The google_events engine no longer accepts new requests, so Nikal uses SerpApi's Google Search engine. My first parser read only Google's optional events box and ignored organic results. The corrected one reads both, and treats every result as a lead until its source page corroborates a dated event. Two improvements made after the recording On a rollover to tomorrow, the card now adds one line saying why today's remaining hourly slots failed. From a synthetic test: “No remaining daylight hourly slot passes today: forecast AQI at 5 PM is 110, above your limit of 100.” It is derived from that run's own forecast hours and saved limits. In an interactive terminal, Nikal also shows a short progress note while it works and prints the answer line in bold. The card's text is unchanged. Both are covered by automated tests on synthetic readings and the offline fixture, with no new live or real-model run. The recording above predates both and shows neither. Keyed SerpApi evidence, separate from the GIF An earlier keyed workflow returned three unconfirmed leads, zero corroborated events, and no model-selected lead. Its search response was fetched on 11 October at 12:25 AM IST for outdoor events walks runs street markets in Gwalior this week. A later offline inspection of that stored response, with no new search, found no events box and these leads: a Facebook topic page, a run organiser's archive and an Instagram reel. The reel's snippet contained dates, but a snippet is not a dated, matching event on a source page, so the card said “No verified event found.” Limitations - Forecast AQI is modeled, and forecasts change between runs. The limits are comfort filters, not medical guarantees. - Choices are hourly slots in daylight, at least 30 minutes before sunset. - Distances are straight-line. A mapped place does not establish access, opening hours or safety. - An event counts only with matching, dated Event data on its source page, and “this week” ends on Sunday night. No recorded event has been corroborated. - Qwen 2.5 7B is the only model verified here. Why Does Open Innovation Matter? Open weights make the local part possible: Qwen 2.5 7B runs on my laptop, so the prompt that holds my preferences stays there. Published weights are not open-source software; Mastra, the AI SDK, Ollama and Nikal are. Open data makes the card checkable. The park on the card is an OpenStreetMap entry anyone can open, and Nikal's selection validation is open to review. Model inference and preference memory stay on the laptop. Retrieval is external: Open-Meteo and Overpass receive coordinates, SerpApi receives a city-level query, and source sites receive page requests. Paid model/API charges were ₹0 within free-tier limits, excluding hardware, electricity and network costs. Prize Categories Best Use of Mastra — $100 USD (primary). Tools, a parallel workflow with a join, a local agent and persistent working memory form the core of Nikal. The recorded synthetic-facts demonstration shows a chat-saved preference changing the recommendation from 5 PM to 7 AM across separate processes. Best Use of SerpApi — $100 USD (secondary). Google Search supplies source-linked leads for Nikal's separate corroboration step. The earlier keyed workflow returned three unconfirmed leads, zero corroborated events and no model-selected lead. The unkeyed GIF supplies no SerpApi evidence. Credits: Mastra, AI SDK, Ollama, Qwen, Open-Meteo and CAMS, © OpenStreetMap contributors and Overpass, SerpApi, and VHS.

想在自己电脑上跑中文大模型，Qwen 系列绕不开。 0.5B 到 72B 全都有，中文写作强，文档也是中文的，改起来方便。 QwenLM/Qwen2.5

AI 出图慢，往往不是显卡不行，是去噪步数太多。 Qwen-Image-2.1-Turbo 把文生图和自然语言改图都压到 8 步，画质没明显掉。 QwenLM/Qwen2.5