entrope

For coding, Qwen3.6-27B with MTP should fit in 32GB with almost full context length for Unsloth's 5-bit quantization. That's my preferred choice for a local coding agent on similar hardware: the quality delta compared to a MoE model is IMO worth the extra wait. (And I haven't found a model with 70B-120B parameters that works better for coding.) For general chat, maybe gpt-oss-120b? It should have more general knowledge than a 30B-class model; I've used it to suggest itineraries for trips and to review the completeness of small requests for proposals.

I don't have recommendations for images because I haven't played with those.

HuggingFace says this model has 753B parameters, which will need a lot more RAM than a maxed-out MacBook Pro. With 40B active parameters, running from SSD would need patience.

The answer to the question posed in the site's domain name is "no", unfortunately.

It looks like it just grabbed the intro to each project's self-description, but blurbs like "Zero-cost ultra-high-performance declarative DOM library using FRP signals" would be worth very little even with screenshots.

Ignoring multiple evaluation, one can also #define stdc_has_single_bit(X) !((X) & ((X)-1)). If X isn't a power of two, the -1 will leave the MSB in place.

Yes, but presumably the authors are suggesting broader application than just caching a system prompt.

The paper's approach should work well if (a) you can calculate KV(A || B) as a function of KV(A) and KV(B) independently, (b) you can identify which documents A1, A2, A3, ... are used commonly enough to be worth caching, and (c) it is cheaper to buy and sell KV(A) on a market than to compute KV(A) when it is needed. Given the size of KV(A) I am not sure that (c) will become true even if people solve the open research problem represented by (a) and accept the state-of-the-art trade-offs known for (b).

Perhaps I overlooked something, but which part of this involved "fooling Go"? I would usually not call it "fooling" something to trigger a not-strictly-required rejection of a dubious trait, especially when best practice says to avoid that trait.

And the Russian system is named (the Russian words for) "Global Navigation Satellite System", but usually only called GLONASS because adding L, O and A is less confusing than having one name for super- and sub-sets in a single category.

The fourth global GNSS constellation is Europe's Galileo. NavIC and QZSS are regional GNSS constellations.

Two things amaze me about GPS. First, that there are still four Block IIR and seven Block IIR-M satellites operational; these had 7.5 year design lives and were launched by 2004 and 2009 respectively. Second, that L1C, L5 and L2C are all still pre-operational thanks to the OCX debacle. L1C and L2C really modernize the signal structure to improve accuracy.

Based on the wording of the law, I think the relevant transmission is when the damage-causing command goes to the LLM. Who causes that transmission? I would say it's the person who wrote software to generate the command.

It's a general principle of US law that warranties cannot disclaim liability for intentional misconduct or gross negligence, and prompt injection malware is intentional misconduct.

This isn't legally very much different from other supply chain attacks that steal data or credentials, or act as ransomware. That is why people object to this open source software.

> all the flows where a model has the initiative are strictly biased towards unwarranted stops

Can you elaborate on what you think causes such a bias? My experience is that Qwen3.6, Claude Sonnet 4.6 and Opus 4.6/4.7 will work as far as they can given direction and a way to test their work. My so-far limited experience with Opus 4.8 is that it does stop somewhat earlier for feedback, but in places where I am glad it is checking assumptions or where I agree with it identifying a change in scope (for example, where the following work deserves a separate commit or merge request). I would call those justified stops rather than unwarranted.

Hi! If you want people to think you are a human, you should not mistake one of them for an entirely different one, and you should not refer to yourself in the third person.

I do not think it is "lazy". Those labels are ones that human fact-checkers have been using for a decade or more. I think those human fact-checkers use those terms knowing full well that there is overlap and ambiguity between them. So I think this study ends up mixing three effects: how LLMs interpret the claims as statements about the world, how LLMs reduce that to a four-category judgment, and the inherent ambiguities of those labels as natural language. It's a quantification of those three factors combined, but not powerful enough to distinguish their relative sizes.

You keep posting that. Do you understand the difference between that and "we anticipate that Go will never add generic methods"? What they actually said shows epistemic humility and recognizes that they might change their mind.

That is, in essence, the "squash workflow": https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

The big differences are that the jj approach gives you a commit message for the staging change, and lets you jump to some other commit without extra steps.

Well, "should you use binary logic?" has an easy answer: yes*. (* - sometimes). There are a lot of cases where it's obviously not the right framework, others where it's useful up to a point, and some where it's absolutely the right approach. The relative frequencies of encountering those categories depends on what one is doing.

> Another way in which it's not cheap to lose sight, I guess.

Seems like it would be a win-win to have a user setting to opt out of video in exchange for ungating that feature.

Your LLM should have bothered to notice that llmfit also has quality scores (and defaults to sorting by them). One might quibble about weighting of factors -- llmfit favors Qwen3.6-35B-A3B over Qwen3.6-27B, whereas I found the quality of the latter to be worth waiting for -- but it absolutely ranks models by quality.

Both my experience, and Anthropic's off-peak promotion, indicate that there are very uneven levels of demand for peak hours versus off-peak hours. How close do you think they are?

What's the basis for saying local tokens will always be cheaper? As others have outlined, LLMs serving one user at a time are pretty expensive, but concurrent users become much more cost-effective (assuming there's enough RAM for the contexts). If "local" to you means ~10 hours daily use by a team of employees, the company still has to balance against cloud services that can amortize non-recurring costs over 24 hours of service per day.

You will likely have to compromise on memory bandwidth or capacity under a $10k price. The Radeon R9700 has 32 GB of VRAM and is pretty cheap (~$1500 right now), which is what I primarily use. My home desktop has 128 GB RAM and my laptop has 96 GB RAM, but bandwidth limits make most models slow on those CPUs. Models with multi-token prediction are somewhat usable on them: Nemotron 3 Super runs reasonably well on my desktop but does poorly on agentic coding that I've given it; my laptop can run Qwen3.6-27B reasonably well with a version of llama.cpp that is patched for MTP support; but usually I run Qwen3.6-27B on my R9700. vLLM might support two or three R9700s on some OS, but I've not been able to get it to run at all with Ubuntu 26.04: system ROCm version is apparently different than what's in the container images, and system OpenMPI v5.0 finally removed C++ bindings that were deprecated in 2005 but are linked from some Python wheel that vLLM (probably indirectly) imports.

If you are spending $800/month on tokens you are likely to notice degradation for local models compared to near-frontier models. The models I can run locally are consistently worse than Claude Sonnet 4.6 (again for the work I give them), although Qwen3.6 does feel almost like magic for its size because it can do a lot. The really big open-weight models should be better, but they want 200+GB RAM, which will need a correspondingly expensive CPU.

I think you're not really engaging with his point, which is that RTC is a poor fit for communicating with an AI agent. I didn't read the blog as claiming that WebRTC is bad for what it is, only that it's a (very) poor choice for a voice-to-AI application.

I let Qwen3.6-27B chew on a bug all last night. It choked at some point and stopped responding (probably a context overflow before pi-coding-agent could compact it). Claude Sonnet 4.6 found and fixed the bug in under 10 minutes.

Qwen3.6 is pretty amazing for a 27B model, but it's not hard to run into its limits. With a Radeon R9700 and unsloth's 6-bit quantization, I get ~20 TPS and 110k context, so it can do a fair bit quickly.

The touch based key I use only responds once per touch. If someone compromises the machine it's plugged into, the action I expected to complete won't complete. This means the compromise becomes immediately visible.