Most LLMs output a whole bunch of tokens to help them reason through a problem, often called chain of thought, before giving the actual response. This has been shown to improve performance a lot but uses a lot of tokens

Yup, they all need to do this in case you're asking them a really hard question like: "I really need to get my car washed, the car wash place is only 50 meters away, should I drive there or walk?"

One very specific and limited example, when asked to build something 4.6 seems to do more web searches in the domain to gather latest best practices for various components/features before planning/implementing.

I've found that Opus 4.6 is happy to read a significant amount of the codebase in preparation to do something, whereas Opus 4.5 tends to be much more efficient and targeted about pulling in relevant context.

And way faster too!

They're talking about output consuming from the pool of tokens allowed by the subscription plan.

thinking tokens, output tokens, etc. Being more clever about file reads/tool calling.

> Interestingly, the malware checks for the presence of Claude Code CLI or Gemini CLI on the system to offload much of the fingerprintable code to a prompt.

Can anyone explain this? Why is it an advantage?

Some AV / endpoint protection software could flag those files. Some corpo deep inspection software could flag those if downloaded / requested from the web.

The cc/geminicli were just an obfuscation method to basically run a find [...] > dump.txt

Oh, and static analysis tools might flag any code with find .env .wallet (whatever)... but they might not (yet) flag prompts :)

The malware is not delivering any exploits or otherwise malicious-looking code, so endpoint security is unlikely to flag it as malicious.

That’s because it’s new. Perhaps feeding prompts into Claude Code and similar tools will be considered suspicious from now on?

Furthermore most people have probably granted the node binary access to everything in their home directory on macOS. Other processes would pop up a permission dialog.

It seems they are: https://developer.chrome.com/docs/ai/built-in

Really excited to see this shipped & hopefully get cross-browser support

In the demo, is there any specific reason that the voice doesn't go "up" in pitch when asking questions? Even the (many) rethorical questions would in my view improve by having a bit of a pitch change before the question mark.

There’s no SSML. The model that came up with the text knows what it’s saying in theory and therefore would know that it’s a question, if the mood should be sombre or excited and then can pass this information as SSML tags to the text to speech synthesizer. The problem I’ve been seeing is that pretty much all of these models are just outputting text and the text is being shoved into the TTS. It’s on my list to look into projects that have embedded these tags so that on the one hand you have like open web UI that’s showing a user text, but there’s actually an embedded set of tags that are handled by the TTS so that it sounds more natural. This project looks hackable for that purpose.

At [previous company], we initially required branches to be up to date with main. Since it was a relatively big mono repo, it slowed down productivity quite a bit.

Eventually we tried dropping that requirement and instead relied on testing main before deploying to production. It sped us up again, and main never broke because of bad merges while I was there.

I give up, why?

It's FOSS. And you get rickrolled by the pricing link.

Never give up! https://www.youtube.com/watch?v=KxGRhd_iWuE

I can't tell if your "give up" is a reference to the "never gonna give you up" line from the rick roll video. The internet is a web of labyrinthine references, and I don't know what means what, if anything anymore.

Context window is how long your prompt can be. Output tokens is how long its response can be. What you sent says its response can be 64k tokens at maximum.

It is possible, since spending has an API. I’ve recently implemented it on Azure for a company, to ensure our storage costs didn’t run wild.

Couldn’t find an out-of-the-box solution, maybe, as you say because it’s not in their interest.

Couldn't get the code to run with Perl on Mac:

   $ plenv exec perl midi.pl
   Not enough arguments for main::pedal_notes at midi.pl line 107, near "$note)"
   BEGIN not safe after errors--compilation aborted at midi.pl line 150.

I got something similar working in Supercollider though, which has a lot of tools for these sort of things, eg:

   MIDIIn.addFuncTo(\noteOn, ~myNoteOnHandler);

Very impressive. Also interesting that the motion type prediction ("is this a moving train?") generalizes to underground trains in other cities.

I see they support the the largest cities in Sweden and Norway, wonder if there are any plans for Copenhagen, Denmark?

While I understand your question is about the Transit app in general, I'd just like to mention in correlation to the article that my team and I worked with one of the public transport operators in Denmark, to utilize the motion predictability feature found in Android and iOS SDK's, so I can enlighten you with some details regarding that.

Our conclusion was that the feature didn't work in the danish metros for reasons we never got to deep dive into. It's most likely related to the fact that many of the metro stations are built in concrete, as such there's no GPS data in most of them unless you're very close to or on the surface and no motion data.

I'd be surprised if they got this particular feature working but who knows... maybe if we had looked into the raw sensor output we might have been able to work something out.

In the end we made a solution to help determine when you're moving or not by utilizing beacons.

> no motion data

How come there's no motion data?

Let them know you’d like CPH !

Especially if you know someone at the transit agency or can help them even in a very small way.