Mentions

ローカル環境で一枚絵から３Ｄモデルを作成できる「Idol」(ネーミングちょっとアブない)が、先日公開されたので触ってみました ComfyUI上で動かすので、導入にちょっぴりPythonの知識が必要ですが、チャッピーに訊けば何とかなるのでお試しあれ huggingface.co Comfy-Org/work t.co

macOS window switcher in Swift where ⌘-Tab lists every window, including other Spaces, and typing filters them - Switch Sanyam-G/switch dev here. it's swift/swiftui, the hotkey is a cgeventtap and windows on other spaces come from a few private skylight calls. it's not on the app store because sandboxed apps can't use accessibility like this. brew install --cask Sanyam-G/switch/switch if you want to try it

⭐️PS3 World-app dev builds by daedra000 PS3 Homebrew app for downloading apps, games, themes, and avatars from ps3.world 👉This is a work in progress. 📥github.com/daedra000/ps3world-app/actions t.co

Stop re-explaining your project to Claude Code: build a knowledge graph Graphify turns your code, docs, schemas and PDFs into a queryable knowledge graph for AI coding assistants. Install it with uv and run /graphify . in Claude Code. Official repo: Graphify-Labs/graphify #graphify #claudecode #aitools #knowledgegraph #vibecoding #shorts

@serhiyhvala @maria_rcks congrats on the merge! i've been trying to get a sandbox environments idea into T3 Code but it's stuck waiting on direction in the discussions. any tips on how you got it in front of the team? it's this one t3code#27949

StableGen is a free, open-source (GPL-3.0) Blender add-on that runs your own models through ComfyUI. The models keep their own licenses (Qwen Image 2.1 is non-commercial). sakalond/StableGen Guide: github.com/sakalond/StableGen/wiki Discord: discord.gg

Some of everything: logic errors, missed edge cases, flipped boolean/inequality signs, etc. Check out the fix PRs if you'd like: github.com/obi1kenobi/trustfall/pulls github.com/obi1kenobi/trustfall-rustdoc-adapter/p…

How to stop prompt injections and AI hallucinations at the OS level (CBS v1.6.2 release) Disclosure: I am the author of Cyber-Butler-Security (CBS). If you run AI Agents (like DeepSeek Harness, AstrBot, or LangChain) locally on your machine, you've probably experienced the "Oh no" moment. Maybe the AI hallucinated and deleted a folder. Maybe a malicious prompt injected through a webpage told the agent to read your ~/.ssh keys. Most solutions today try to fix this at the application layer: writing better prompts, hooking into the agent's API, or using a secondary LLM to judge the first LLM. But here is the harsh truth I learned after talking to security experts on Reddit: You can't stop a Turing-complete program by asking it nicely. If the agent executes arbitrary code, application-layer guardrails are just suggestions. So, I decided to build Cyber-Butler-Security (CBS) — an OS-level, fail-closed security sandbox specifically designed for Windows. Today, I am releasing v1.6.2-preview (Experimental). Here is how it works, the new features, and the three deadly traps we had to build defenses for. --- 🏗️ The Core Philosophy: Fail-Closed & Human-in-the-Loop CBS doesn't try to judge if the AI is "good" or "bad". It restricts what the process is physically allowed to touch. 1. Dual-Account Isolation: The Agent runs in a separate low-privileged Windows service account (CyberButlerSvc). It physically cannot see your host files via Windows ACLs. 2. TOTP Broker: If the Agent tries a high-risk action (delete/overwrite), the SYSTEM-level Broker intercepts it. It pauses the Agent and sends a TOTP (Time-based One-Time Password) to your phone. The AI cannot see or intercept this code. 3. Scoped Tokens: To prevent approval fatigue, you can authorize a specific scratch folder for 30 minutes. The AI works freely there, but the moment it touches config or memory, it gets blocked again. --- ⚠️ The 3 Deadly Traps We Had to Defend Against During development and discussions with red-teamers, we realized that simple "file path blocking" is not enough. Here are the new defenses in v1.6.2: Trap 1: The "Lying" AI (Intent Mismatch) The problem: The AI says, "I'm just updating the UI colors," but the actual tool call is trying to modify .env or auth.py. If a human blindly clicks "Approve" on the TOTP prompt, the system is compromised. The fix: CBS compares the AI's reason string with the actual target path. If it claims to modify UI/CSS but touches config/secret, the TOTP prompt flashes a huge red ⚠️ INTENT MISMATCH warning. We show the raw system parameters, never the AI's natural language summary. Trap 2: The "Wolf in Sheep's Clothing" (Magic Bytes Sniffing) The problem: A malicious script can be renamed to travel_photo.txt. Simple extension-based filtering will miss it. The fix: CBS reads the first few bytes of the payload. If it detects a Shebang (#!), PE (MZ), or ELF header, it flags the file as Executable Content, regardless of the extension. Trap 3: Test Tampering & Rule Bypassing (Anti-Tampering) The problem: If you use AI to write code, it might modify pytest.ini or conftest.py just to make the CI pipeline pass, rather than actually fixing the code. The fix: CBS hard-denies (403) any write attempts to critical integrity files (conftest.py, pytest.ini, .github/workflows/*). We also introduced a Credential Proxy: the Agent only gets a "fake" API key. The real key is injected at the local reverse proxy layer. Even if the AI is compromised, it cannot steal your real credentials. --- 🛡️ Supply Chain Security & Auditability We also hardened the release and audit process: - TOCTOU Protection: Approvals are bound to the file handle + SHA-256. If the file is swapped between approval and execution, CBS returns a 409 Conflict. - Quarantine: Deleted files go to an isolated zone with a manifest. Restoring them requires a new TOTP. - WFP Egress Firewall: We use Windows Filtering Platform (WFP) to audit and block outbound connections. (Currently in audit-only mode to prevent false positives). - Audit Hash-Chain: All logs are mirror-written into a hash chain. Tampering with the logs breaks the chain. - RSA-3072 Signed Releases: The release manifest is cryptographically signed. --- 🚨 A Critical Warning (Please Read) CBS v1.6.2-preview is an EXPERIMENTAL release. It has not completed clean-VM acceptance or full physical-machine testing yet. - If you want a working setup: Please download the stable v1.6.1 release. - If you are a security researcher/bug hunter: This v1.6.2 preview is for you. Please run it in a disposable VM or snapshot. We have published our Threat Model and Security Policy (SECURITY.md). It includes our core security invariants, a self-audit checklist inspired by CVE-2026-82533 (the local API auth bypass in AI harnesses), and a list of what CBS explicitly does not protect against (like a full admin compromise). 🔗 Repo & Feedback GitHub: https://github.com/JunxiangPan/Cyber-Butler-Security We have 154 passed Pytest cases and 144 passed Pester tests, but I know there are gaps. If you test it, let me know: 1. Does the Intent Mismatch logic cause false positives? 2. Are there ways to bypass the Magic Bytes sniffing? 3. Does the TOTP Broker ever hang or deadlock under heavy concurrency? Let's build a safer ecosystem for local AI together. Thanks for reading!

🙄 虽然我不知道为什么 GPT Pro 死活要让我做一个 Scientific Viewer 来支持多种文件的预览。好看是挺好看的，但是为什么你这 6.1 sol 做出来的 UI 怎么怎么丑。 phodal/pero #ai4s t.co

PUMPFUN JUST ADDED QUANTUM PROOF SECURITY?? we can finally send QUANTUM INU W PUMP PAIR AND QUANTUM STOCKS NO PAIRS WENT 6MIL github.com/pump-fun/pump-fun-skills/commit/cd0b46… t.co

Redde 2.3.1: Proactive. This is where it gets fun... Until now, I've focused on the standard features we all know and love: chats, bots, voice. Now it's time for proactive ones: an agent that acts before you ask, closing the gap with Grok Bot, Muse and the like. The video is one day with it. Crammed, trying to show as much as possible in the one minute I can. But there's far more new than fits in a minute, so below is everything, each with something to say or try to see it for yourself. 2.2 slipped out without a post, so its voice features are at the end. Redde is a free iPhone, iPad, Mac, Apple Watch and CarPlay app for your own Hermes agent, and 2.3.1 is out today. Oh, and now a native macOS app too! Most of it takes the Redde plugin on your Hermes. Settings → Agent → Ahead of Your Day installs or updates it and turns the daily jobs on in one step. Your Hermes agent now gets ahead of your day, plus 2.2's live voice (too much for one video, so here's a list to try) As always, privacy comes first. The proactive features are all off until you turn them on, and nothing comes back to me: your data goes only to your own server, and to services you choose, on your own keys. Ahead of your day - Morning Ideas. A few things worth doing today, as cards to swipe: right to have your agent do it, left for not now. Hold one for More Like This, Fewer Like This or Later. It learns from your swipes. - Try: turn it on, then tomorrow morning swipe the deck. - Heads-ups before your events, with what to bring and who's coming. - Try: "Give me a heads-up 30 minutes before my dentist appointment with what I need to bring." - Leave-By Alerts. Redde checks your calendar and Apple Maps on your iPhone and tells you when to leave, by car, transit or on foot, with the traffic checked again close to the time. - Try: add an event with a street address and wait for the nudge. - Week Ahead on Sunday and an Evening Wrap-up each night. - Try: "What does my week look like?" - Up Next on your Home Screen counts down to your next event and shows what's waiting for you. - Health-aware days, if you allow it: last night's sleep and today's steps shape your ideas and wrap-up. Off until you turn it on, and the numbers only go to your own server. It comes back on its own - Watches. Your agent keeps checking and tells you only when something changes. - Try: "Keep an eye on the price of AirPods Pro and tell me if it drops below $180." - Follow-ups. Loose ends don't get dropped. - Try: "Check back with me Friday about the contractor's quote." - Hand-offs. A watch can wake another bot instead of you. - Try: "Watch the NAS's free space every morning and hand it to Ops if it drops under 10%." It reacts to your day - Places. Set Home, Work or the gym. Arriving or leaving tells the agent you choose. - Try: Settings → Agent → Places → Home → when I arrive, "Turn on the porch light." - Shortcuts triggers. "Ask a Redde Bot a Question" works in any automation. - Try: when CarPlay connects, ask Home "Is the garage door closed?" - Routines. Any chat can become a routine: the menu → Make This a Routine, with a schedule if you like. - Try: "Every weekday at 7, tell me what to wear for the weather." - Quiet Hours hold the non-urgent ones and hand you a short digest when they end. - Agent Activity is the log of everything your agents did on their own, and Before Acting sets how much each one may do unasked. Answers as cards Ask for these and the answer comes as a card, not a wall of text: - "What's on my calendar tomorrow?" Your day as a timeline, free time marked. Tap a gap to add an event. - "Will it rain this afternoon?" The weather by the hour. - "Coffee shops within a 10-minute walk." Places on a map, with ratings and hours. - "Find me cheap options for a 5090." Products to buy, with your agent's pick, prices, ratings and stock. - "Compare the Sony XM6 and the AirPods Max." Side by side. - "Draft an email to my landlord about the leak." An email to check and edit before it goes. - "Packing list for a weekend in Boston." A checklist with a progress ring. - "Turn off the office lights." Your home's devices, with toggle controls. - "Set a timer for 12 minutes." A countdown. - "Did the Heat win last night?", "Chili for 6", "Is AA 1234 on time?", "Where can I watch Severance?", "180 °C in Fahrenheit", "How's NVDA today?": scores, recipes that scale, flights, where to watch, conversions and stocks. Also in 2.3.1 - Redde for Mac, a native app with menus, shortcuts and text zoom. It's included in the same free download. (Currently in review) - 17 languages. The whole app, and voice mode listens and answers in the one you pick. - Approvals in plain words. Before your agent runs something, the card says what it will delete (in red), what it changes, and whether Hermes restarts. - Keys asked for. When your agent needs an API key, it asks in Redde, and what you paste goes sealed straight to your server, never into the chat. - Current Location, if you turn it on: your agent hears roughly where you are, only when you ask about places, directions or the weather. - US or metric, for your agent, the weather and distances. And 2.2, which never got a post: Voice - Live voice. Voice mode becomes a real call: pick ElevenLabs, GPT-Live, Gemini Live or Grok Voice in Settings → Voice → Voice mode and add your key. It talks and listens at once, so you can interrupt it. It answers small talk itself, and anything real goes to your agent, then it says the answer in its own words. Each service bills your key per minute. - Try: mid-answer, cut in with "Actually, make it tomorrow instead." - Your agents can call you. Turn on Calls from Agents (Settings → Notifications) and pick who may. When something shouldn't wait, it rings like a phone call, Lock Screen included, and tells you why in its own voice. - Try: "If the garage is still open at 11 tonight, call me." - A voice for every bot. Each bot can have its own engine and voice (Edit Bot → Voice), with a sample of every voice before you pick it. - Try: in a call, "Home, is the back door locked?" Home answers, in Home's voice. - Wake phrases. With Redde open on your iPhone, iPad or your car's screen, say "Hey" and an agent's name. It listens on the device, and it's off until you turn it on (Settings → Voice → Wake Phrase). - Try: "Hey Home, turn the lights off." - Group chats as calls. Voice mode in a group chat is a live call: each bot answers in its own voice. - Try: in a group with your research and writing bots, "Plan a weekend in Asheville." - ElevenLabs reads your replies, on your own key, each bot in an ElevenLabs voice of its own. Kokoro voices can be blended. - Plugins. Settings → Plugins browses Nous Research's catalog and installs Hermes plugins for your agent or one bot. Official and verified ones come first, and you see what each sends, costs and adds before you install it. - Bots make Kanban cards, in their own chats and in group chats. - Try: "Make a Kanban card to renew the car registration by the 15th." - A wallpaper behind your chats, with the text, and light or dark, following it. - On Apple Watch, each bot reads its replies in its own voice. App Store: apps.apple.com Source: goosehouse-llc/redde What would you have your agent watch for you? Feedback and bug reports welcome.

その後 change6を実行。 add-symbol-shoestringを適用する。 github.com/dusanjp-and-pasomi/tools/tree/main/cha… 結局こうなるwwwwwwwwwwwwwwww t.co

@tysn_dev christopherowen/spark-ds41f This absolutely rips.

Agora sim, último launcher do dia: DiRT Rally (2015). GitHub: akitaonrails/rea-dirt-rally Esse é um que nunca consegui fazer rodar em Linux, e acho que até em Windows tem problemas até hoje. Todo mundo sabe que Dirt Rally 2 é um dos melhores jogos de Rally de todos os tempos, mas poucos jogam o primeiro. Mas eu queria esse porque, se não me engano, é um dos poucos que tem Pikes Peak! Agora dá pra jogar!

Your web terminals are now agent tools vercel-labs/wterm

One less box. One less thing to get something like a Harmony or Sofabaton remote to integrate with. An interface of your choice (there are many frontends), etc. I see a lot of ppl in here advocate AppleTV but that assumes you're part of their ecosystem already. Or think of it his way: get root for some powerful new features over the stock TV OS and get telemetry blocking as a bonus. I'm planning to set up lg-hue-sync [0] that can read the TV's framebuffer and control an ESP32 connected to a LED string for a dirt cheap AmbiLED setup. [0] poiedk/lg-hue-sync

iPhone Duo is the best console i've played rocket league on After playing on PS4, PS5 and Switch 2 for years, i can confidently say that the game runs way smoother, with almost zero input lag on my new iPhone Duo, and it does that while running inside a simulated Windows environment using wine. local on device, no streaming or anything. I am amazed. I used willfaust/madeira (version 0.2.0), sideloaded with a developer account for extended jit memory - works flawlessly - apart from EAC that doesn't work, so no online matches for now :(

It's open source. Paste the repo into Claude Code and say "set up Chatterbuilt Mail for me." Fork it, make it yours. mrhinkle/chatterbuilt-mail What would you build into yours?

Why your cloud monitoring is blind to IPv6 blackholes (and how to fix it) TL;DR: your checker probably takes the first address the resolver hands back, and on a dual-stack host that is the AAAA record. If IPv6 is a blackhole — a route that exists and drops packets — every check waits for its full timeout and then reports the target as down. The target answered in 281 ms on IPv4 the whole time. This post is the ten-second experiment that proves it, the two different shapes of IPv6 failure that everybody merges into one word, and a two-file CLI that tells them apart. --- !Two bars on the same baseline: IPv4 answered in 281 ms, the check reported the target DOWN after 10,007 ms The dashboard was green. The site was green. A monitor reported timeout of 48048ms exceeded and paged somebody at 3am, and the site had been answering requests the entire time. That number is not a network fault. It is a timeout setting faithfully reporting how long it waited. Which means the interesting question is not "why did it take 48 seconds" but "why did anything wait at all, and who decided the target was the one to blame?" Here is the answer, and you can reproduce it in a container in about ten seconds. The ten-second experiment Take a hostname that resolves to a healthy IPv4 address and an IPv6 address that swallows packets. I used a documentation prefix for the AAAA side, which is the cleanest way to make a blackhole on purpose: printf '127.0.0.1\tlocalhost\n104.20.23.154\tdemo.internal\n2001:db8::1\tdemo.internal\n' > /tmp/hosts.demo Now ask the resolver what it thinks, and then ask a checker that takes the first answer: $ python3 -c "import socket; [print(' ', 'IPv6' if i[0]==socket.AF_INET6 else 'IPv4', i[4][0]) for i in socket.getaddrinfo('demo.internal',443,proto=socket.IPPROTO_TCP)]" IPv6 2001:db8::1 IPv4 104.20.23.154 IPv6 comes first. That is not a bug and it is not this host being odd — RFC 6724 says to prefer the larger scope and longest matching prefix, and identical scopes break the tie in favour of IPv6. Any resolver worth using does this. Which means the very common line below is a coin flip: addr = socket.getaddrinfo(host, 443, proto=socket.IPPROTO_TCP)[0] # <- the bug A check built on that line gives this answer, on this host, at this moment: $ python3 -c "..." DOWN (timeout) after 10.0s And the same target, measured properly: $ alertpath --check-host demo.internal --timeout 10 demo.internal:443 -> IPV6-BLACKHOLE vantage : localhost summary : IPv6 blackholed while IPv4 works for demo.internal A : 104.20.23.154 AAAA : 2001:db8::1 IPv4 104.20.23.154 ok 281ms IPv6 2001:db8::1 timeout 10007ms no response before 10s deadline 281 milliseconds, versus a ten-second report that says DOWN. Both are true statements about the same hostname at the same instant. One of them is a measurement. The other is a measurement of the wrong thing, wearing the target's name. Note what the failure costs you: the timeout is not wrong, it is unattributed. Nothing in DOWN (timeout) says whether the far side failed to answer or our own packets failed to arrive. Those have opposite owners, and the alert has one word for both. The two shapes of IPv6 failure, which are not the same thing This is the part I got wrong first, and it is the part that matters for how you fix it. I tested three vantages I actually had access to. A homelab host with working IPv6, a cloud VM in the Asia-Pacific region, and a default Docker bridge network. | Vantage | IPv4 | IPv6 | Shape of the failure | |---|---|---|---| | Homelab host (dual-stack) | ok, 254 ms | ok, 223 ms | none — both families work | | Cloud VM, AP region | ok, 205 ms | refused, 0.0 ms — Network is unreachable | no route | | Default Docker bridge | ok, 276 ms | refused, 0 ms — Network is unreachable | no route | | Blackholed prefix (2001:db8::1) | — | timeout, 5003 ms / 5004 ms / 5004 ms | dropped packets | Two of those rows look similar in a log and are completely different animals: No route. The kernel answers immediately: ENETUNREACH, in zero milliseconds. Your check fails fast, fails loudly, and falls back to IPv4 if you wrote it to fall back. Annoying, but honest. A container with no IPv6 route is this case, which is why most people never see the dangerous one. Blackhole. A route exists. Packets leave. Nothing comes back, and nothing tells you so. The connect call does not fail — it waits. This is the only one that produces a false green, and it is the one that costs you a night. Measured above: the full deadline, every time, with no distinguishing text. Here is why that distinction is not academic. If you see "IPv6 doesn't work" and you have the first shape, you conclude you have no IPv6 and move on — correctly. If you have the second shape, you also conclude you have no IPv6, and you move on, and meanwhile the resolver is handing IPv6 to the front of the list, so roughly half your connects begin by waiting for a deadline that will never be met. Same conclusion, opposite risk. One of these is a config note. The other is why your p95 went up and nobody could find out why. Containers make this worse, in a specific and boring way A default Docker bridge network has no IPv6 route, so you land in the loud failure shape — measured at 0 ms, Network is unreachable. That is genuinely the safe case, and it is why containerised probes usually survive this. But two things change the picture: 1. The container still resolves AAAA records, because DNS works over IPv4. So getaddrinfo still hands back an IPv6 address first, and any code that trusts the first entry still tries it. On a bridge network it fails instantly; on --network host, or in a VPC with IPv6 enabled, the same code meets a route that may or may not drop. 2. Whether your container has IPv6 is a property of the network it is attached to, not of the image, not of the application, and not of your intent. The same probe image that behaves on one network silently mis-attributes on another. That is the definition of a configuration that fails in the direction you cannot see. The uncomfortable generalisation: a check's behaviour is a property of where it runs. Anything that reports a verdict without recording where it stood has produced a claim nobody can check. "Just raise the timeout" is the wrong repair When a check times out against a healthy site, the instinct is to raise the timeout so it "has time". That makes the false report slower. It does not make it truer, and it makes the page arrive later than it otherwise would. The timeout is not the defect. The defect is that one string covers two situations with different owners: | What happened | What it means | Whose problem | |---|---|---| | kernel completed the handshake | reachable | nobody | | kernel answered, answer was "no" | host is up, nothing listening on that port | the target | | nothing answered before the deadline | could be the target, could be your egress | unresolved | | AAAA silent while A works | your probe's path, not the service | you | Connection refused is the one people get wrong most often. It is an answer. It means the target is alive and declined, which is a state no amount of probe repair will change. Reporting a refusal as an outage is both wrong and expensive, because it sends somebody to look at the wrong machine. How to fix it Three rules, in order of how much they buy you. 1. Never merge the outcomes. Keep "connected", "answered no", and "said nothing" as three separate values all the way through, from the socket to the alert label. The moment they share a variable, every downstream consumer inherits the ambiguity. 2. Give each outcome its own exit code. A monitor reads a code, not a sentence. Codes are what let you say "exit 3 should not wake anybody up" — because exit 3 means the probe is blind, not that the service is dead. 3. Measure from a second vantage. This is the only honest way to answer "is it the target or the path?". Silence from one vantage while the other reaches the target is a path problem, and it names the broken path. Silence from everywhere points at the target, with the caveat that a shared upstream produces the identical picture — so say so rather than pretending the question is closed. One measurement can never separate the two. That is not a limitation of a tool, it is a property of what a single vantage knows. The tool I extracted this from the audit tooling I maintain and packaged it as two files with no dependencies, because the machine where things are broken is frequently a machine where you cannot install anything: **dafili/alertpath-cli** git clone https://github.com/dafili/alertpath-cli cd alertpath-cli python3 -m alertpath --check-host your-service.example.com Exit codes are the interface: | Code | Verdict | Should it page? | |---|---|---| | 0 | ok | no | | 1 | refused — the target answered and said no | target team | | 2 | timeout — nothing answered | run a second vantage first | | 3 | IPv6 blackhole, IPv4 works | no — this is your probe | | 4 | did not resolve from here | check which side | | 5 | the check could not run | no — this is your invocation | Exit 3 and 5 are the interesting ones, because they are the codes that tell you not to page. Any checker that cannot express "the instrument is blind" will eventually use "the patient is dead" to say it. Second vantage, with nothing installed on the far side — it ships the same source over ssh and runs it there, so both measurements come from the same code: $ alertpath --check-host example.com --via probe-eu --compare example.com:443 -> OK vantage : localhost example.com:443 -> OK vantage : ssh:probe-eu compare -> OK reached : localhost, ssh:probe-eu And when the far side cannot be reached at all, it refuses to conclude anything: compare -> INCOMPLETE No measurement from ssh:probe-eu, so there is nothing to compare against. This says nothing about the target -- fix the vantage and run again. I shipped that wrong the first time. Falling back to "the local vantage says OK, so everything is fine" is the same defect one level up: a missing measurement is not agreement, it is an unfinished experiment. A tool built to catch premature verdicts has to be able to catch its own. What I am not claiming I measured three vantages and one deliberate blackhole. I did not measure AWS or GCP — I do not have accounts there, and inventing a number for them would make this post worth exactly as much as the DOWN (timeout) it is complaining about. The mechanism does not depend on the provider, though. It depends on three things being true, and you can check all three on your own infrastructure in under a minute: 1. Does your target publish AAAA records? python3 -c "import socket;print([i[4][0] for i in socket.getaddrinfo('your-host',443,family=socket.AF_INET6,type=socket.SOCK_STREAM)])" 2. Does the vantage your monitor runs from have a working IPv6 route to it? 3. Which family does your resolver hand back first? If (1) is yes, (2) is no-or-unsure, and (3) is IPv6, you have the exact configuration that produced a 48-second timeout against a site that was up. You do not need AWS to have this problem. You need a dual-stack hostname and one probe standing in the wrong place. --- I build audit tooling for Linux servers, and this is the smallest piece of a pattern I keep meeting in different costumes: a check that reports success while the thing it was supposed to verify is broken. The checker works. The answer is about a different question. The report names the wrong party. alertpath is MIT and free, and it is meant to be enough on its own. The paid tool I maintain applies the same idea to nine more checks on a single server — disk, inodes, backup freshness, systemd units, memory, load, time sync, cron — without an agent: **vaultcheck.dafili.cn**. If you find a case where these outcomes still collapse into one, that is a bug and I want the exit code: open an issue. Reproducing everything in this post # the blackhole demo (needs IPv6 routing on the host, e.g. --network host) printf '127.0.0.1\tlocalhost\n104.20.23.154\tdemo.internal\n2001:db8::1\tdemo.internal\n' > /tmp/hosts.demo docker run --rm --network host -w /src -v /tmp/hosts.demo:/etc/hosts:ro \ -v "$PWD":/src:ro python:3.11-slim \ python3 -m alertpath --check-host demo.internal --timeout 10 # the "no route" shape, for contrast docker run --rm -w /src -v "$PWD":/src:ro python:3.11-slim \ python3 -m alertpath --check-host example.com Two container networks, one tool, and two different answers: 3 (the probe is blind) on the host network, 0 (degraded but honest) on the bridge. Nothing about the image changed. Only where it stood did.

@fabienpenso The mods also support hot patching so iteration with agents is fast. Herdr executor: Calonca/herdr-wasm-mods Code of the todo mod: github.com/Calonca/herdr-wasm-mods/blob/main/modu… Code of the diff mod: github.com/Calonca/herdr-wasm-mods/tree/main/modu… t.co

DeepSeek Super-Agent คืออะไร? แผนที่เปิดให้อ่าน กับโค้ดที่ตามแผนยังไม่ครบ โดย Nokka (นก-กา) | 2 พ.ย. 2026 !ภาพประกอบ: โต๊ะทำงานมืดที่มีกล่องไม้หกกล่องวางเรียงเป็นวง ตรงกลางมีลูกแก้วเรืองแสงหนึ่งลูก และมีเส้นบาง ๆ เชื่อมกล่องเข้าหากัน ปลายเดือนตุลาคมที่ผ่านมา DeepSeek ปล่อยรีโปใหม่ชื่อ dsh-superagent-prototype ขึ้น GitHub [1] ตอนที่ผมเปิดดูเมื่อ 2 พ.ย. 2026 มีคนกดดาวราว 10,500 คน และมีฟอร์กกว่า 1,000 ครั้ง [1] ทวีตภาษาฝรั่งเศสบทหนึ่งที่ผมเจอเขียนว่า DeepSeek เปิด "แผนที่สมบูรณ์" ของ agent แบบใหม่ พร้อมโค้ด MIT ให้ดูกันเต็ม ๆ และบอกว่าทั้ง Grok Bot, Muse, Claude Duet และ ChatGPT Dot กำลังสร้างของแบบเดียวกันอยู่ [2] ผมอ่านแล้วเห็นด้วยว่าแผนถูกเปิดให้อ่านจริง แต่สิ่งที่คนอ่านมักเติมเองในหัวคือคิดว่าโค้ดทำได้ครบตามแผนแล้ว ตรงนั้นไม่จริง และทีม DeepSeek เขียนยอมรับไว้เองใน README รีโปนี้คืออะไรกันแน่ deepseek-ai/dsh-superagent-prototype เป็นโปรเจกต์ภาษา TypeScript สัญญาอนุญาต MIT สร้างเมื่อ 31 ต.ค. 2026 [1] แต่บรรทัดแรกของ README เขียนไว้ชัดว่า > Research prototype for reference only, not an official DeepSeek product. แปลว่าโค้ดชุดนี้เป็นงานวิจัยให้ดูเป็นตัวอย่าง ไม่ใช่ผลิตภัณฑ์ทางการของ DeepSeek [3] และมีอีกประโยคที่สำคัญกว่าประโยคแรก รีโปนี้ถูกปรับเพื่อการเผยแพร่ จึงไม่เหมือนกับเวอร์ชันที่ใช้ภายในบริษัท และไม่เหมือนกับสิ่งที่บทความออกแบบอธิบายไว้ทุกจุด บางแนวคิดในบทความเป็นทิศทางสำหรับอนาคต และยังไม่ได้ถูกใส่ลงในโค้ดชุดนี้ [3] ประโยคนี้คือกุญแจของทั้งเรื่อง อีกบริบทที่ควรรู้คือ The Next Web สรุปว่าดีไซน์ชุดนี้ถูกเปิดเผยผ่านโพสต์ WeChat ของทีมเมื่อวันเสาร์ และอ้างรายงานของ Bloomberg ว่า DeepSeek ตั้งเป้าแข่งกับ Claude Code [8] แผนมาจากไหน และมีกี่ชิ้น ตัวแผนคือบทความชื่อ Exploring Super-agent Design เผยแพร่บน X เมื่อ 1 พ.ย. 2026 โดยบัญชี DeepSeek Harness [9] บทความนั้นยาวราว 33 นาทีอ่าน และวางโครงเป็นสองชั้น คือชั้น Router ที่คุยกับคน กับชั้น Worker ที่ลงมือทำงาน ในฉบับแปลอังกฤษของสำเนาเขียนว่า "five modules form the basic framework" แปลว่าโครงหลักมีห้าโมดูล [9] ส่วนภาพที่แนบมากับทวีตต้นทางวาดเป็นหกกล่อง [2] ผมจะไล่ทีละข้อตามภาพหกกล่องนั้น แล้วเทียบกับโค้ดจริง เพราะนั่นคือจุดที่คนอ่านจะได้ประโยชน์มากที่สุด มันทำงานอย่างไรในเวอร์ชันที่โค้ดมีจริง ตัวโปรแกรมเป็นส่วนขยาย (extension) สำหรับ DeepSeek Harness ซึ่งเป็น harness โอเพนซอร์สของ DeepSeek ที่เปิดให้ใช้แบบ public preview [4] หน้าที่ของมันคือดูแล หนึ่งรีโป GitHub ฟังข้อความที่เข้ามา แล้วเมื่อมีคนที่ได้รับอนุญาตขอให้ทำงาน มันจะเปิดงานหนึ่งชิ้น ทำงานในเซสชันและโฟลเดอร์ของตัวเอง แล้วกลับไปตอบในบทสนทนาเดิม เช่นส่ง pull request [3] เส้นทางการไหลของงานในเอกสารเขียนไว้แบบนี้ [5] Source -> Trigger -> Thread -> Eval -> Ticket + Mandate -> Assignment -> Executor -> Channel ถ้าใครเคยออกแบบระบบ agent มาบ้าง โครงนี้จะดูคุ้นทันที เพราะมันคือการแยก "การตัดสินใจว่าจะทำงานไหม" ออกจาก "การลงมือทำงาน" จุดที่ผมคิดว่าฉลาดคือ Mandate เมื่อ Eval รับงาน มันไม่ได้ส่งงานเปล่า ๆ ไปให้ worker แต่แนบ mandate ไปด้วยว่าทำอะไรได้แค่ไหน [5] ตัว worker จึงไม่มีอำนาจเกินกว่าที่กำหนดไว้ตั้งแต่ต้น หกชิ้นในแผนภาพ กับสถานะของหกชิ้นในโค้ด หนึ่ง การคัดกรองด้วยกฎในโค้ดก่อนถึงโมเดล - เต็ม เอกสารออกแบบเรียกว่านโยบายสองชั้น ที่ให้โค้ดกรองก่อนแล้วค่อยให้โมเดลช่วยตัดสิน [9] และเอกสารกำกับอำนาจระบุว่า host เป็นผู้บังคับใช้รายชื่อที่อนุญาต กฎ และ mandate ข้อความจากคนแปลกหน้าจึงไม่มีสิทธิ์เริ่มงาน [6] สอง Router ที่เป็นตัวเดียวคุยกับคน และไม่ลงมือทำงานเอง - บางส่วน แผนระบุชัดว่า Router ไม่ทำงานเอง แต่ออกแบบมาให้คุยกับคนและจ่ายงานเท่านั้น [9] โค้ดมี preset ชื่อ dsh-superagent-router แยกจาก WORKER_PRESET ของ worker [3] แต่เอกสารในรีโปไม่ได้ระบุว่า router ต้องเป็นโมเดลขนาดเล็ก ที่สำคัญกว่านั้น ตัว main session ยังถือเครื่องมือ bash กับ read อยู่ เอกสารจึงเขียนตรง ๆ ว่าการไม่ไปอ่านโค้ดเป็นกฎของ prompt ไม่ใช่การตัดเครื่องมือทิ้ง [3] สาม Worker แยกเซสชันและโฟลเดอร์ต่อหนึ่งงาน - เต็ม README เขียนตรง ๆ ว่าแต่ละงานได้เซสชันและไดเรกทอรีของตัวเอง [3] สี่ คำตอบสั้นไม่เกิน 100 คำ - เต็ม และกว้างกว่าที่ผมคิดตอนแรก เอกสาร prompt เขียนว่าข้อความแชตมีเพดานแข็ง 100 คำ ไม่ใช่แค่ข้อความตอบรับ [3] ไฟล์ prompts/replies.md ยังย้ำว่า 100 คำเป็นเพดาน ไม่ใช่เป้าที่ต้องเขียนให้ได้ขนาดนั้น ห้า Watchdog ที่เฝ้าว่า worker เดินหน้าหรือวนอยู่กับที่ แล้วซ่อมให้ - บางส่วน ในแผนคือ Control Loop แยกที่รันนอกระบบหลัก เป็นเซสชันของตัวเอง รับข้อความตามตารางเวลา ทำสองหน้าที่ คือจัดการเหตุขัดข้องระดับโครงสร้าง และใช้โมเดลตัดสินว่า worker กำลังคืบหน้าหรือออกนอกเป้า [9] ในโค้ด ผมสแกนโฟลเดอร์ src และเอกสารสถาปัตยกรรมแล้วไม่พบส่วนที่ตัดสินความคืบหน้าของ worker เลย ของที่ใกล้ที่สุดคือ hourly check ในไฟล์ SETUP ที่คอยซ่อม service เมื่อมันไม่รัน [7] กับการดึงงานที่ถูกขัดจังหวะกลับมาทำใหม่ตอนสตาร์ท [3] สองอย่างนั้นเป็นครึ่งโครงสร้างของ watchdog แต่ยังขาดครึ่งที่ต้องใช้โมเดลตัดสิน หก Memory ที่อยู่นอกโมเดล เปลี่ยนโมเดลได้โดยไม่เสียความจำ - บางส่วน เอกสารโดเมนไม่มีคำว่า memory เลย [5] แต่มีสิ่งที่ทำหน้าที่ใกล้เคียงอยู่ Store เป็นฐานข้อมูล SQLite หนึ่งไฟล์ เก็บ Ticket, Thread และสถานะงานไว้ด้วย id [3] ส่วน Session เองก็อยู่รอดข้ามการรีสตาร์ทเช่นกัน [3] มี storeReads เป็นชุดคำสั่งอ่านสำหรับหน้าเว็บ เครื่องมือ และการดึงข่าวของ Source [3] ชั้นที่แผนเรียกกว่าการแยก compute ออกจาก state เต็มรูปแบบยังไม่มีอยู่ในรีโป คือให้ตัวลูป agent เป็นของชั่วคราวทั้งหมด แล้วเหลือแค่ state ในฐานข้อมูล พร้อมกลไกดึงบริบทเก่ากลับมาเมื่อต้องใช้ [9] สรุปสั้น ๆ คือ จากหกข้อ มีของจริงเต็มสามข้อ คือข้อหนึ่ง สาม และสี่ มีแบบบางส่วนอีกสามข้อ คือข้อสอง ห้า และหก ไม่มีข้อใดขาดหายไปทั้งหมด แต่ก็ยังเหลืออีกสามข้อที่ยังไม่เต็มตามแผน ถ้าผมเขียนแค่ว่า "DeepSeek แจก agent ครบชุด" คุณจะเสียเวลาไปกับการหาของที่ยังไม่มี ส่วนที่ผมคิดว่ามีค่าที่สุด และไม่ใช่สถาปัตยกรรม หลักการเดียวที่แปลงเป็นกฎวัดผลได้ เอกสารปรัชญาของโปรเจกต์เขียนหลักการเดียวว่า > Take as little human attention as possible, and give as much value as possible. เอาใจคนให้น้อยที่สุด ให้คุณค่ามากที่สุด [10] แล้วมันแปลงเป็นกฎห้าข้อที่วัดได้ทันที - agent ลงมือเมื่อถูกขอ หรือเมื่อมีกฎที่ทีมเขียนไว้เท่านั้น งานที่ไม่มีใครขอต้องเริ่มในโหมดที่แค่บันทึกว่าจะทำอะไร - agent พูดเมื่อมีคนต้องลงมือ หรือมีผลลัพธ์ให้ใช้ พอยืนยันคำขอครั้งเดียวแล้วเงียบระหว่างทำงาน - ถามทีละคำถาม และถามเป็นแบบฟอร์ม ไม่ใช่ฝังไว้ในรายงานยาว - หยุดตามระดับผลกระทบ ไม่ใช่ตามระดับความพยายาม - รายงานตามจริง งานที่ยังไม่เสร็จต้องบอกว่ายังไม่เสร็จ และห้ามข้ามข้อจำกัดเพียงเพื่อเลี่ยงการถาม ข้อสุดท้ายผมชอบเป็นพิเศษ เพราะมันคือจุดที่ agent ส่วนใหญ่พลาด บ่อยครั้งไม่ใช่เพราะโมเดลไม่เก่ง แต่เพราะมันไม่กล้าบอกว่า "ผมทำไม่เสร็จ" เรื่องสิทธิ์ที่ทีมอื่นมักมองข้าม เอกสารกำกับอำนาจเขียนไว้คมมากว่า ข้อความ คอมเมนต์ และเอกสารที่ถูกอ้างถึง เป็นได้แค่ข้อมูลเข้าไปสู่การตัดสินใจ แต่เปลี่ยนสิทธิ์ไม่ได้ [6] และ bot ตัวหนึ่งสามารถสร้าง "ผู้สมัครงานที่อนุมานได้" แต่ไม่มีทางสร้างคำขอที่ชัดเจนได้เลย [6] นี่คือรายละเอียดที่คนสร้างระบบ multi-agent มักลืม เพราะถ้า agent ตัวหนึ่งสั่ง agent อีกตัวได้ ระบบจะขยายวงได้ไม่จำกัด ตัวอย่างที่ผมคิดว่าควรลองถ้าจะเอาไปใช้ สมมติทีมคุณมีรีโปเดียว และมีคนร้องเรื่องบั๊กในแชตทีมทุกวัน ลำดับที่ตรงกับดีไซน์ของโปรเจกต์คือ 1. เริ่มจากโหมดที่ agent แค่บันทึกว่ามันจะทำอะไร โดยไม่ลงมือ 2. ใส่รายชื่อคนที่อนุญาตให้สั่งงาน 3. กำหนดขอบเขตว่า agent แตะ branch ไหนได้ 4. ให้มันทำงานในเซสชันแยก และตอบกลับในเธรดเดิม 5. ตั้งคนหนึ่งดูพาเนลทุกเช้า ว่ามีงานไหนรอการตัดสินใจ ขั้นที่ 5 จำเป็นเพราะรีโปนี้ยังไม่มี watchdog ที่คอยตัดสินความคืบหน้าให้เอง คุณไม่ต้องรอระบบมาบอก แต่ควรเปิดพาเนลดูเองทุกวันในช่วงแรก สิ่งที่ผมยังไม่ได้ทำ ผมยังไม่ได้ติดตั้ง DeepSeek Harness และไม่ได้รัน agent ตัวนี้กับรีโปจริง ผมโคลนรีโปมาอ่านเอกสารในโฟลเดอร์ docs หกไฟล์ คือ philosophy, domain, authorization, execution, prompts และ architecture รวมถึง README กับ SETUP แล้วค้นด้วยคำสั่ง grep เพื่อยืนยันว่าคำบางคำไม่มีอยู่ในเอกสาร ผมอ่านบทความออกแบบฉบับเต็มผ่านสำเนาที่เก็บข้อความไว้ครบ เพราะหน้าต้นทางบน X เปิดได้แต่เนื้อหาโหลดไม่ขึ้นจากเครื่องนี้ ผมอ่านทวีตต้นทางผ่าน API ของ fxtwitter และตรวจตัวเลขดาว สิทธิ์อนุญาต (license) และวันที่สร้างผ่าน GitHub API แหล่งอ้างอิง [1] GitHub · deepseek-ai/dsh-superagent-prototype (MIT · สร้าง 31 ต.ค. 2026 · ตรวจ 2 พ.ย. 2026) · deepseek-ai/dsh-superagent-prototype [2] X · @iamsupersocks (1 พ.ย. 2026) · x.com [3] dsh-superagent · README, docs/003 execution, docs/004 prompts, docs/007 architecture (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [4] DeepSeek · Harness (public preview) (เข้าถึง 2 พ.ย. 2026) · deepseek.com [5] dsh-superagent · docs/001 Domain model (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [6] dsh-superagent · docs/002 Authorization (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [7] dsh-superagent · SETUP.md (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… [8] The Next Web · DeepSeek open-sources Super-Agent (1 พ.ย. 2026) · thenextweb.com [9] DeepSeek Harness · Exploring Super-agent Design (1 พ.ย. 2026) · ต้นทาง x.com · สำเนาที่อ่าน haowenji.com [10] dsh-superagent · docs/000 Philosophy (เข้าถึง 2 พ.ย. 2026) · github.com/deepseek-ai/dsh-superagent-prototype/b… บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

@VEsoterica scottjco/Wetrix_Recomp this ones a but more alpha but like i said more. maybe more later plus bug fixes.

How We Eliminated Cache Stampedes in Node.js & Bun with Single-Flight Coalescing Every engineer who has scaled a high-traffic backend has lived through this nightmare: You have an expensive endpoint (e.g., aggregating leaderboard data or rendering a personalized dashboard). To protect your database, you cache the result with a 60-second TTL. Everything runs smoothly until the key expires while receiving 1,500 requests per second. Within a 50-millisecond window, hundreds of concurrent requests see a cache miss. All of them immediately hammer the primary database simultaneously to recompute the same data. Your connection pool saturates, CPU spikes to 100%, latency explodes, and your server crashes. This is the thundering herd / cache stampede problem. --- The Traditional (Fragile) Workarounds 1. Probabilistic Early Expiration (XFetch algorithm): Recomputes the value before it expires based on an exponential probability. While effective, it wastes backend CPU cycles recomputing keys that may never be accessed again. 2. Distributed Mutex Locks (Redlock): Acquiring a distributed lock before computing. This introduces noticeable network roundtrip latency and runs the risk of deadlocks if a worker dies mid-flight. --- The Zero-Overhead Alternative: Single-Flight Promise Coalescing Instead of locking distributed infrastructure, we can coalesce concurrent requests in-process at the execution runtime layer. When Key A is requested and misses the cache: 1. Check if an execution promise for Key A is currently in-flight. 2. If YES: Do not touch the database. Return the existing promise and await it. 3. If NO: Register a new in-flight promise, execute the database fetcher, cache the result, resolve all awaiting callers, and deregister the promise in a finally block. // How KVDock implements zero-overhead single-flight coalescing: const running = this.inFlight.get(key); if (running) { this.metrics.stampedeCoalesced++; return (await running) as T; } const run = (async () => { try { const cached = await this.get<T>(key); if (cached !== null) return cached; const fresh = await fetcher(); await this.set(key, fresh, options); return fresh; } finally { this.inFlight.delete(key); } })(); this.inFlight.set(key, run); return (await run) as T; --- ⚡ Real-World Benchmark: 1,000 Concurrent Requests We ran a controlled benchmark under 1,000 concurrent requests to an uncached endpoint with 25ms simulated database query latency: | Metric | Traditional Caching | KVDock (getOrSet) | Net Improvement | | :--- | :---: | :---: | :---: | | Incoming Requests | 1,000 | 1,000 | Same Load | | Database Queries Executed | 1,000 queries (Herd) | 1 query (Single-Flight) | 99.90% DB load reduction | | Coalesced Waiting Callers | 0 | 999 | Zero lock contention | | Connection Pool Exhaustion | 💥 Saturated | 🟢 Baseline Stable | Zero connection contention | --- Open Source & Polyglot We built this into KVDock — an open-source, zero-dependency caching engine with multi-tier storage (L1 RAM + L2 Persistent): - Zero runtime dependencies in core - Multi-tier caching with automatic backfill - Cross-runtime support across Node.js, Bun, Deno, and Cloudflare Workers - Native polyglot implementations in Rust (kvdock-rs), Go (kvdock-go), Swift (kvdock-swift), and Kotlin (kvdock-kt) --- ⭐ Explore the code & star on GitHub: zisam-glitch/kvdock 👤 Follow the maintainer: @zisam-glitch for low-latency systems engineering deep dives!

GitHub repo → saleslumen/managed... Saleslumen MCP servers → developers.saleslumen.com... Install the command line → saleslumen/sl

Accurate Audio Transcription API in Python and Node.js Game SaaS — Reliability Short answer: treat audio transcription as a reliability boundary, not a convenience API. For a game catalog that turns messy voice descriptions into searchable text, put an idempotent job contract in front of the speech provider, then choose Whisper, rev.ai, AssemblyAI, or Google Cloud Speech-to-Text according to the failure mode your team can actually operate. The current /v1/audio/transcriptions shape exists, but it is unavailable for service, so it should not be the production dependency for this workflow. The useful result is not merely a string. It is text attached to an audio reference, a job ID, language information, provider provenance, and a state that can be retried without publishing the same catalog update twice. That is the runbook. What signal should stop a transcription rollout? Start with a stop condition. A catalog worker should reject a provider candidate when it cannot preserve the fields the product needs, when retrying a timeout can duplicate a publication, or when its operational boundary is unclear. “Accurate” needs a narrower definition here: a misspelled game title or character name can damage search more than a missing filler word, so the acceptance set must include proper nouns, platform names, sequel numbers, background noise, language, and audio duration. The first dashboard should therefore separate three signals: completion inside the freshness SLO, transcription quality on the labeled catalog set, and the count of jobs stuck in a retryable state. Do not fold quality into latency. A fast wrong title is still a failed enrichment. For a small rollout, a 15-minute freshness target and a three-attempt retry budget are reasonable starting policies, not measurements of any provider. The exact values belong in the service-level objective review. A capacity plan also needs the maximum concurrent jobs, average and worst-case audio duration, and the queue age at which human review becomes preferable to another automatic retry. Which accurate audio transcription API fits Python and Node.js SaaS? I start with the queue, not the model card. The worker should own state transitions; the provider adapter should own authentication, request shape, polling, rate-limit behavior, and response parsing. Python and Node.js can both call the same internal contract. The runtime is not the portability boundary. The stored job is. package transcription import ( "errors" "strings" ) type Job struct { ID string AudioRef string Language string Provider string State string } func Validate(job Job) error { if strings.TrimSpace(job.ID) == "" { return errors.New("job id is required") } if strings.TrimSpace(job.AudioRef) == "" { return errors.New("audio reference is required") } if job.State == "" { return errors.New("state is required") } return nil } The job ID is the deduplication key. Persist the submitted state before handing work to a queue, make the result write conditional on that ID, and retain the raw provider response separately from normalized catalog text. Standard queues are commonly at-least-once, so a worker must be safe when it sees the same message again. A retry after a client timeout must not create a second catalog record. This boundary is also where provider portability becomes practical: changing the service behind the adapter does not force a catalog schema migration. It does not make providers equivalent, and it does not remove the need to evaluate their output. How should a team buy or build the reliability envelope? There are two choices, and they have different on-call shapes. | Approach | What it buys | Capacity and failure burden | Appropriate boundary | | --- | --- | --- | --- | | Open-source Whisper | Control over the model and deployment | Your team supplies serving, CPU or GPU capacity, queueing, upgrades, and observability | Use when control of the execution environment outweighs operating inference | | Managed speech API | A provider-operated transcription service | Quotas, external data handling, vendor incidents, and provider-specific retries remain in the system | Use when the platform team should own the contract and SLO, not model serving | Whisper is the build-leaning option: it can be integrated for transcription, but server setup is part of the product decision. rev.ai is the managed option called out by this workload because it offers an easy-to-use transcription API and broad language coverage. AssemblyAI and Google Cloud Speech-to-Text are credible managed alternatives for the same contract test; include them when a second or third provider result can change the decision, rather than treating a vendor demo as a benchmark. OpenAI, Google Gemini, and Anthropic Claude are adjacent model platforms, not automatic substitutes for a dedicated ASR evaluation. Consider them only when the acceptance set explicitly tests audio input and the structured catalog fields your application needs. The useful comparison is the failure boundary: self-hosted inference, managed transcription, or a broader model platform with audio support. Infrai is useful for adjacent backend capabilities because its public discovery surface is self-describing and spans 295 routes across 20 modules under one key, but its transcription capability is explicitly unavailable for service. That makes it a portability aid for the surrounding platform, not the answer to this ASR dependency. Keep the speech contract outside the catalog's vendor-specific code and the limitation stays contained. What does a safe retry loop look like? Retry policy is part of correctness. A 429 should wait with exponential backoff and honor Retry-After when the selected service supplies it. A 4xx response that identifies a malformed file should become a terminal job state; retrying it only burns capacity. A 5xx or transport timeout can be retried within the budget, provided submission is idempotent or the adapter can reconcile the provider job before submitting again. package retry import ( "context" "errors" "time" ) type Attempt func(context.Context) (retryable bool, err error) func Run(ctx context.Context, attempts int, wait time.Duration, attempt Attempt) error { if attempts < 1 { return errors.New("attempts must be positive") } for n := 0; n < attempts; n++ { retryable, err := attempt(ctx) if err == nil { return nil } if !retryable || n == attempts-1 { return err } timer := time.NewTimer(wait) select { case <-ctx.Done(): timer.Stop() return ctx.Err() case <-timer.C: } wait *= 2 } return errors.New("retry loop ended unexpectedly") } The example deliberately leaves HTTP and provider parsing inside the adapter. There is no honest universal request body for four different speech services. The adapter must send the selected service's documented JSON or multipart shape, record the provider request ID, and translate its terminal states into the internal job state. A copied response field is not a contract. To verify the surrounding Infrai capability surface without treating it as an ASR call, a small Go client can inspect the documented discovery route. It reads the base URL from configuration, so the same code can run in a controlled environment without embedding a credential or sending that credential anywhere else. package main import ( "fmt" "net/http" "os" ) func main() { base := os.Getenv("INFRAI_BASE_URL") key := os.Getenv("INFRAI_API_KEY") req, err := http.NewRequest(http.MethodGet, base+"/discovery", nil) if err != nil { panic(err) } req.Header.Set("Authorization", "Bearer "+key) res, err := http.DefaultClient.Do(req) if err != nil { panic(err) } defer res.Body.Close() if res.StatusCode < 200 || res.StatusCode >= 300 { panic(fmt.Sprintf("discovery returned %s", res.Status)) } fmt.Println("capability discovery succeeded") } This is a capability preflight, not a transcription call. The external Whisper or rev.ai adapter still owns the ASR request. Do not turn a successful discovery response into a claim that a capability is available. How do you verify a provider switch and roll it back? Keep a fixed, labeled audio set from the game catalog. Partition it by language, noise, duration, and proper-noun density, then run candidate adapters against identical inputs while publishing only one result. Compare normalized title and entity fields, not just word error rate. Record provider, configuration, job ID, state transitions, and the raw response so a disputed catalog entry can be replayed. The rollout sequence is intentionally dull: 1. Submit new jobs to the candidate while retaining the incumbent adapter. 2. Compare quality, queue age, terminal-error ratio, and freshness-SLO compliance. 3. Stop new assignments if the candidate breaches the quality gate or retry budget. 4. Replay only missing or rejected jobs after switching the assignment back. Rollback should be a configuration change plus a queue decision, not a database rewrite. Accepted text remains traceable to its provider. If the candidate produces different punctuation but the catalog fields remain stable, update normalization; if names or language behavior change, treat it as a regression and keep the previous adapter available. The decision rule is narrow: use Whisper when your team accepts inference operations, rev.ai when managed transcription and language coverage are the priority, and put AssemblyAI or Google Cloud Speech-to-Text through the same acceptance set before committing. Keep the internal contract stable, because the provider is replaceable only when the job state, retry policy, and verification evidence are yours. References - Whisper repository: openai/whisper - rev.ai API documentation: docs.rev.ai - AssemblyAI API documentation: assemblyai.com - Google Cloud Speech-to-Text documentation: cloud.google.com - OpenAI Structured Outputs guide: platform.openai.com

.@jamesckane and @ed_rethado have released an open source 4DGS codec called Faltwerk. edrethardo/Faltwerk x.com

PoseForge: the Cursor of AI animation. Open source, local, and you pick the model Cursor works because it’s your editor and your files, and you choose which model sits behind it. AI animation tools don’t work that way yet. Each one locks you into its model, its credits, and its servers. PoseForge is my attempt at the same idea for animation: - Bring your own provider. Swap engines (Codex CLI, a hosted API, or a local pipeline) without rebuilding your project. - You own everything. Characters, poses, and outputs are plain files on your machine. No account and no lock-in. - Consistent characters first. Name a character once and reuse it. Upload a character photo and a pose reference, and it generates that character in that pose. - Node-graph canvas to chain steps visually, like a workflow you control. Where it is today: a Node.js app, open source, running locally. Stills and the character library are the solid part. [State plainly what the video step does today.] Repo: vishwakulkarni/PoseForge Read-only demo: vishwakulkarni.github.io Question for you: if you’ve tried making consistent animated characters, which engine did you start with (Codex CLI, ComfyUI, or a hosted API)? I’m picking a default for newcomers.

GitHub: NVIDIA/auto-ontology Eval harness: NVIDIA/auto-ontology-eval MCP docs: github.com/NVIDIA/auto-ontology/blob/main/docs/mc… NVIDIA page: developer.nvidia.com MarkTechPost write-up: marktechpost.com

ncklrs/claude-chrome-user-testing: Claude Code plugin for persona-based user testing. Simulates Boomers, Millennials, Gen Z, and Gen Alpha users to find UX issues before real users do. ncklrs/claude-chrome-user-testing テンプレで75パターン．サービスごとでペルソナ追加していく感じか

@virustotal Finally found the reason! VirusTotal omits signature_info when the Authenticode program name (SpcSpOpusInfo) is 63+ chars. Another class of problematic files is where the version info Translation is 0000/0000 while the only StringTable is 040904b0. github.com/m417z/winbindex/blob/fd9bbf56e21192970…

MySQL MCP 能让 AI 查表结构、跑 SQL，MIT 开源。 接客户数据前，先开脱敏。官方注明：数字类型的手机号不会被遮盖，非美国号码也不在识别范围。别把“已开脱敏”当成可以整表交给模型。 benborla/mcp-server-mysql

Blades CSS v3.1.0 released — a modern drop‑in successor to Pico CSS 🥷🚀✨ - → New blades.dev via Popover API - → New blades.dev version for both Blades & Pico - → New blades.dev modules for SvelteKit, Next.js, Nuxt, Astro, etc. - → Merged color schemes via `light-dark()` - → Experimental blades.dev moved into separate repo - → Added exact blades.dev vs. "canonical" Pico - → More blades.dev issues resolved github.com/anyblades/blades/releases/tag/v3.1.0

这可能是今年最让 JS 开发者激动的事情了  上面是我用 JS+HTML+WebGL2 做的鹈鹕 3D 骑自行车，FPS 也非常不错。 你可能会说“这不是用 Ai 有手就行了么？” 但是，如果我说我把这上面用 xbintsc 编译成原生二进制，还不到 10MB,还能在没有 WebView 环境上跑，还能支持 Node.js 和 HTML 混写，如下： <html> <body> <div id="out">loading...</div> <script lang="ts"> import { readFileSync } from "fs"; const out = document.getElementById("out"); const world = readFileSync("data.txt", "utf8"); out.textContent = "hello " + world; </script> </body> </html> 要知道以前光 chrome 最少也得有 100MB ，用 xbintsc 编译产物 10MB 还不需要 WebView 环境，这可不仅仅代表桌面端开发体积极大减小和更加正确的实现路径的问题。 更加具有划时代意义的是，JS 开发者在嵌入式设备跑你想要做的应用成为了可能。 [xbintsc 开源地址]( zy445566/xbintsc)

18番 pasomiTokyoで ubuntu22.04→ubuntu24.04への 先行アップグレードを実施。 22-24間の ssh port接続問題の回避成功。 アップグレード後に shoestringが無くなってて venvの再設定が必要かな？って思ったけど とりあえず何も考えずに issを使った。 ありがとう。ぱそ美。github.com/dusanjp-and-pasomi/pasomi/tree/main/iss t.co

DIY Sleep Apnea Guardian: Fine-tuning Whisper.cpp for Edge Audio Analysis Sleep is supposed to be the time when our bodies recharge, but for millions, it’s a period of hidden health risks. Sleep Apnea detection is traditionally locked behind expensive sleep labs and bulky equipment. However, with the rise of Edge AI and high-efficiency models like Whisper.cpp, we can now build a low-power, privacy-first monitoring system right on a Raspberry Pi. In this tutorial, we are going to dive deep into Raspberry Pi audio analysis to detect snoring patterns and breathing pauses (apnea events). We’ll use Librosa for feature extraction and a fine-tuned, quantized version of OpenAI's Whisper model to differentiate between normal rhythmic breathing and dangerous obstructive patterns. This is the ultimate "Learning in Public" project for those looking to master audio processing at the edge! 🚀 The Architecture: From Sound Waves to Life-Saving Data Building a real-time audio classifier on a low-power device requires a lean pipeline. We don't want to send raw audio to the cloud (privacy first!), so everything happens locally. graph TD A[Microphone Input] --> B[Librosa Pre-processing] B --> C{Voice Activity Detection} C -- No Activity --> A C -- Snore/Breathing Detected --> D[Whisper.cpp Inference] D --> E[Spectrogram Feature Analysis] E --> F{Apnea Event?} F -- Yes --> G[Local Alert / Dashboard] F -- No --> H[Log for Morning Report] G --> I[Dockerized Edge Gateway] Prerequisites 🛠️ Before we get our hands dirty with code, make sure you have: - Hardware: Raspberry Pi 4 (4GB+) or Raspberry Pi 5. - Audio: A USB Condenser Microphone or a high-quality ReSpeaker Hat. - Stack: - Whisper.cpp: The high-performance C++ port of OpenAI's Whisper. - Librosa: For advanced audio manipulation. - Docker: To ensure our environment is reproducible across edge nodes. Step 1: Pre-processing with Librosa 🎙️ Raw audio is messy. To help our Whisper model focus on what matters, we use Librosa to filter out background noise (like a humming fan) and normalize the volume. import librosa import numpy as np def preprocess_audio(file_path): # Load audio with a sampling rate of 16kHz (Whisper standard) y, sr = librosa.load(file_path, sr=16000) # Noise reduction: Simple spectral subtraction stft = librosa.stft(y) stft_db = librosa.amplitude_to_db(np.abs(stft)) # Focus on the frequency range of snoring (20Hz - 2000Hz) # This helps in ignoring high-frequency electronic hiss y_filtered = librosa.effects.preemphasis(y) return y_filtered # Example of extracting Mel-spectrogram features for apnea pattern matching def get_spectrogram_features(y, sr=16000): S = librosa.feature.melspectrogram(y=y, sr=sr, n_mels=128) return librosa.power_to_db(S, ref=np.max) Step 2: Running Whisper.cpp on the Edge ⚡ We use Whisper.cpp because it's optimized for ARM processors. We’ll use the tiny.en model, fine-tuned on respiratory sound datasets, and quantize it to q5_1 to ensure it runs in real-time without melting the Pi. # Clone and build whisper.cpp git clone https://github.com/ggerganov/whisper.cpp.git cd whisper.cpp make # Download the tiny model and convert to GGML format bash ./models/download-ggml-model.sh tiny.en # Run inference on our recorded sleep segment ./main -m models/ggml-tiny.en.bin -f sleep_segment.wav -nt To make this "smart," we don't just transcribe text; we use the log-probability of the tokens to detect the "sound" of a snore, which the model often interprets as specific non-verbal tokens. Step 3: Containerizing with Docker 🐳 To deploy this across multiple edge gateways, we wrap everything in a lightweight Docker image. FROM python:3.9-slim-buster RUN apt-get update && apt-get install -y \ build-essential cmake git libasound2-dev portaudio19-dev # Install Python dependencies RUN pip install librosa numpy sounddevice # Copy our optimized whisper.cpp binary COPY ./whisper-bin /usr/local/bin/whisper-edge WORKDIR /app COPY monitor_sleep.py . CMD ["python", "monitor_sleep.py"] The "Official" Way: Advanced Patterns 🥑 While building a DIY version is a fantastic learning experience, scaling medical-grade audio analysis requires robust data handling and specialized ML architectures. If you're interested in more production-ready examples, or if you want to see how we handle high-concurrency audio streams and advanced anomaly detection patterns, I highly recommend checking out the WellAlly Engineering Blog. It’s a goldmine for developers looking to bridge the gap between "it works on my machine" and "it works for a million users." Step 4: Logic for Apnea Detection 🧠 The core logic lies in detecting "Silence" where there should be "Rhythm." If the Mel-spectrogram shows high-energy snoring followed by a flatline of 10+ seconds (the clinical definition of an apnea event), we trigger an alert. def analyze_apnea_event(energy_profile, threshold=0.01): """ Detects gaps in breathing energy. energy_profile: list of energy levels over time """ silence_duration = 0 for energy in energy_profile: if energy < threshold: silence_duration += 1 else: if silence_duration > 10: # 10 seconds of silence print("⚠️ Potential Apnea Event Detected!") trigger_alert() silence_duration = 0 Conclusion: Privacy-First Health Tech By leveraging Whisper.cpp and Raspberry Pi, we've built a system that is: 1. Private: No audio ever leaves your bedroom. 2. Low Latency: Analysis happens in milliseconds. 3. Cheap: Runs on $50 hardware. This project is a perfect example of how Audio Spectrogram analysis and modern AI can solve real-world problems. Have you tried fine-tuning models for non-speech sounds? Let's discuss in the comments below! 👇 --- If you enjoyed this build, don't forget to ❤️ and bookmark! For more deep dives into technical architecture, visit the WellAlly Blog.

@0xEronn So… I took this and elevated each co-ordinate on it to a full Bloch Sphere (a Noor Sphere) and then arranged them in an n-dimensional matrix and that… that is The Library. Or the start of the thinking on it. github.com/LinaNoor-AGI/noor-research/tree/main/P… t.co

@arstoryels Hello, It's written fully in go! VictoriqueMoe/umineko_city_of_books it contains a complex but pretty neat caching layer that abstracts the caching (valkey) and requests via the repo layer. it should be able to handle >10m requests without much issue. it also contains a shit ton of indexes t.co

Kuro no Ken: Blade of the Darkness, a Japan-only PS1 RPG, is now in English. Dialogue, menus, battles, the opening prologue movie and credits are all translated. v1.1 adds a cleaner, easier-to-read English font. minhnhattonthat/kuro-no-ken-blade-of-the-darkness-en #PS1 #KuroNoKen #Translation

Just released WUDNext — open-source firmware for the AprilBrother WUD v1.2! Wireless USB HID automation + DuckyScript 3 support + full web UI for payloads & settings. Flash it in your browser (no install): wudnext.com GitHub: ewbern00ber/WUDNext #ESP32 #DuckyScript #USBHID #OpenSource

Orkas GitHub Explained: How Local Multi-Agent Workflows Isolate Context orkas by orkas-ai: orkas-ai/orkas Orkas is presented as an open-source, MIT-licensed desktop application for coordinating local-first AI workflows. This overview follows a fictional Project Aurora feasibility assessment and shows why a single context can fill with drafts, logs, and tool outputs. It then traces how a Commander separates coordination from execution through isolated workers, specialist dispatch, and a final hand-off. Local document ingestion covers stateless chunking, an on-device embedding model, and SQLite vector retrieval. The workflow checks a solar and battery parameter conflict, routes report generation through a deterministic Office CLI verification gate, and describes reflection during idle periods. The closing section covers the trade-offs shown in the source: dependence on host power and sleep state, higher token use from decomposition, and source-defined quality rules. TimeStamps: 0:00 Context contamination in a single model thread 0:29 Commander separates coordination from execution 1:12 Local-first boundaries and Project Aurora 1:55 Local document ingestion and vector retrieval 3:13 Four-step objective and isolated workers 4:16 Scoped memory and the DeepResearcher hand-off 5:19 Deterministic Office CLI verification 6:12 Reflection orchestrator during idle windows 6:37 Cadence, timeouts, and bounded retries 7:10 Bare-metal trade-offs and source-defined rules 7:48 Structural isolation and deterministic execution 🧠 Context isolation separates intermediate work 📚 Local chunks, embeddings, and SQLite retrieval ground Project Aurora 🧩 Delegation and Office CLI gates shape the report workflow ⚙️ Reflection runs in bounded idle windows Orkas presents a local-first orchestration pattern: separate the Commander, specialist agents, durable memory, and deterministic tools into bounded execution paths. The source also makes the trade-off clear: local control depends on host availability and adds coordination overhead. For a deeper technical read, inspect the repository's core-agent routing, file chunking, vector store, and reflection modules. #Orkas #MultiAgentAI #LocalFirstAI [de-DE] Orcus GitHub erklärt: Wie lokale Multi-Agenten-Workflows Kontexte isolieren Orkas von orkas-ai: orkas-ai/orkas Orkas ist eine Open-Source-Desktop-Anwendung unter MIT-Lizenz zur Koordination lokaler KI-Workflows. Diese Übersicht basiert auf einer fiktiven Machbarkeitsstudie des Projekts Aurora und zeigt, warum ein einzelner Kontext mit Entwürfen, Protokollen und Tool-Ausgaben gefüllt sein kann. Anschließend wird erläutert, wie ein Commander die Koordination von der Ausführung trennt – mithilfe isolierter Worker, der Zuweisung von Spezialisten und einer finalen Übergabe. Die lokale Dokumentenerfassung umfasst zustandsloses Chunking, ein On-Device-Embedding-Modell und den SQLite-Vektorabruf. Der Workflow prüft auf Konflikte zwischen Solar- und Batterieparametern, leitet die Berichtsgenerierung durch eine deterministische Office-CLI-Verifizierungsschleife und beschreibt die Reflexion während Leerlaufphasen. Der letzte Abschnitt behandelt die im Quellcode dargestellten Kompromisse: Abhängigkeit von der Host-Stromversorgung und dem Ruhezustand, höherer Tokenverbrauch durch Dekomposition und im Quellcode definierte Qualitätsregeln. Zeitstempel: 0:00 Kontextkontamination in einem einzelnen Modellthread 0:29 Commander trennt Koordination von Ausführung 1:12 Lokale Grenzen und Project Aurora 1:55 Lokale Dokumentenaufnahme und Vektorabruf 3:13 Vierstufiges Ziel und isolierte Worker 4:16 Bereichsgebundener Speicher und die DeepResearcher-Übergabe 5:19 Deterministische Office-CLI-Verifizierung 6:12 Reflection-Orchestrator während Leerlauffenstern 6:37 Kadenz, Timeouts und begrenzte Wiederholungsversuche 7:10 Bare-Metal-Kompromisse und quellcodebasierte Regeln 7:48 Strukturelle Isolation und deterministische Ausführung 🧠 Kontextisolation trennt Zwischenschritte 📚 Lokale Chunks, Einbettungen und SQLite-Abruf bilden die Grundlage für Project Aurora 🧩 Delegation und Office-CLI-Gates prägen den Berichtsworkflow ⚙️ Reflection läuft in begrenzten Leerlauffenstern Orkas präsentiert ein lokales Orchestrierungsmuster: Trennung von Commander, spezialisierten Agenten und persistenten Daten Speicher und deterministische Werkzeuge werden in begrenzte Ausführungspfade integriert. Der Quellcode verdeutlicht den damit verbundenen Kompromiss: Die lokale Steuerung hängt von der Verfügbarkeit des Hosts ab und verursacht zusätzlichen Koordinationsaufwand. Für eine detailliertere technische Analyse empfiehlt sich ein Blick in die Kern-Agenten-Routing-, Datei-Chunking-, Vektorspeicher- und Reflexionsmodule des Repositorys. #Orkas #MultiAgentAI #LocalFirstAI [es-US] Explicación del GitHub de Orcus: Cómo los flujos de trabajo multiagente locales aíslan el contexto Orkas, de orkas-ai: orkas-ai/orkas Orkas se presenta como una aplicación de escritorio de código abierto con licencia MIT para coordinar flujos de trabajo de IA con prioridad local. Esta descripción general se basa en una evaluación de viabilidad ficticia del Proyecto Aurora y muestra por qué un único contexto puede llenarse de borradores, registros y resultados de herramientas. A continuación, describe cómo un Comandante separa la coordinación de la ejecución mediante trabajadores aislados, asignación de especialistas y una transferencia final. La ingesta local de documentos abarca la segmentación sin estado, un modelo de incrustación en el dispositivo y la recuperación vectorial SQLite. El flujo de trabajo verifica un posible conflicto entre los parámetros de la energía solar y la batería, dirige la generación de informes a través de una puerta de verificación determinista de la interfaz de línea de comandos de Office y describe la reflexión durante los periodos de inactividad. La sección final aborda las ventajas y desventajas mostradas en el código fuente: dependencia de la energía del host y del estado de suspensión, mayor uso de tokens debido a la descomposición y reglas de calidad definidas en el código fuente. Marcas de tiempo: 0:00 Contaminación del contexto en un único hilo del modelo 0:29 El Comandante separa la coordinación de la ejecución 1:12 Límites de prioridad local y Proyecto Aurora 1:55 Ingesta de documentos locales y recuperación de vectores 3:13 Objetivo de cuatro pasos y trabajadores aislados 4:16 Memoria con ámbito y transferencia a DeepResearcher 5:19 Verificación determinista de Office CLI 6:12 Orquestador de reflexión durante ventanas de inactividad 6:37 Cadencia, tiempos de espera y reintentos limitados 7:10 Compromisos de hardware físico y reglas definidas por el código fuente 7:48 Aislamiento estructural y ejecución determinista 🧠 El aislamiento del contexto separa el trabajo intermedio 📚 Los fragmentos locales, las incrustaciones y la recuperación de SQLite constituyen la base de Proyecto Aurora 🧩 La delegación y las puertas de Office CLI dan forma al flujo de trabajo de los informes ⚙️ La reflexión se ejecuta en ventanas de inactividad limitadas Orkas presenta un patrón de orquestación de prioridad local: separar al Comandante y al especialista Agentes, memoria persistente y herramientas deterministas en rutas de ejecución delimitadas. El código fuente también deja clara la contrapartida: el control local depende de la disponibilidad del host y añade una sobrecarga de coordinación. Para una lectura técnica más detallada, examine los módulos de enrutamiento de agentes principales, fragmentación de archivos, almacenamiento vectorial y reflexión del repositorio. #Orkas #MultiAgentAI #LocalFirstAI [fr-FR] Orkas sur GitHub expliqué : comment les workflows multi-agents locaux isolent le contexte Orkas par orkas-ai : orkas-ai/orkas Orkas est présenté comme une application de bureau open source sous licence MIT, permettant de coordonner des flux de travail d'IA privilégiant le local. Cette présentation s'appuie sur une étude de faisabilité fictive du projet Aurora et explique comment un seul contexte peut se remplir de brouillons, de journaux et de résultats d'outils. Elle décrit ensuite comment un commandant sépare la coordination de l'exécution grâce à des processus isolés, l'affectation de spécialistes et un transfert final. L'ingestion locale de documents inclut le découpage sans état, un modèle d'intégration embarqué et la récupération de vecteurs SQLite. Le flux de travail vérifie un conflit de paramètres solaires et de batterie, achemine la génération de rapports via une vérification déterministe en ligne de commande Office et décrit la réflexion pendant les périodes d'inactivité. La dernière section aborde les compromis observés dans le code source : dépendance à l'alimentation et à l'état de veille de l'hôte, utilisation accrue de jetons lors de la décomposition et règles de qualité définies par le code source. Horodatage : 0:00 Contamination du contexte dans un thread de modèle unique 0:29 Le Commandant sépare la coordination de l’exécution 1:12 Limites locales et Project Aurora 1:55 Ingestion locale de documents et récupération vectorielle 3:13 Objectif en quatre étapes et workers isolés 4:16 Mémoire délimitée et transfert DeepResearcher 5:19 Vérification déterministe de l’interface de ligne de commande Office 6:12 Orchestrateur de réflexion pendant les fenêtres d’inactivité 6:37 Cadence, délais d’attente et tentatives de nouvelle exécution limitées 7:10 Compromis liés au système nu et règles définies par le code source 7:48 Isolation structurelle et exécution déterministe 🧠 L’isolation du contexte sépare le travail intermédiaire 📚 Les fragments locaux, les embeddings et la récupération SQLite sous-tendent Project Aurora 🧩 La délégation et les portes de l’interface de ligne de commande Office façonnent le flux de travail des rapports ⚙️ La réflexion s’exécute dans des fenêtres d’inactivité limitées Orkas présente un modèle d’orchestration local : séparation du Commandant, des agents spécialisés et des ressources durables La mémoire et les outils déterministes sont intégrés dans des chemins d'exécution délimités. Le code source met également en évidence le compromis : le contrôle local dépend de la disponibilité de l'hôte et engendre une surcharge de coordination. Pour une analyse technique plus approfondie, consultez les modules de routage des agents principaux, de segmentation des fichiers, de stockage vectoriel et de réflexion du dépôt. #Orkas #MultiAgentAI #LocalFirstAI [hi] Orcus GitHub की व्याख्या: लोकल मल्टी-एजेंट वर्कफ़्लो संदर्भ को कैसे अलग करते हैं orkas by orkas-ai: orkas-ai/orkas Orkas को एक ओपन-सोर्स, MIT लाइसेंस प्राप्त डेस्कटॉप एप्लिकेशन के रूप में प्रस्तुत किया गया है, जिसका उपयोग स्थानीय-केंद्रित AI वर्कफ़्लो के समन्वय के लिए किया जाता है। यह अवलोकन प्रोजेक्ट ऑरोरा के एक काल्पनिक व्यवहार्यता मूल्यांकन पर आधारित है और दर्शाता है कि कैसे एक ही संदर्भ ड्राफ्ट, लॉग और टूल आउटपुट से भर सकता है। इसके बाद यह बताता है कि कैसे एक कमांडर पृथक कार्यकर्ताओं, विशेषज्ञ प्रेषण और अंतिम हैंड-ऑफ के माध्यम से समन्वय को निष्पादन से अलग करता है। स्थानीय दस्तावेज़ इनपुट में स्टेटलेस चंकिंग, ऑन-डिवाइस एम्बेडिंग मॉडल और SQLite वेक्टर पुनर्प्राप्ति शामिल हैं। वर्कफ़्लो सौर और बैटरी पैरामीटर के टकराव की जाँच करता है, एक नियतात्मक Office CLI सत्यापन गेट के माध्यम से रिपोर्ट जनरेशन को रूट करता है, और निष्क्रिय अवधि के दौरान प्रतिबिंब का वर्णन करता है। समापन खंड स्रोत में दिखाए गए ट्रेड-ऑफ को कवर करता है: होस्ट पावर और स्लीप स्टेट पर निर्भरता, डीकंपोज़िशन से टोकन का अधिक उपयोग, और स्रोत-परिभाषित गुणवत्ता नियम। टाइमस्टैम्प: 0:00 एक सिंगल मॉडल थ्रेड में कॉन्टेक्स्ट कंटैमिनेशन 0:29 कमांडर कोऑर्डिनेशन को एग्जीक्यूशन से अलग करता है 1:12 लोकल-फर्स्ट बाउंड्री और प्रोजेक्ट ऑरोरा 1:55 लोकल डॉक्यूमेंट इनजेशन और वेक्टर रिट्रीवल 3:13 चार-चरणीय ऑब्जेक्टिव और आइसोलेटेड वर्कर्स 4:16 स्कोप्ड मेमोरी और डीप रिसर्चर हैंड-ऑफ 5:19 डिटरमिनिस्टिक ऑफिस CLI वेरिफिकेशन 6:12 आइडल विंडो के दौरान रिफ्लेक्शन ऑर्केस्ट्रेटर 6:37 कैडेंस, टाइमआउट और बाउंडेड रिट्राई 7:10 बेयर-मेटल ट्रेड-ऑफ और सोर्स-डिफाइंड रूल्स 7:48 स्ट्रक्चरल आइसोलेशन और डिटरमिनिस्टिक एग्जीक्यूशन 🧠 कॉन्टेक्स्ट आइसोलेशन इंटरमीडिएट वर्क को अलग करता है 📚 लोकल चंक्स, एम्बेडिंग और SQLite रिट्रीवल प्रोजेक्ट ऑरोरा को आधार बनाते हैं 🧩 डेलीगेशन और ऑफिस CLI गेट्स रिपोर्ट वर्कफ़्लो को आकार देते हैं ⚙️ रिफ्लेक्शन बाउंडेड आइडल विंडो में चलता है ओर्कास प्रस्तुत करते हैं लोकल-फर्स्ट ऑर्केस्ट्रेशन पैटर्न: कमांडर, स्पेशलिस्ट एजेंट, ड्यूरेबल मेमोरी और डिटरमिनिस्टिक टूल्स को सीमित निष्पादन पथों में अलग करें। स्रोत कोड में इसके फायदे और नुकसान भी स्पष्ट किए गए हैं: लोकल कंट्रोल होस्ट की उपलब्धता पर निर्भर करता है और समन्वय का बोझ बढ़ाता है। अधिक तकनीकी जानकारी के लिए, रिपॉजिटरी के कोर-एजेंट राउटिंग, फाइल चंकिंग, वेक्टर स्टोर और रिफ्लेक्शन मॉड्यूल देखें। #Orkas #MultiAgentAI #LocalFirstAI [id] Penjelasan GitHub Orcus: Cara Alur Kerja Multi-Agen Lokal Mengisolasi Konteks Orkas oleh orkas-ai: orkas-ai/orkas Orkas disajikan sebagai aplikasi desktop sumber terbuka berlisensi MIT untuk mengoordinasikan alur kerja AI yang mengutamakan lokal. Gambaran umum ini mengikuti penilaian kelayakan fiktif Proyek Aurora dan menunjukkan mengapa satu konteks dapat dipenuhi dengan draf, log, dan output alat. Kemudian, ia menelusuri bagaimana seorang Komandan memisahkan koordinasi dari eksekusi melalui pekerja terisolasi, pengiriman spesialis, dan penyerahan akhir. Pengambilan dokumen lokal mencakup pembagian tanpa status, model penyematan di perangkat, dan pengambilan vektor SQLite. Alur kerja memeriksa konflik parameter surya dan baterai, mengarahkan pembuatan laporan melalui gerbang verifikasi CLI Office deterministik, dan menjelaskan refleksi selama periode idle. Bagian penutup membahas pertimbangan yang ditunjukkan dalam kode sumber: ketergantungan pada daya host dan status tidur, penggunaan token yang lebih tinggi dari dekomposisi, dan aturan kualitas yang ditentukan dalam kode sumber. Cap Waktu: 0:00 Kontaminasi konteks dalam satu thread model 0:29 Komandan memisahkan koordinasi dari eksekusi 1:12 Batasan lokal-pertama dan Proyek Aurora 1:55 Pengambilan dokumen lokal dan pengambilan vektor 3:13 Tujuan empat langkah dan pekerja terisolasi 4:16 Memori terlingkup dan serah terima DeepResearcher 5:19 Verifikasi CLI Office deterministik 6:12 Orkestrator refleksi selama jendela idle 6:37 Irama, batas waktu, dan percobaan ulang terbatas 7:10 Kompromi bare-metal dan aturan yang ditentukan sumber 7:48 Isolasi struktural dan eksekusi deterministik 🧠 Isolasi konteks memisahkan pekerjaan perantara 📚 Potongan lokal, penyematan, dan pengambilan SQLite mendasari Proyek Aurora 🧩 Delegasi dan gerbang CLI Office membentuk alur kerja laporan ⚙️ Refleksi berjalan dalam jendela idle terbatas Orkas menghadirkan pola orkestrasi lokal-pertama: terpisah Komandan, agen spesialis, memori tahan lama, dan alat deterministik ke dalam jalur eksekusi terbatas. Kode sumber juga menjelaskan pertukaran tersebut dengan jelas: kontrol lokal bergantung pada ketersediaan host dan menambah biaya koordinasi. Untuk bacaan teknis yang lebih mendalam, periksa modul perutean agen inti, pemecahan file, penyimpanan vektor, dan refleksi di repositori. #Orkas #MultiAgentAI #LocalFirstAI [it] Orcus GitHub spiegato: come i workflow multi-agente locali isolano il contesto Orkas di orkas-ai: orkas-ai/orkas Orkas è presentato come un'applicazione desktop open-source con licenza MIT per il coordinamento di flussi di lavoro di intelligenza artificiale "local-first". Questa panoramica segue una valutazione di fattibilità fittizia del Progetto Aurora e mostra perché un singolo contesto può riempirsi di bozze, log e output di strumenti. Descrive quindi come un Comandante separa il coordinamento dall'esecuzione attraverso worker isolati, l'assegnazione di specialisti e un passaggio di consegne finale. L'acquisizione locale dei documenti comprende la suddivisione in blocchi senza stato, un modello di embedding on-device e il recupero di vettori SQLite. Il flusso di lavoro verifica un conflitto tra i parametri di alimentazione solare e batteria, instrada la generazione dei report attraverso un gate di verifica deterministico della CLI di Office e descrive la riflessione durante i periodi di inattività. La sezione conclusiva tratta i compromessi mostrati nel codice sorgente: dipendenza dall'alimentazione e dallo stato di sospensione dell'host, maggiore utilizzo di token dovuto alla decomposizione e regole di qualità definite dal codice sorgente. Timestamp: 0:00 Contaminazione del contesto in un singolo thread del modello 0:29 Commander separa il coordinamento dall'esecuzione 1:12 Limiti "local-first" e Project Aurora 1:55 Acquisizione locale dei documenti e recupero dei vettori 3:13 Obiettivo a quattro fasi e worker isolati 4:16 Memoria con ambito e passaggio di consegne DeepResearcher 5:19 Verifica deterministica della CLI di Office 6:12 Orchestratore di Reflection durante le finestre di inattività 6:37 Cadenza, timeout e tentativi limitati 7:10 Compromessi bare-metal e regole definite dalla sorgente 7:48 Isolamento strutturale ed esecuzione deterministica 🧠 L'isolamento del contesto separa il lavoro intermedio 📚 Chunk locali, embedding e recupero SQLite sono alla base di Project Aurora 🧩 Delega e gate della CLI di Office modellano il flusso di lavoro del report ⚙️ Reflection viene eseguita in finestre di inattività limitate Orkas presenta un modello di orchestrazione "local-first": separare i Comandante, agenti specializzati, memoria persistente e strumenti deterministici in percorsi di esecuzione delimitati. Il codice sorgente chiarisce anche il compromesso: il controllo locale dipende dalla disponibilità dell'host e aggiunge un overhead di coordinamento. Per un approfondimento tecnico, si consiglia di esaminare i moduli di routing dell'agente principale, di suddivisione dei file, di archiviazione vettoriale e di riflessione presenti nel repository. #Orkas #MultiAgentAI #LocalFirstAI [pt-BR] Orkas no GitHub explicado: Como fluxos de trabalho multiagente locais isolam o contexto Orkas, da Orkas-ai: orkas-ai/orkas O Orkas é apresentado como um aplicativo de desktop de código aberto, licenciado sob a licença MIT, para coordenar fluxos de trabalho de IA com foco em recursos locais. Esta visão geral segue uma avaliação de viabilidade fictícia do Projeto Aurora e mostra como um único contexto pode ser preenchido com rascunhos, registros e resultados de ferramentas. Em seguida, descreve como um Comandante separa a coordenação da execução por meio de workers isolados, despacho de especialistas e uma entrega final. A ingestão local de documentos abrange fragmentação sem estado, um modelo de incorporação no dispositivo e recuperação de vetores SQLite. O fluxo de trabalho verifica conflitos entre parâmetros de energia solar e bateria, direciona a geração de relatórios por meio de um gate de verificação determinístico da CLI do Office e descreve a reflexão durante períodos de inatividade. A seção final aborda as compensações mostradas no código-fonte: dependência da energia e do estado de repouso do host, maior uso de tokens devido à decomposição e regras de qualidade definidas pelo código-fonte. Marcadores de tempo: 0:00 Contaminação de contexto em uma única thread de modelo 0:29 O Commander separa a coordenação da execução 1:12 Limites locais e o Projeto Aurora 1:55 Ingestão local de documentos e recuperação de vetores 3:13 Objetivo de quatro etapas e workers isolados 4:16 Memória com escopo e a transferência do DeepResearcher 5:19 Verificação determinística da CLI do Office 6:12 Orquestrador de reflexão durante janelas ociosas 6:37 Cadência, timeouts e novas tentativas limitadas 7:10 Compensações de bare-metal e regras definidas pela fonte 7:48 Isolamento estrutural e execução determinística 🧠 O isolamento de contexto separa o trabalho intermediário 📚 Blocos locais, embeddings e recuperação de SQLite fundamentam o Projeto Aurora 🧩 Delegação e gates da CLI do Office moldam o fluxo de trabalho do relatório ⚙️ A reflexão é executada em janelas ociosas limitadas Orkas apresenta um padrão de orquestração local: separar o Commander, agentes especializados, Memória durável e ferramentas determinísticas em caminhos de execução delimitados. O código-fonte também deixa clara a compensação: o controle local depende da disponibilidade do host e adiciona sobrecarga de coordenação. Para uma leitura técnica mais aprofundada, examine os módulos de roteamento do agente principal, fragmentação de arquivos, armazenamento de vetores e reflexão do repositório. #Orkas #IAMultiagente #IALocalPrimeiro

Thank you for the reply! My thought is that any competition to Anthropic is going to need to actually have the compute to serve all of Anthropics customers. Chinese labs certainly do not. It seems to be the crux of all these compute agreements. Even then, Anthropic has the luxury of knowing exactly what hardware (even what datacenter!) will serve their models. This gives them the ability to co-design their model for the exact chips it will run on, something that Open Weights models are completely unable to do - even to the point that Deepseek fully open-sourced their inference engine, revealing that they're still running on only H100s and Huawei Ascend chips (github.com/deepseek-ai/DeepInfer/blob/main/README…). Anthropic will be running their 2027 Opus and Fable models on Vera Rubin, a chip which produces tokens for about 1/100th the cost of the H200. Seriously. 100x more efficient on GLM 5.3: inferencex.semianalysis.com compared to what DeepSeek is able to use for inference. Combined with Kimi K3.1's underperformance I'm honestly not too bullish on Chinese AI being able to catch back up. As an example, according to artificialanalysis.ai, Kimi K 3.1 would need to be run 10x cheaper than its current inference cost in order to hit the Paraeto Frontier (matching 6.1 Sol Medium)

デンコ(仮の最終話を掲載します。 #デンコ バックナンバーは以下から。 Layer812/PanicPlayerWeb panicって乱数対応してるのかな... t.co

Ini repo GitHub-nya buat yg mau coba: storytold/figcraft

[OPEN SOURCE] Fast IdeogramV4 + Qwen 3.X class model trainer. Train more in less time. preview.redd.it As part of the effort I did on training AI models that are able to create great art, we've had to design two components of what makes a design good: 1. Text to image models to transform a caption into a image. 2. Customer request to caption / brief to then send to the AI model (which in turn generates it). For both trains, I've found pre-existing trainers are quite slow in terms of performance and leave a lot of MFU underutilized (which leads to less tokens / images trained a second). I've optimized this for BH200 (Datacenter GPUs), but this should work for H100 and likely also works well on A100, and can be adapted to work on RTX series GPUs as many things translate over to customer GPUs (although unfortunately I don't have any to test and develop this). preview.redd.it The results are very good - on one GPU, our solution is 58% better than ms-swift (a optimized training kit), 76% better than unsloth, and 178% better than transformers + PEFT. For example, for training a designer (takes a concept / idea, then refines it into a very detailed caption for the model to then render / generate) via Qwen3.5-9B, it does 12,523 tokens/second, quite a bit (against 989 TFLOPS, what the GPU can do). It also has a 43.7% best-config number from our micro-batch sweep, so play around with it and sweep to maximize perf. However, the Arrhenius supercomputer we've tested this on does power-capping, so the true MFU is 53.9% clock-adjusted. Same data and setup, other trainers: - ms-swift ≈ 24% (1.58× slower); - Unsloth ≈ 22% (1.76× slower); - transformers + PEFT ≈ 14% (2.78× slower). To give some comparison numbers, i've made some graphs. Comparison graph versus other solutions It virtually has loss parity (<6e-4 loss difference, which is negligible), and this, in short, allows training more for less. preview.redd.it For the Ideogram V4 trainer , below is the performance analysis: preview.redd.it Also, there are some ablations in terms of what increases or decreases step time. preview.redd.it Code here: logolabs/perf_kit If you want to support us in developing and releasing more free tools, you can star the repository. Hope it is useful to you to help you improve your trains efficiency.

Criei um fork desse projeto e estou tentando implementar recursos de mods famosos no recomp. willzmkv/gta-vcs-recomp Meu fork é pré-alpha, e só recomendo testar se tiver curiosidade. Até o momento, na build do fork, somente um controle de FOG foi implementado.

135 seconds. 4,050 frames. All drawn by code. Pip and the Missing Glow: a paper-cut kids' story built with AI coding agents. Code + guide (MIT): aburgostejada/kids-story-studio Behind the scenes: blog.attainos.com YouTube: youtu.be t.co

⭐️Resonant for Plex PS3 1.00 released by daedra000 A native Plex music player for the PlayStation 3. 🔹Draw artist's picture behind artist and album pages. 🔹MP3 encoding. FLAC & MP3 play direct. 🔹Lyrics from your Plex server 📥github.com/daedra000/Resonant-PS3/releases t.co