标签：#pens

Small language models can now run directly on phones. But most of them stop learning the moment they ship. For personal AI, that feels like a strange stopping point. Some of the most useful signals arrive only after the model acts: Did the user dismiss the notification? Did they open it later? Did they rewrite the suggestion? Did they ask for it again? These interactions contain useful information about the user, but they are delayed, private, and ambiguous. They are not clean labels, and they are not reliable scalar rewards. To explore this problem, we built Online-SDFT , an open-source prototype that continually fine-tunes a small language model from delayed interactions while keeping the learning loop on the device. The prototype uses: LiquidAI/LFM2.5-230M A rank-4 LoRA adapter ONNX Runtime Training A bounded on-device replay buffer An Android notification-routing testbed Once the model has been provisioned, inference, interaction storage, replay, and adapter updates all happen locally. Why standard fine-tuning is awkward here Suppose the model receives a notification and chooses one of three actions: Show it now Save it for later Archive it Supervised fine-tuning would require a correct action for every notification. But the phone never observes what the ideal action was. Reinforcement learning replaces the correct answer with a reward, but that reward is also difficult to define. Opening a notification does not necessarily mean it arrived at the right time. Ignoring it does not necessarily mean it was unimportant. The user may simply have been busy. There is another complication: the model only observes the result of the action it actually took. If it archives a notification, it cannot know what would have happened had it shown the notification immediately. What the phone receives is not a label or reward. It receives hindsight . Using the same model as student and teacher The core idea is simple: let the model reconsider its decision after seeing what happened

Electric-vehicle assistants rarely have just one job. A short Turkish question may ask for a nearby station, a charging-price comparison, help planning a route, or an explanation of battery health. Before an application can retrieve current data or generate an answer, it needs to identify that intent reliably. We created the Turkish EV Charging Intent Dataset as a small, transparent starting point for that routing problem. Version 1.0.0 contains 192 Turkish queries distributed evenly across eight intent classes. It is open under CC BY 4.0, includes fixed train, validation, and test splits, and is maintained by TekPedal , an EV charging map and vehicle decision platform for Türkiye. You can explore the dataset interactively , inspect the source and validation workflow on GitHub , or cite the permanent Zenodo release with DOI 10.5281/zenodo.22062688 . Why intent routing comes first An assistant should not answer every EV question in the same way. Different requests need different tools and freshness guarantees: a station request needs a map or location index; a price request needs current tariff data; route planning needs distance, range, and charging-stop logic; a battery question needs careful educational content; a vehicle comparison needs structured specifications. An intent router makes that separation explicit. It can send each query to the correct retrieval source, product page, or application workflow. This also makes evaluation easier: teams can test routing independently before measuring the quality of downstream answers. Dataset design The taxonomy contains eight balanced classes, with 24 records in each class: FIND_STATION COMPARE_PRICE ROUTE_PLANNING CHARGING_SPEED VEHICLE_COMPARISON HOME_CHARGING BATTERY_HEALTH OWNERSHIP_COST Every record includes a stable ID, the Turkish query, the intent identifier, a human-readable Turkish label, a suggested TekPedal content route, the assigned split, the language, and a provenance marker. Here is a simplified example

Quick one: if PyRIT (Microsoft's Python Risk Identification Tool) is on your shortlist for LLM red-teaming, check the repo first. Azure/PyRIT was archived on GitHub on March 27, 2026. It's read-only now: no commits, no releases, no issue triage, nothing. Whatever version you pip-installed is the last version you'll ever get. That matters more for PyRIT than it would for most tools, because PyRIT was never a turnkey scanner. It's a framework for scripting multi-turn attack orchestration, the kind of thing a red team builds custom attack sequences on top of. A framework that's stopped shipping fixes is a worse foundation to build on than a finished tool that's stopped shipping features, because you were relying on it staying flexible to your needs, and now it can't. So what do you use instead? Depends on what you were actually using PyRIT for: You wanted a broad, actively maintained app-layer scanner -> promptfoo . Zero-install via npx promptfoo , 50+ red-team plugins, OWASP/NIST/MITRE ATLAS report mappings, and it's still getting regular releases. You wanted model-layer testing (jailbreaks, encoding tricks, data leakage on the base model itself, not your app) -> garak . NVIDIA-maintained, pip installable, 8k+ stars, actively developed. You wanted OWASP-mapped detectors and don't mind a paid tier for continuous scanning -> Giskard . The open source scanner is real and current; the always-on Hub is commercial. You wanted a fast, zero-setup smoke test before reaching for any of the above -> that's the gap we built sentinel-scan-cli for. Dependency-free CLI (Python and npm ports, identical output), 15 attack patterns each tagged to its OWASP LLM Top 10 category, --demo runs with no config and no API keys in under a minute. None of these replace PyRIT's specific multi-turn orchestration model one-for-one, if that's genuinely what you need, Microsoft's PyRIT Community fork discussion or building your own harness on top of a maintained model API is probably the honest answe

I made a small Vim 9.2+ plugin called thumb . Put the cursor on an image path → :Thumb → popup the image. Select LaTeX in Visual mode → :Thumb → render it as an image popup. For example:  Put the cursor on diagram.png and run: : Thumb Or select: \frac { a }{ b } = \sqrt { x ^ 2 + y ^ 2 } and run: : Thumb It uses Vim's native popup image support, with Python/Pillow for image conversion and matplotlib for LaTeX rendering. No mappings are installed, so you can add your own: nnoremap < leader > t < Cmd > Thumb < CR > xnoremap < leader > t < Cmd > Thumb < CR > GitHub: https://github.com/JosefAlbers/thumb Requires Vim 9.2+, Python 3, Pillow, and matplotlib. Feedback welcome, particularly around the popup positioning/rendering.

Voice and chat assistants for the home share a deceptively hard job: turning messy natural language into precise, structured commands. “Make it cozy in here” has to become a concrete intent plus the right slots — which device, which room, which value. Domux is an open model from iFlytek that focuses on exactly this problem: command understanding for smart-home assistants, framed as intent parsing and slot filling. What it is Task: smart-home command understanding — intent parsing + slot filling Base model: fine-tuned on google/gemma-4-E2B-it Modality: multimodal (image + text input) Target: edge / on-device deployment rather than large cloud models License: Gemma Why the compact base matters Building on the small Gemma-4-E2B base keeps Domux in a size class meant to run close to the device. For home assistants, that direction is attractive: keeping command understanding on-device can reduce round-trips and keep more interaction local, instead of routing every utterance to a large hosted model. Try it The model card is on Hugging Face (access is gated — you may need to log in and request access): 👉 https://huggingface.co/iFlytekOpenSource/Domux We're sharing open work like this because on-device, task-focused models are a practical piece of the foundation-model and serving story — not everything needs to be a giant cloud model.

GitHub热门项目 | Joplin - the privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS. | Stars: 56,058 | 11 stars today | 语言: TypeScript

GitHub热门项目 | | Stars: 864 | 9 stars today | 语言: JavaScript

GitHub热门项目 | A TizenBrew module to remove ads and add support for SponsorBlock for your Tizen TV. | Stars: 2,002 | 10 stars today | 语言: JavaScript

GitHub热门项目 | A scalable generative AI framework built for researchers and developers working on Large Language Models, Multimodal, and Speech AI (Automatic Speech Recognition and Text-to-Speech) | Stars: 18,257 | 45 stars today | 语言: Python

Contributor: Nikhil Kumar Rajak ( @ryzrr ) Organization: webpack · Project: webpack-doc-kit Mentors: Aviv Keller ( @avivkeller ), Claudio Wunder ( @ovflowd ), Sebastian Beltran ( @bjohansebas ) Teammates: Mohamed Shams El-Deen ( @moshams272 ), Tushar Thakur ( @TusharThakur04 ) Period: 25 May to 17 August 2026 The problem webpack's docs lived at webpack.js.org and every API change meant somebody updating them by hand. Pages go stale and nobody notices until a reader does. webpack-doc-kit fixes that. It takes webpack's TypeScript declarations, runs them through TypeDoc, hands the output to nodejs/doc-kit for linking and UI, and produces a site that regenerates itself. We split the work three ways. Shams took AST parsing and content, Tushar took routing and navigation and UI, and I took the operational side: how docs get generated on a release, versioned & deployed. My six deliverables were PR-based doc sync, release-aware doc generation, versioned output folders, a deployment pipeline, CI validation before merge, and README fetch automation. All six shipped. Merged PRs in webpack-doc-kit 31 Lines added / removed +1,959 / −1,419 Distinct files touched 89 First / last merge 28 May ( #110 ) / 14 Aug ( #241 ) Merged PRs in other repos 2 Upstream issue filed and fixed 1 Everything below is merged into main . Nothing is open or pending. The release pipeline webpack releases happen in webpack/webpack . The docs live in webpack/webpack-doc-kit . A release in one needs to produce updated docs in the other with nobody doing anything. #110 set up versions.json as the single source of truth everything downstream reads, plus the script that maintains it and the workflow that runs it. My mentor proposed an object schema with latest , label , major , exactVersion , commit and frozen per entry. Review cut it to a flat array of tag strings, because everything else is derivable from the semver string and position [0] with unshift() already tells you which is latest. Right call, and I d

Hit a perfect 7-day streak this week, shipping 177 commits across systems architecture and personal...

GitHub热门项目 | TSP自托管、零运维的 A 股「选股 + 监控 + 回测」量化工作台 | 基于 TickFlow 数据源 | LLM能力驱使策略定制+个股分析+复盘 | 自由接入第三方数据源与个性化扩展数据 | 个人开源 ,非TickFlow官方项目 | Stars: 3,477 | 82 stars today | 语言: Python

The more autonomy I give coding agents, the more of a repository's expectations need to be executable. I do not want manual review to be the first place a predictable failure is discovered. My projects now have more pre-commit hooks, tests, deterministic checks for project conventions, and small reviewable commits. The checks turn expectations into pass/fail results an agent can act on; the commits keep failures narrow enough to diagnose. Linting is one of those guardrails. This story began when the React linting layer I relied on broke during an ESLint 10 upgrade. I maintain several React applications and wanted to upgrade them to ESLint 10. The upgrade stopped at eslint-plugin-react . ESLint 10 removed deprecated rule-context APIs . The current eslint-plugin-react@7.37.5 release declares support only through ESLint 9 and can crash under ESLint 10 with: TypeError: contextOrFilename.getFilename is not a function The upstream compatibility issue was opened on February 7, 2026. As of August 23, it is still open more than six months later. The pull request , opened on July 30, is also still open. That led me to release @ternaus/eslint-plugin-react : an independent React 19 continuation for ESLint 10. Who this is for The package has a deliberately narrow support matrix: Tool Supported version React 19+ ESLint 10 Biome 2.5.8+ Node.js 22.13, 24, or 26 ESLint config Flat config React 18, ESLint 9, and .eslintrc* are outside the package contract. My setup My projects use Biome as the primary formatter and linter. Biome handles general JavaScript, TypeScript, JSX, DOM, and most React checks. ESLint remains for checks that Biome does not provide, including framework plugins and several React 19 contracts. The setup came from real Next.js and React codebases behind Albumentations.ai , sportscategory.info , and my-roots.me : Next.js 16 React 19 TypeScript ESLint 10 with flat config Biome with the all preset Yarn 4 Node.js 22, 24, and 26 My projects need a smaller rule set: the

How I built an FVG trading bot for OKX and made 99% of its signals useless on purpose If you trade crypto futures, you know the drill. You're staring at the chart at 3am because you're scared to blink and miss "the perfect entry". Or worse, you get in emotionally, chase a pump, and hand back all your profit in one bad night. I got liquidated once because my stop was at -5% and the liquidation price was at -2%. Price gapped straight through my stop. That's how this project started. I built FVG Killer , a bot that trades one setup only: the ICT Fair Value Gap, on OKX perpetuals. The repo is open-source: https://github.com/Xbs950812/okx_fvg_agent 1. What it trades FVG stands for Fair Value Gap, from the ICT (Inner Circle Trader) framework. The idea is simple: one violent candle moves price fast and leaves a "vacuum" where almost nobody got filled. The theory says market makers rebalance and price tends to come back and fill at least half of that vacuum. So the bot waits for price to retrace into the gap, enters, takes profit at the 50% level (consequent encroachment in ICT-speak), and stops out outside the gap. Detection pipeline: Pre-filter: at least a 3-sigma move and 5x volume expansion Three-candle gap detection, scanning 1H and 4H It tracks the top 100 contracts around the clock, even when it holds nothing 2. The part nobody tells you: saying no Textbooks show you three candles and call it a day. Reality: a naive detector spits out dozens of signals a day and 99% of them are garbage. I built five gates to reject them. Each has a real log line from production: Freshness: gap older than ~100 candles? Drop it. [Freshness] SNXX 1H FVG 186 candles old > 24, drop ATR grade: gap width less than 0.5x ATR is a weak setup. [ATRGrade] width 0.16/ATR 0.37 = 0.43 < 0.5, weak C-grade Direction: don't long a coin that just pumped 14%, don't short one that dumped. [MoverDir] ETHFI 4H long rejected: +14.4% in 24h Depth: if the resting order is 6% off price, you're catching a falli

I spent two months building Vestibule, an open-source Python framework for the boring layer of RAG ingestion — stable document IDs, a state ledger, error classification, per-vertical governance. The parts every team struggles with once the demo works and production doesn't. Most of the code wasn't typed by me. Four AI agents did the work — one wrote designs, one reviewed them, one implemented, one reviewed the code — all through real GitHub pull requests, with me signing off at every gate. The result: twelve components, three releases, 878 tests. Two moments defined the whole experience. When the process caught what I couldn't The trickiest component provisions vector indexes on first use, safely even when workers race each other. Its design was rejected and revised five times before any code existed. In the first round, the reviewer agent found a genuine race condition: a worker still inside a slow index-creation call (~390 seconds with retries) would look stale (the threshold defaulted to 300 seconds), lose its claim to a waiting worker, and now two workers create the same index. A production race, in the default configuration, spotted by one AI reading another AI's design — before a single line was written. When green tests lied to me After v0.2 shipped, I wrote a quickstart script and ran the pipeline the way a stranger would — for the first time. pip install didn't work. At all. A packaging conflict made the whole framework uninstallable, while 483 tests sat green. An hour of actually using it turned up two more: a default model name that had never once worked against the real SDK, and an import that took down an entire package when an optional dependency was absent. What went wrong wasn't the tests — it was what they measured. They proved the code agreed with itself: same working tree, same mocked seams. Nothing ever checked the world a user lives in: clean machine, real install, real SDK. Passing tests and a working product turn out to be two different claims

skillcheck is a static analyzer for SKILL.md files, the format agents like Claude Code, Copilot, Codex, and Cursor use to load reusable skills. It validates frontmatter, scores description discoverability, checks file references, enforces token budgets, and flags cross-agent compatibility issues. No network calls, no LLM calls, no file mutations. Runs as a CLI, a GitHub Action, or a pre-commit hook. pip install skillcheck skillcheck skills/ Latest pass was hardening and accuracy, not features. Here's what changed and why. Description scores went up. Skills that were scoring low because the scorer was broken will now see a jump in scoring. Median across the reference corpus went from 75 to 90. --explain-score also now tells you which pattern hits or misses instead of just a number. The score exists to predict whether an agent will actually find and trigger your skill, so a scorer that under-credits good descriptions defeats the point. The fix was validated against real-world skills, and the separation held: filler still scores 28-65, well-written descriptions 85-100. Corrupt files now fail cleanly instead of crashing. Before, a bad history ledger or non-UTF-8 skillcheck.toml above the skill dumped a Python traceback. It's now a clear error naming the file and byte offset (exit code 2). Config discovery walks up the directory tree, so one bad file could break every scan under it. Now every untrusted read (ingest, history, config) goes through the same guard before parsing, so they all reject the same way. README has been corrected in regards to token estimates. Without tiktoken, expect roughly 20-30% over-estimation, so install the extra if you're near a budget limit. The offline heuristic feeds the budget checks and its accuracy had never actually been measured, just assumed. It's benchmarked against tiktoken across the full corpus now, and the documented numbers are the measured ones. pip install "skillcheck[tiktoken]" The rest of the pass is invisible on purpose: f

mcp-drift-monitor detecta cambios no autorizados en servidores MCP (Model Context Protocol). Implementa el control primario faltante descrito en arXiv:2608.00997 : un barrido completo periódico del catálogo que re-descarga todos los servidores y recomputa hashes. Problema arXiv:2608.00997 ( MCP Registry Drift: A 88.6-Day Measurement of 19,099 Servers ) reporta un punto ciego crítico: los enfoques tradicionales de detección de cambios fallan en identificar dos modos de fallo: Cambios silenciosos — un servidor cuyo hash de descripción cambia, pero el monitor ya lo conocía y lo rankinga por historial pasado. Nuevas adiciones — servidores que aparecen en el registro sin que el monitor tenga registro previo. El paper mide 15,845 eventos de cambio, 19,877 adiciones y 911 eliminaciones, pero los modelos que rankean por historial previo pierden una fracción significativa de estos eventos. Este monitor cierra esa brecha con el control primario que el paper propone pero no implementa: un full-catalog sweep periódico. Solución mcp-drift-monitor implementa un motor de diferencias único ( compute_events ) que sirve tanto para polling incremental como para barridos completos. No hay lógica duplicada. Cada vez que un hash de descripción cambia, el motor revalida el contenido ( len(drifts) > 0 es el único disparador). Si el registro responde 429, aplica backoff con Retry-After . Si el payload está malformado, lanza SchemaDriftError y registra el payload ofensor a nivel ERROR. Arquitectura core/ diff.py — CatalogEntry, DriftEvent, NewArrivalEvent, RemovalEvent, compute_events hasher.py — normalize_description (NFC), hash_description state.py — StateStore (sqlite), FetchStatus, removed flag, get_all_hashes poller.py — Poller.fetch_catalog, PollConfig, SchemaDriftError, backoff sweep.py — run_sweep (control primario), SweepReport calibrate.py — replay (FR-6), ReplayReport, external validity vs panel Resultados de calibración El monitor se calibró y verificó contra el panel real del pa

I maintain a small comic and manga viewer component for React called react-comic-viewer . The other day I was poking around npm and noticed something odd — there were three other packages with basically my package's name, published by other people. All three were forks of mine. Same description, same repository URL pointing back at my repo. None of the three authors had ever opened an issue or a pull request on my side. What the fork changed The oldest fork was made about three months after I first published, and it kept going for almost a year. Its version number ran ahead of mine at the time — I was on 0.3.5 while the fork was on 0.6.3. So I read the diff. Honestly, it was more useful than any issue would have been. The commit messages alone told the whole story: remove sass fix: support className props use Hotkeys and a new example file called controlled.tsx The sass one I'd already fixed. The className one I'd fixed too, about a year later. The controlled.tsx one I had never fixed. Not in four years. The part I never fixed Here's what their example looked like: < ComicViewer currentPage = { currentPage } isExpansion = { false } onTryMoveNextPage = { ( nextPage ) => { /* ... */ } } onChangedCurrentPage = { ( page ) => setCurrentPage ( page ) } pages = { pages } /> And here's what my component actually accepted: < ComicViewer initialCurrentPage = { 0 } initialIsExpansion = { false } onChangeCurrentPage = { ( page ) => { /* ... */ } } pages = { pages } /> The initial prefix is the whole problem. My component would take a starting page from you, and then never let you touch it again. It owned that state for the rest of its life. That's fine for a demo. It's pretty bad for anything real. You can't jump to a page from a table of contents. Syncing the current page with the URL doesn't work either. And if a chapter needs to be purchased first, there's no way to step in and stop the move. Every one of those needs the parent to be in charge, and the parent never was. Maki

Every coding agent says it is efficient. Almost none of them publish the bill. So we ran the boring experiment: the same bugfix, the same model, the same API, the same prices, and a byte identical prompt, once through opencode and once through the coding agent inside Locally Uncensored. Headline: opencode averaged 2157 credits over three runs. Our 2.6.6 agent finished the identical task for 1298 . That is about 40 percent less, and even the cheapest opencode run came in 29 percent above our number. The interesting part is not the headline. It is why the gap exists, and it is not the reason most people guess. Setup A cost comparison is only worth reading if everything that drives cost is nailed down. What was held constant: Held constant Value Task Fix a failing test in a small npm repo, then commit Repository Three files, a one line bug in add.js , tests red at the start Prompt Byte identical, sha256 29cec6c3...cf62687 Model deepseek-ai/DeepSeek-V3.2 Endpoint The same OpenAI compatible API for both agents Prices Same account, same tier, same per token rate Counting One wire proxy in front of the API, credits read before and after every run opencode 1.18.21 from npm, wired as an OpenAI compatible provider, opencode run --auto , otherwise defaults Success was defined before the runs, not after: npm test passes exactly one commit, with the required message only add.js changed clean working tree at the end All four runs cleared that bar. Nothing failed, so cost is the only variable that moved. The numbers Run Credits Requests Prompt tokens Success opencode, run 1 1679 8 98,789 yes opencode, run 2 2433 11 146,058 yes opencode, run 3 2358 11 146,387 yes Locally Uncensored 2.6.6 1298 16 74,629 yes Locally Uncensored 2.6.5 4395 30 257,270 yes Read the last row first. Our own shipped agent from one release earlier is the most expensive thing in that table, by a lot. This is not a chart built so that we win by construction. It is a chart that shows what one efficiency pass is

Hello I'm creating CrowdGPT , an open-source project which allows training of a LLM (Large Language Model) in a decentralized way, where each user contributes to making the AI better with whatever data they want. The idea is simple: instead of one machine owning the entire training run, let many people contribute small training jobs and periodically merge those updates into a shared model. The system is based on a centralized server (lightweight) that receives every client training, then "merge them back" to the main model. This system prevents threats or malicious updates by doing cross-client verifications (provides a proof of work). The users that train the model are being put on a leaderboard, rewarding their contribution. Data is taken from a curated dataset on Hugging Face (which means no personal data is ever used during training). However, users can push new text to this dataset (which is then moderated and validated). If you're curious, here is the GitHub: https://github.com/Vxtzq/CrowdGPT Here is the website: https://www.crowdgpt.net The best way to help me is to either: Give feedback on what must be changed to make it a fully finished project. I'm mainly looking for criticism: what would stop you from running this on your own GPU? Contribute to the project by becoming a part of the network (coming soon) Star the repo on GitHub ⭐ It helps a lot :)