But the most significant change in modern science is not just about the amount of noise, but how we experience it. Noise is no longer understood solely as a problem that affects hearing, it is also recognised as a systemic environmental pollutant. Transport noise is now one of the leading environmental cause of illness in Europe, second only to air pollution.

256 GB model: $1,059 USD

1TB model: $1,299 USD

Preorder list randomized, goes out Sept 17th

Power supply not included, costs $29 (same as Steam Deck power supply)

3rd party addon available for color passthrough, Arcturus Vision Camera, $149

me and a friend were arguing about this and i think the part i left out before is AI

like even if you accept that leetcode was never supposed to perfectly simulate the job and is just meant to test reasoning/pattern recognition/grind or whatever, does it still work as a hiring signal today?

you now have AI that can look at a self-contained coding problem, reason through it, generate multiple approaches, optimize the brute force solution, explain the complexity, all in minutes. then you have tools like Cluely and similar stuff specifically built to sit alongside interviews

you can’t really just pretend those don’t exist

meanwhile the actual job has also changed. engineers are already using AI to write code, review code, debug things, generate tests, understand unfamiliar systems, etc.

so wouldn’t it make more sense to assess someone inside an actual codebase? give them a scoped repo, a task, maybe even an embedded AI assistant and see what they actually do with it

can they find the relevant code? understand the system? decide what needs changing? tell when the AI is wrong? make the change without breaking something else?

obviously you can still cheat and obviously i’m not saying “here’s our 10 million line production repo, you have 40 minutes”

but surely a whole codebase with context is harder to just outsource to some interview copilot than “here’s one neatly packaged algorithm problem”

so i’m genuinely curious why we’re still optimizing hiring around leetcode instead of adapting the assessment to how software engineering actually works now

Here I thought I had been insanely smart to buy a GPU from 2010 for $10 since the CPU is going to do all the encoding anyway. And because my previous card, a honking 3080, wouldn't have allowed for the other two capture cards to be installed, taking up all the real estate.

I have been trying to setup an Artix system on my own for two hours now, but GRUB won't install in CSM mode... I've tried UEFI on GPT, BIOS on MBR, BIOS on GPT... 😅 Boot partition with and without file system... 💀

I'll just buy a more modern yet slim card, I guess? Unless I wake up tomorrow and give researching the issue a chance.

Night👋🔌

The Stop Killing Games folks will love this.

CounterSide is a gacha game. It died on August 26th this year. However, some modders have provided infrastructure to host your own local server, so it can still be played.

You can also use console commands to give yourself however many gacha pulls, other currency, or gear you want. The story is fully playable, so the game can be treated like a single player RPG.

Some of the gamemodes don't work right (I hear Dive is broken), but the important stuff like the main story, side stories, and combat work fine.

The infrastructure that handles launching the server is here, though you will need to grab the assets (which the infrastructure calls a frozen client) elsewhere. The non-Steam variant seems to work best, though YMMV.

Paywall? https://www.removepaywall.com/search?url=https%3A%2F%2Fwww.ft.com%2Fcontent%2Ff2b75c8a-1060-4995-9c8d-00355aaffffc%3Fsyn-25a6b1a6%3D1

https://archive.ph/iTsHV

A post-trained Qwen 3.8 27B model was trained to be more efficient by identifying which tokens were linked to overthinking and penalizing them without directly "attacking" the reasoning length. Accuracy was then restored using a technique hinted to be On-Policy Distillation. The result was -58% thinking tokens, 1.95x speed up, and <1% accuracy loss, and the model was open-sourced for community feedback.

The model is available here: https://huggingface.co/ukisai/Swift-Qwen3.8-27b [1]

A GGUF [3] version (Q1-Q8) is also available, along with several community quants (Bartowski) [4] at even lower/higher precision. The community also created NVFP4, W4A16, and Uncensored [5] versions of the model on Huggingface.

This training approach is not a replacement for reasoning effort settings, chat templates, or token caps, but is complementary and targets a separate issue: overthinking and "anxiety-like" reasoning loops previously seen in PTQ, but also identified as prominent in BF16 models of this size class. Contrary to popular belief, these specific patterns do not contribute to answer quality when properly targeted. The thesis is that reasoning length is extremely important and should not be shortened by force, but rather optimized. This is demonstrated in the xhigh vs medium effort benchmark table below. The goal is to keep xhigh accuracy while reducing only the unnecessary part of thinking.

TLDR of the thought process, research, training, and benchmarks:

1. When running quantized Qwen 3.8 27B instances, random reasoning loops (referred to in the paper below as "overthinking errors") were a persistent annoyance. These random loops were persistent throughout medium and low reasoning settings.
2. A paper by Meta [6] was identified that is supposed to target this phenomenon in PTQ, but when used straight out of the box it produced mixed results.
3. The hypothesis was tested as to whether it was a matter of targeting the right keywords and tuning the parameters, so a large amount of different (out of distribution) domain (coding, language, vision, agentic) traces were generated using an 8xH100 box.
4. The traces with overthinking were grouped and "common denominator" tokens between them were found, targeting the most prominent ones.
5. An inference-time penalizer of those tokens was built as seen in the paper, with the hopes of simply generating traces and doing cross-entropy SFT over them.
6. This did not work at all, but the penalizer seemed to work much better than the tokens provided in the paper, and not only for lower precision models but for bf16 as well. Hence experimentation continued. A loss function was built using the identified tokens and LoRa SFT was run over the previously generated traces; reasoning seemed to fall off significantly but accuracy seemed to follow. The reasoning reduction seemed to generalize.
7. After a significant amount of tinkering (since the day of Qwen 3.8 27B release), the reasoning reduction was satisfactory. After that, ways of restoring accuracy were searched. Several methods were experimented with, including RL(GSPO), On-Policy Distillation, and using the ThinkingCap 3.6 27B adapter chunks, until the accuracy loss was satisfactory. It was restored to <1% loss on almost all OOD in-house tests.
8. Intensive benchmarks were then performed across several reasoning efforts, precision variants, etc. A few problems were encountered, one of which was that to get a reliable score, each benchmark needed to be run 10x (5x on base + 5x with the adapter, following the standard procedure on the Qwen 3.6 27B model card on Terminal Bench). After running it, the performance converged to 40-60% token reduction with <1% accuracy loss across GPQA, MMLU, Terminal Bench 2.1, LiveCodeBench v6, ERQA, C-Eval, IFBench, and HMMT25, with an exception being AIME26 with an accuracy loss of 4.6%, which was later linked to a bug during training with a specific token relevant for math-related reasoning being penalized. This is planned to be fixed in an updated release.

The benchmarks: (raw benchmark files here - https://github.com/UkisAI/Swift-Qwen3.8-27B-evals/ ) [7]

Swift-27B vs Qwen3.8-27B (BF16, all benchmarks ran x5, thinking effort xhigh)

| Benchmark | Qwen3.8-27B | Swift-27B | Median tokens | |

|

|

|

| | GPQA-Diamond | 88.4% | 88.3% | 58% fewer | | LiveCodeBench v6 | 76.8% | 81.6% (+4.8pp, due to default truncation in LCB it is not performance gain) | 46% fewer thinking tokens | | Terminal-Bench 2.1 | 66.7% | 65.8% | 39% fewer | | MMLU-Pro | 85.5% | 85.0% | 28% fewer | | C-Eval | 90.0% | 90.6% | 19% fewer | | IFBench | 73.5% | 71.8% | 51% fewer | | AIME 2026 | 98.7% | 94.0% | 50% fewer | | HMMT (Nov 2025) | 99.3% | 96.0% | 46% fewer | | ERQA (vision) | 67.5% | 66.3% | 55% fewer |

Token savings hold at every reasoning effort (mean thinking reduction): xhigh 41%, medium 23%, low 26% (albeit with accuracy losses of 1-4% on medium and 1-2% on low, which need further testing).

Swift at xhigh vs the base's own effort settings on GPQA-Diamond (198 questions x 5 seeds):

| Model / effort | Accuracy | Median tokens | |

|

|

| | Base xhigh | 88.4% | 6,642 | | Swift xhigh | 88.3% | 2,771 | | Base medium | 84.1% | 1,753 |

So Swift keeps xhigh accuracy at under half the tokens, and beats base-medium by 4pp at roughly 1.6x its tokens.

Paywall? https://www.removepaywall.com/search?url=https%3A%2F%2Fwww.bloomberg.com%2Fnews%2Farticles%2F2026-09-14%2Feurope-can-t-simply-import-ai-technologies-from-us-lagarde-says