2026-10-09

recently saw a bunch of open decision models pop out of nowhere in the last two weeks (laya, liquid's d1, cloudflare's clef-flash, interfaze's lev), so I wanted to see how far apart they actually are on the same GPU(yes, model size is a huge factor, but still isn't the only factor). all four had the same task of reading nine wikipedia articles about centipedes (9,534 words) word by word and flag every word that names a centipede. one /v1/systemone call per word, the next word goes out the second the answer comes back request for every word: {"state": "Word: \"Scolopendra\".", "questions": {"centipede": {"type": "noul", "instructions": "Does this word name a kind of centipede?"}}} model weights engine per word (p50) words in 32s accuracy centipede names caught wrong picks Laya Laya-BF16.gguf llama.cpp b11495 3.9 ms 7,980 97.4% 70% 98 d1 3B d1-3B-AD-Q4_K_M.gguf llama.cpp b11495 6.0 ms 5,306 96.5% 51% 51 Clef-Flash 9B Clef-Flash-Q8_0.gguf llama.cpp b11495 24.4 ms 1,292 97.2% 36% 2 Lev 4B interfaze-ai/lev, bf16 lev serve (PyTorch) 51.0 ms 626 98.9% 83% 4 laya and d1 gap the other models in speed, though not so much on accuracy (yes, it does say 95%, but even saying "no" counts as a correct answer, so that's where the high acc comes from). what everyone might care about more is how well each one did their respective task and lev catches the most while being 13x slower than laya, partly because it runs in its own pytorch server instead of llama.cpp (it measured 68 ms on a different 4090, so it's CPU-sensitive too). but in the end Laya is the fastest model overall, and considering how easily it can be fine-tuned for any use case I'd say that be my go to pick setup: GPU: rented RTX 4090 (driver 580.119.02, 32 vCPU) engine: llama.cpp b11495 (commit 37ac63456, CUDA 12.8 release build), -ngl 99, everything else default Laya, Clef-Flash: the ggml-org GGUFs d1: our own AD-Q4_K_M quant ( atomic.chat ), runs natively on /v1/systemone since the lfm2-d1 support landed in #30110 Lev: interfaze's LoRA on Qwen3.5-4B in its own lev serve, default settings (--compile never finished warming up) latency: end to end from a Python client on the same box over localhost submitted by /u/Fun-Meaning-6474 to r/LocalLLaMA [link] [comments]

The other week I posted about Jev vs. Kev compared and since then, OpenAI released the decisions endpoint, Cloudflare released Clef and many here asked about Laya as well. This time we compared six popular decision models by making them play Pac-Man: kev 1.13, Kev 4B, Clef, Clef Flash, GPT-6 Luna and Laya. Since they respond within ms it works for them to play the game in real time. We published a leaderboard and the repo is open-source, so anyone can run their own decision model, like your own fine-tuned one run locally or hosted somewhere, and join the leaderboard. Model Avg score High score Avg latency jev 1.13 2,750 6,380 290 ms GPT-6 Luna 2,568 5,920 179 ms Clef Flash 2,538 4,260 256 ms Clef 2,476 4,820 398 ms Kev 4B 1,506 5,280 231 ms Laya 639 1,200 104 ms For the leaderboard we let each model run 100 times and took mean score with a 95% margin of error (±2 standard errors), so some models tie on top spot. You can also play yourself as Pac-Man, and the ghosts are the decision models, either all jev, clef, Luna or Laya, or a mix of models taking over each ghost. submitted by /u/facethef to r/LocalLLaMA [link] [comments]

Post title is slightly misleading, I don't think you can get these for $350 each anymore but they're still pretty cheap all things considered. They're Radeon Pro V620's which are older RDNA2 enterprise cloud gaming cards with 32 GB VRAM. (Ignore the RTX 4090 on the side, it's just used for stuff like image/video gen models, no LLMs) But I bought these cards a couple months ago as a gamble to see if I could build a big VRAM rig with usable speed for relative peanuts. I was struggling with llama.cpp for a long time, but the prefill was pretty bad (around 350-450 t/s average with this same model) and vLLM just didn't work on the cards. Plus llama.cpp just sucks at concurrency. I'd been planning to sell the cards lately because this wasn't going to work for my use case, but then decided to see if I (Claude) could make a vLLM fork that both works with the cards and actually gets good speeds out of them. I had it build/test/iterate on custom RDNA2 kernels. Problem solved! It worked out way better than I expected. I thought maybe I'd hit 1000 t/s prefill with QFN at best, but this is something like 800% faster than llama.cpp was managing. Couldn't be happier with the results! GPU sale plan canceled lol. I'm going to have it continue optimizing and see how it goes, and make sure DeepSeek and GLM-5.3-Flash work as well. llama-benchy results below with concurrency = 1 and vLLM running with PP=4 (no tensor parallel here) with orcarouter's uncensored QFN which I quantized. Routed experts are W4A16 and everything else remains at BF16. MTP enabled with 3 token drafting. It gets 40 to 50 t/s decode with MTP disabled. https://preview.redd.it/4223w82yz9uh1.png?width=666&format=png&auto=webp&s=a15e5d1f5664fcb894a746a54a501eb8f6637a57 submitted by /u/_TheWolfOfWalmart_ to r/LocalLLaMA [link] [comments]

Uncompressed image: https://postimg.cc/gallery/gmR7dbs (To view the uncompressed image, click on it a second time after opening it, or simply download the entire image album) ---------------------------------------------------------------------------------------------------------------------------------- Hi everyone! I noticed that a lot of people have started talking about Hunyuan Image 3 , so I wanted to test it in T2I scenarios. While I was at it, I compared it against the most popular models in the same segment right now: Qwen Image 2.1 and Krea 2 Turbo . What this test is about I was NOT trying to test the maximum-size versions of these models with minimal quantization. What mattered to me was testing the versions that can realistically run on regular consumer PCs, so I picked the lightest variants, which most of you will probably be able to run. The goal of this test is to make it easier for you to choose the ideal T2I model for your own tasks. To keep things as fair as possible, I used the simplest, most basic workflow for each model. Models used: hunyuan_image_3_instruct_distil_w4a8 Qwen Image 2.1 int8 convrot Krea 2 Turbo int8 convrot Test categories I split the tests into several categories with different goals: Images 1-3: complex prompts with lots of details and different poses. These show how well a model follows the prompt and how often it loses details. Images 4-6: typography, mixing typography with real-world imagery, and banner creation. Images 7-11: styles. Pay attention to how well each model handles different styles. Images 12-13: level of detail. This is similar to tests 1–3, but with a stronger focus on small details. Image 14: character understanding. Images 15-17: your favorite (or most hated) category, 1girl. Here you can judge overall realism and the ability to generate in an amateur-photo style. How I picked the results I ran each prompt with two fixed seeds and two random ones, then picked the single best image out of those four. Generation speed I’m running an RTX 3090 (24 GB VRAM), and generation took: Hunyuan Image 3 distill: 20-26 seconds Qwen Image 2.1: 16 seconds Krea 2 Turbo: 8-9 seconds My opinion Now I’d like to share my personal opinion, which doesn’t claim to be the truth. 1st place: Krea 2 Turbo Incredible speed plus good detail. The images aren’t mushy, but they also don’t suffer from oversharpening, harsh artificial crispness, or excessive detail. They look alive and realistic. The model handles styles well, understands the prompt and context, does a decent job with typography, and very rarely messes up anatomy. For me personally, it covers pretty much all of my T2I needs. There’s one downside that really annoys me, though: the weak VAE from Qwen Image. On full-body shots it turns the character’s eyes into mush, like base SDXL. Yes, I know there are custom VAEs that add extra detail, but they just improve the quality of the same anomalies and bugs the eyes have. The only way I’ve found to fix the eyes is FaceDetailer with a mask over the eyes. Besides eyes, the model also likes to turn other small elements into a mess, and I’m more than sure this comes down to that VAE. 2nd place: Qwen Image 2.1 Qwen has very good detail, which is both its strength and its weakness. The excess detail creates an artificial sharpness effect, basically oversharpening. In most cases it looks very unnatural and gives off that classic “AI look”. That said, I liked how it handles the 1girl category: it produces fairly realistic amateur-style photos. It also does well with styles. I really liked image 8 with the lion and the zebra, where the model nailed a genuinely cool hand-drawn pencil effect. But in some cases the oversharpening badly hurts the style, for example in images 7 and 10. Its VAE issues are similar to Krea 2’s. On images with visible skin, you can see diamond-shaped or dotted patterns when zoomed in. It looks ugly, and when you zoom in and out the skin starts to shimmer. 3rd place: Hunyuan Image 3 A very heavy model that, in most cases, produces fairly low-detail images, so it’s not a great choice for realistic generation. You might think it’s stronger in other scenarios, but no. It doesn’t always handle typography well (you can see that in the tests), and the same goes for stylization (look at images 9 and 10). It performs more or less decently in the 1girl category, but I tested only a few images there, so I can’t say for sure how good it is. It has VAE problems too. Sometimes hair textures get strange stripes that are easy to spot when you zoom in and out. This is especially visible in image 15: zoom in and out a few times and you’ll see what I mean. It looks like generation noise is showing through in the image. I think Hunyuan Image 3 is more interesting for I2I (Edit) scenarios than for classic T2I. Final words I’d like to remind you again that this is my subjective opinion and may differ from yours. If you see it differently, I’d be glad to hear your thoughts in the comments. Also, if you have any questions, feel free to post them in the comments section. Thanks for reading! I hope my tests were useful and helped you choose your main model for generation. submitted by /u/Both-Rub5248 to r/StableDiffusion [link] [comments]

I've been upscaling old footage with RTX Video Super Resolution in ComfyUI, and it works fine for short clips. But for a full-length film it's painful. If it crashes or you cancel at the 90 minute mark, you start again from zero. So I made RTX VSR Studio. It's a normal Windows app that calls NVIDIA's Video Effects SDK directly. No ComfyUI, no node graph, no PyTorch. The main thing is that long videos are processed in small segments. If it crashes, the power goes out, or you just cancel it, run the same job again and it picks up at the exact frame it stopped at. You lose minutes, not hours. What else it does: - Pick 720p, 1080p, 1440p or 4K and it works out the size for you. It keeps the aspect ratio, so a 2.39:1 film doesn't get stretched to 16:9. - Before/after preview. Render one frame at any timestamp and drag a split line to compare before you commit to a long run. - Time range, so you can test 30 seconds instead of waiting 2 hours. - Batch queue. Add files, set them up, walk away. - Output as H.264 or HEVC in mp4, or ProRes / DNxHR in mov. These import straight into Final Cut Pro and DaVinci Resolve. - Content presets (Balanced, Anime, Film, Screen capture, Old/DVD, Editing) that fill in the settings for you. - Denoise and deblur modes if you just want to clean up at the original resolution. - It never overwrites a file. If the name is taken it writes "name (2).mp4" instead. - Audio and subtitles are copied through untouched. - There's a CLI too, if you'd rather script it. VRAM is not really an issue. Frames are processed one at a time, so 1080p to 4K peaks at about 1.6 GB, and a 2-hour film uses the same VRAM as a 2-second clip. Speed on my RTX A4000, 1080p to 4K: the upscale alone runs at about 109 fps on HIGH. End to end it's around 40 fps, because the NVENC encode is the slow part, not the upscale. A 2-hour 24 fps film takes roughly 1.2 hours. What you need: an RTX 20-series or newer card, driver 570.65 or later, 64-bit Windows 10 or later, and ffmpeg. Double-click run.bat and the first run sets everything up (about 1.4 GB, most of it NVIDIA's own DLLs). Things it can't do, so nobody is surprised: - 8-bit SDR only. The SDK doesn't handle HDR or 10-bit. There's an option to tonemap to SDR first, but it changes the look, so it's off by default. - ProRes and DNxHR encode on the CPU, so they're slower and the files are much bigger. - Free DaVinci Resolve on Windows can't open HEVC, so use H.264 or ProRes there. Links: Video tutorial: https://youtu.be/r2rhHdvzHgU GitHub: https://github.com/Garionhk/RTX-VSR-Studio Thanks to NVIDIA for the Video Effects SDK, and to the ComfyUI-NVIDIA-RTX-VSR-Pro project, which parts of this are based on. I've only tested on my A4000, so I'd love to hear how it runs on your card, especially 20 and 30 series. Bugs and ideas are welcome too. It's free and open source (Apache 2.0). The NVIDIA SDK it downloads is NVIDIA's own and has its own terms. submitted by /u/garionhk to r/StableDiffusion [link] [comments]

As previously promised , here's Anthropic's new fast, low cost model: Introducing Claude Haiku 5.5 . The previous Haiku, 4.5, was very much showing its age. It came out almost a year ago , and was priced at $1/million input and $5/million output - relatively expensive even back then, and a full 10x the price of OpenAI's GPT-6 Luna , released last month. The new Haiku exactly matches the price of GPT-6 Luna - $0.10/$0.50 - up to 100,000 tokens. Beyond 100,000 tokens the price increases 5x to $0.50/$2.50. Luna itself has a price increase at 272,000 tokens but only to $0.20/$0.75. Haiku 5.5 also uses a new, less generous tokenizer. My Claude Token Counter tool shows that the same long prompt uses around 1.25x as many tokens with Haiku 5.5 compared to Haiku 4.5, so there's a hidden price increase there. If your workloads fit in 100,000 tokens, Haiku is the same price as Luna and reports higher benchmark scores. Above 100,000 tokens, Luna looks like a much better deal. The most recent release of llm-anthropic finally fixed it so I don't need to ship a new version of that plugin for every new model. I tested the new model like this: llm install -U llm-anthropic llm anthropic refresh llm -m claude-haiku-5.5 "Generate an SVG of a pelican riding a bicycle" -o thinking_effort low Pelicans Here are pelicans for low, medium, high, xhigh, and max . The new Haiku doesn't let you disable reasoning, and defaults to medium . I got a good bicycle frame for everything beyond low . The low effort pelican cost 0.0936 cents and took 7 seconds. This max effort pelican (with a reasoning trace that starts "This is the classic pelican-on-bicycle SVG test...") took 5 minutes 9 seconds to generate, but still only cost me 3.3826 cents : (Since the reasoning trace exhibits awareness of the benchmark, here's Generate an SVG of an armadillo in fishnet tights jaywalking on Mars (on xhigh) , and the same prompt against some other recent models . Background on that .) For comparison, here's the pelican I got a year ago from Haiku 4.5 (for 0.7583 cents - Haiku 4.5 did not support reasoning levels). It sucked at drawing pelicans: And a generous API credit scheme for subscribers In addition to Haiku 5.5, Anthropic announced today that they are halving the price of cache reads for Sonnet 5.5. They've also added API credits to subscription plans: Second, this week, we’ll roll out a new monthly API credit to all Max and Team subscribers for use on the Claude Platform . Max 5x users will get $100 in credits per month, Max 20x users will get $200, and Team subscribers will receive up to $500, pooled across their users. Claiming this is pleasantly easy: navigate to Settings -> Billing and select the API organization that should benefit from the credits every month: The API credits exactly match the cost of the subscription itself. This is really generous - it makes it much easier for subscribers to use the API. Anthropic also let you disable auto-reload for the API, with the consequence that "API requests will stop when your balance runs out" - exactly what you want if you're planning to burn through those API credits without risk of a nasty billing surprise . Note that the monthly credits do not roll over - use them or lose them. OpenAI still allow you to use your Codex subscription for personal API use, which works out as a better deal for heavy API users. This new credit scheme goes at least some way to overcoming that difference. Tags: ai , generative-ai , llms , anthropic , claude , llm-pricing , pelican-riding-a-bicycle , llm-release

submitted by /u/Charuru to r/singularity [link] [comments]

Anthropic : Anthropic launches OSS Scanner, which provides free, opt-in security audits for open-source projects by sending AI-generated reports without human review — We're launching OSS Scanner, an opt-in vulnerability scanner for the open-source ecosystem informed by our experience using Claude …

CUDA: improve top-k algorithm selection ( #28713 ) CUDA: radix top-k for large row counts Replaces CUB's per-row DeviceTopKKernel with a grid-over-rows radix select, gated on GGML_CUDA_TOPK_RADIX_MIN_ROWS. On qwen4exp at 34,816 tokens this cuts top-k from 1,671,253 launches / 5,761.8 ms to 2,329 / 941.8 ms. CUDA: select the TOP_K implementation by shape Replace the nrows/ncols special case with the decision boundary from #28547 (as implemented in #29278 ): bitonic for short rows, radix select for several long rows, and DeviceTopK or CUB argsort for a single long row. The thresholds stay overridable at build time. Two refinements on top of that boundary: bitonic stays in use for rows up to a padded 1024 while the rows fit in one wave of blocks (nrows <= number of SMs); radix select pays a fixed cost of about a dozen launches that only amortizes over more rows with DeviceTopK available, it handles up to two rows Radix select now processes rows in chunks so its scratch memory stays bounded, and the bitonic path keeps its chunking. HIP and MUSA keep their previous thresholds. Add perf cases around the bitonic/radix crossover to test-backend-ops. CUDA: make top-k comments less verbose CUDA: remove the TOP_K width limit from supports_op CUDA: use DeviceTopK for single-row TOP_K if available CUDA: avoid ncols overflow in the TOP_K bitonic check CUDA: share the row chunking helper between argsort and top-k CUDA: do the TOP_K radix blocks_per_row math in int64_t CUDA: rename GGML_CUDA_TOP_K_NROWS_THRESHOLD_DEVICETOPK to GGML_CUDA_TOP_K_NROWS_THRESHOLD CUDA: share one sort helper between the bitonic and CUB TOP_K paths CUDA: update the TOP_K TODO, threshold and chunking comments tests: add TOP_K cases that span several row chunks CUDA: use int64_t col in the TOP_K radix loops, fix threshold comment CUDA: limit TOP_K and ARGSORT support to ne[0] <= INT_MAX Co-authored-by: praneshgo 227579474+praneshgo@users.noreply.github.com Co-authored-by: Pranesh Gonegandla pgonegandla@nvidia.com Website: https://llama.app Attestations: https://github.com/ggml-org/llama.cpp/attestations/54066267 macOS/iOS: macOS Apple Silicon (arm64) macOS Apple Silicon (arm64, KleidiAI enabled) DISABLED macOS Intel (x64) iOS XCFramework Linux: Ubuntu x64 (CPU) Ubuntu arm64 (CPU) Ubuntu s390x (CPU) Ubuntu x64 (Vulkan) Ubuntu arm64 (Vulkan) Ubuntu x64 (CUDA 12) - CUDA 12.8 libraries Ubuntu x64 (CUDA 13) - CUDA 13.4 libraries Ubuntu arm64 (CUDA 13) - CUDA 13.4 libraries Ubuntu x64 (ROCm 10.0) Ubuntu x64 (OpenVINO) Ubuntu x64 (SYCL FP32) Ubuntu x64 (SYCL FP16) Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Android: Android arm64 (CPU) Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - setup guide Windows: Windows x64 (CPU) Windows arm64 (CPU) Windows arm64 (OpenCL Adreno) Windows x64 (CUDA 12) - CUDA 12.4 DLLs Windows x64 (CUDA 13) - CUDA 13.4 DLLs Windows arm64 (CUDA 13) - CUDA 13.4 DLLs Windows x64 (Vulkan) Windows arm64 (Vulkan) Windows x64 (OpenVINO) Windows x64 (SYCL) Windows x64 (ROCm 10.0) openEuler: DISABLED openEuler x86 (310p) openEuler x86 (910b, ACL Graph) openEuler aarch64 (310p) openEuler aarch64 (910b, ACL Graph) UI: UI

Hi all, a bunch of performance improvements have been landed in audio.cpp. The biggest highlight is Higgs Audio TTS, which now runs with around 6 GB VRAM , a 48% reduction in peak memory usage compared to the previous implementation. Thanks to https://github.com/mirek190 We also made some models significantly faster, especially HTDemucs on GPU and PocketTTS on CPU. No compromises in parity and correctness. Here's a summary of the improvements: Model Peak memory reduction Speedup Higgs Audio TTS 48% VRAM 1.01–1.09× CUDA ACE-Step family 6–7% VRAM 1.06–1.08× CUDA, 1.16–1.20× Vulkan MOSS-TTS v1.5 cloning 21% VRAM 1.05× CUDA MOSS-TTSD Q8 cloning 11% VRAM 1.04× CUDA Echo-TTS (Memory Saver) 20% VRAM — Qwen3-TTS 16–20% VRAM — IndexTTS2 / 2.5 12% VRAM — HTDemucs — 2.21× CUDA, 1.95× Vulkan HTDemucs six-stem — 1.99× CUDA PocketTTS 9% RAM 2.23× CPU They're runtime-level optimizations that make existing models more practical to run locally. The WebUI now includes an experimental generation history feature that lets you revisit previous outputs and restore their settings. audio.cpp now supports 110+ audio model families and 190+ variants (and counting)! We're continuing to improve memory efficiency and inference speed across CUDA, Vulkan, Metal, AMD/HIP, and CPU. The next release will bring even more optimizations! We're also looking for contributors to help improve the audio.cpp WebUI. With so many models and features now supported, we'd love some help making the UI more polished, intuitive, and enjoyable to use. If you're interested in frontend development or UI/UX design, contributions are very welcome! Thanks to everyone contributing improvements, testing builds, and reporting issues. Curious how these changes work on your setup! submitted by /u/Acceptable-Cycle4645 to r/LocalLLaMA [link] [comments]

Model upgrades Models downloaded with earlier versions of Ollama are upgraded in the background the first time you run them, for better performance and compatibility when running on llama.cpp. To make downgrading safe, Ollama keeps the original copy as a backup, so upgraded models are temporarily kept on disk. A future release will remove these backups automatically. To remove backed up models now (requires jq ): curl -s localhost:11434/api/tags | jq -r ' .models[].name ' | while read -r m ; do curl -s localhost:11434/api/show -d " { \" model \" : \" $m \" } " | jq -r \ ' select(any(.manifests[]?; .runner == "llamacpp")) | .manifests[] | select(.runner == "ggml") | .digest ' done | sort -u | xargs -n1 ollama rm This only deletes the backups. If you later downgrade to a version older than 0.40, you'll need to re-pull those models. Other changes ollama list no longer shows duplicate entries for upgraded models by @dhiltgen in #18874 ollama launch claude uses the model's full context length by @jberg5 in #18855 README: add oxi to community integrations by @maziluiosif in #18739 New Contributors @maziluiosif made their first contribution in #18739 Full Changelog : v0.40.1...v0.40.2-rc0

submitted by /u/141_1337 to r/singularity [link] [comments]

The games and tools we build aren't "economically viable." The community of people who use switches is too niche and too diverse. That's exactly why we build them. My brother Ben uses switch access because of an ultra-rare condition called TUBB4A-related leukodystrophy. He could walk and talk as a kid, but the disease slowly took it all away. He's now nonspeaking and quadriplegic, and for years his only way to communicate was turning his head left or right for yes or no. He went nearly 10 years without real access. Eye tracking and head tracking don't work for him because of how complex his condition is. AAC phrase boards never engaged him. Ben wanted to play video games again and pick his own TV shows. Do you know how many yes/no questions you have to ask every day to give someone as much autonomy as possible? Hundreds. Ben didn't need more yes or no questions. He needed access. Ben moved in with us in 2022. We started with a better phrase board that had more of what he might want to say, but it wasn't enough. Then in 2024 I learned AI could write code, even for someone like me with no programming background, and we started building him better tools. The first time Ben used his switches to pick his favorite movie (Spider-Man 1), his reaction lit a fire in me. So we kept building. He has a keyboard, phrase boards, and text messaging (he can text for the first time in his life). He can search the web, pick any show or movie on any streaming platform, and play dozens of games we're building with him. When I started, I was using one of Claude's competitors. Later, after hearing about Claude's advancements and seeing how good it was, I shifted over, and now Claude is one of my main tools. Not the only one, but a big part of how everything gets built. Claude isn't just for code, either. It's been an awesome thought partner for planning games and writing out our GDDs (game design documents) and spec sheets before anything gets built. We also use it to help run NARBE Foundation, the nonprofit we started to keep all of this free. For the building itself, our setup is VS Code with the Claude Code extension. Here's how it helps: -Writing the code. I describe what Ben needs in plain language, and Claude Code builds it, debugs it, and helps me iterate with Ben's feedback. -Keeping everything accessible. Every game and tool runs on one shared scan-and-select system controlled by spacebar/enter, so any switch works. We keep markdown files in the repo, like ACCESSIBILITY.md, that act as build rules. Claude Code references them so every new game follows the same accessibility standards, and anyone can use those same files to build their own. -Inside the hub itself. Our real-time conversation tool uses Claude Haiku to suggest replies Ben can pick with his switches, so he can join conversations instead of waiting for yes/no questions. Everything is free, open source (MIT license), and runs right in your browser. No account or install needed (streaming uses a free browser extension). Works with any switch that sends spacebar or enter. - Games: https://www.switchedgames.org - Benny's Hub: https://www.bennyshub.com - Code and md files: https://github.com/narbehouse/narbehouse.github.io - Video of Ben's story: https://youtu.be/9UNV3CK46SI If even one person sees this and gets inspired to build a tool or game for someone like Ben, it's worth it. Thanks for reading. submitted by /u/acrolicious to r/ClaudeAI [link] [comments]

Microscopic being on the scale of microns. So apparently this company spent 6 years developing what they're calling a "Matter Compiler." Basically, they've built a manufacturing system that can produce microscopic mechanical devices without needing to develop a completely new fabrication process for each one. You can change the design in software and use the same equipment to manufacture something different. They've already developed a tiny mechanical switch that handles 150A, has 200 µΩ resistance, and opens in 50 microseconds, all in a 9.5mm package. The idea is that eventually you could use this to manufacture all sorts of tiny motors, actuators, sensors, etc. without having to build specialized manufacturing processes for each one. They haven't demonstrated that level of flexibility yet, but if they can actually pull it off, this could be pretty huge. submitted by /u/jimmystar889 to r/accelerate [link] [comments]

I Know it was announced before but just to say that the new version of Kroma (krea 2 finetune) is really really good, i find it better that Qwen 2.1 t2i and Krea2, it is uncensored and with really good prompt following. No body horror, good details, and lot of styles you can play with. This image for exemple just said (Rogue from X-Men) : no costume details, no hair details, nothing!.... https://huggingface.co/lodestones/Kroma/blob/main/kroma-v0.3.1-turbo-opd.safetensors https://huggingface.co/Clybius/Kroma-Quantizations/blob/main/kroma-v0.3.1-turbo-opd-W8A8.safetensors Edit: krea 2 also knows Rogue character...my bad. submitted by /u/Dear-Spend-2865 to r/StableDiffusion [link] [comments]