It's interesting that all three of those used roughly the same amount of tokens, and almost entirely output. Feels like the thinking level lever didn't alter cost at all for this specific task, even though it did change the output.

I never trust OpenRouter to forward parameters correctly and would only ever conduct benchmarks with the official api, personally.

should use an open source one you can audit like my site TrustedRouter

That raises the question of what is it actually doing?

If it isn't spending tokens on quality, is it the assumptions about the task difficulty that cause it to perform better? Or are their broader differences in the model being run.

50% cache hit is really low - in a standard agentic loop you should expect like 99%+ cache hit percentage (which should also lower that $12.50 to like a couple of $ for the same amount of tokens).

If you're using a customised harness you should make sure you don't have something that's e.g. changing your system prompt on some requests or rewriting history - it can be tempting to do stuff like strip old thinking tokens or compact tool call results to reduce context size but it's a trap - you want to never change history because of how cheap cache is, even more so with deepseek because their cache hit pricing is so low compared to most other models.

In my experience, that's the OpenRouter tax. Even a session that does everything right to remain sticky ends up getting moved between providers on a few requests, which bills you the full context as input every time the switch happens.

I assume it's done as load balancing/latency mitigation, but it's put me off of OpenRouter for my use cases (limited use, limited need for changing models).

This has not been my experience. Generally I do pin to 1 provider, or 1 provider with a couple fallbacks (especially with deepseek - most providers are 10x the cached token price compared to deepseek themselves), but even when I don't I still usually see 99%+ cache hit percentage. Specifically using pi with various ad-hoc customisations (that I was careful not to break prompt caching with).

then what is the point of using operouter for this model? Just use the deepseek API and save the 5% fee on top of the better caching rate.

Because they don’t want to sign up for 10 different providers and subscriptions/etc, especially if some models are just going to receive light, or rare usage?

Why not pin to specific openrouter provider and disable fallback?

There is only one provider for this model, so shouldn't be running into that.

Seems like pro 0813 is exclusively served by Deepseek themselves at the moment so I wouldn't say that's the case?

It is a pain from openRouter if you don't define your providers correctly, but for DeepSeek, surely not- the weights aren't released yet and there's only one provider, DeepSeek.

With Deepseek as the provider, there's no issue of course, but that means you don't filter providers for data retention, and you could also choose direct API use with them at that point.

Fallback are still very useful and won't poison much your cache hits too much if the provider is down anyway.

That’s a very heavy tax tbh.

You can set it up to always use the official provider.

Thank you for the advice but it looks like it's an issue with Deepseek's dashboard, I think they are calculating the value incorrectly.

This prompted me to dig back through the logs, it seems to be closer to 96% at its absolute worst and 99.3 at best.

I only sell to openrouter, would much rather support Deepseek directly.

I just assumed this was what all phones with multiple rear cameras were doing, is it not? What are the multiple cameras for other than that?

Each camera has a different optical system with a different focal length range. This lets the camera cover everything from ultra wide angle to telescopic magnification while remaining thin enough to fit in a phone.

Phones can't fit a zoom lens with moving elements. The other cameras are just other prime lenses so you aren't restricted to having a single focal length all the time.

When you hit the little 0.5x, 1x, 4x buttons in the camera app you are switching between the physical cameras. Though Apple goes out of their way to obscure what is actually happening.

The obvious issue with the product here is that the telephoto lens will not cover the whole image that the 1x captured so only some portion of the center of the frame will be higher resolution.

I read that and thought "ah that's going to confuse people, but I can tell they mean 30k-250k loc", so thank you for the clarification.

The capital investment needed to bring new chip fabs online and to staff them is likely orders of magnitude higher than that needed to buy land to grow corn on. And then the ratio of investment to sell price on that land + infrastructure is probably significantly worse for chip fabs that potentially aren't needed to satisfy demand anymore a few years from now.

"If the price is high enough" is of course technically true, but the scale of what high means in this context is important.

I love hacking away at pi extensions.

I realised how use case dependent harness behaviour is when I tried to use my customised-for-a-side-project pi config at work and realised I needed to tweak it significantly to be useful - I would not be surprised if tools like Claude Code needing to be all things for all people is hurting their peak usefulness.

End up building Pi extensions instead of actual product.

Doesn't make sense to me, but to each their own.

Yeah this seems pretty strange to me, I feel like I don't really care about messing around with all the tooling surrounding AI. I just want to get my actual work done. When I first moved to VS Code from Sublime Text I think I spent maybe 15 minutes setting up a few extensions like Emmet and then never really thought about it again - because I had actual work to do. I've just been waiting for all the constant change around AI coding to die down, assuming whatever is best will emerge and then I'll just use that.

Yeah, but the future will essentially be building extensions for agents. Agents will become the new web browser and extensions will be the new apps. We are already seeing the early stages of this.

how many extensions do you need for browsing the web? Adblocker. Not much else because the browser already does the important work.

Same with any of the off the shelf harnesses.

Go build something useful instead of tweaking the minutiae of the harness.

You don't need any extensions to use Pi. You can get far without any.

This is cool, but I gotta say - I care much more about keypress-to-screen latency on my terminals than throughput - would love to see some numbers on that.

It's VERY difficult to measure. But I can say that shitty has the best damage tracking model among foot/kitty/alacritty/ghostty. It's best in the sense that it's cell-exact; I only draw to the screen what has actually changed.

Furthermore, on Linux, I reuse buffers from the swapchain after the wayland compositor returns them, and I only update the areas that changed after I sent the buffer to the window system. In other words, I'm provably doing the minimum amount of work possible. Unfortunately, this isn't possible on MacOS, since the Metal documentation states that it can (and does) corrupt a buffer while displaying it.

Basically, based on code, not actual measurements, shitty is the best terminal in terms of change delivery latency.

> I'm provably doing the minimum amount of work possible.

That is a very bold claim to make for the amount of render code generated by the LLM. It's not obvious what the critical path even is, which is what would bound the latency. And I mean actual code, not just some informal description of what happens.

If you say 'provably', you should offer the proof. In Lean perhaps? But in English is also ok.

these days on HN, if you oppose someone, you get dead-flagged.

I vouched for your comment, as I find it perfectly 'not agreeing' answer.

It wasn't me flagging, by the way.

The burden of proof also falls on the person making the claim.

Sorry, but you simply prompted an LLM and didn't even bother reviewing the output per our other discussion about pthreads. I'm not sure you can claim to be an expert, let alone put your opinion on the same level as mine.

If you truly want low latency input on a Mac then your Terminal app needs to be able to run full screen to enable Game Mode: https://support.apple.com/en-euro/105118

I've found the process of building good reliable CI that thoroughly covers everything has been greatly improved by LLMs. There's so much tedious plumbing and grunt work involved in building CI and automated testing infrastructure for bespoke products that they can handle just fine while you concentrate on the important bits - I would say it's an area where agentic workflows are even more suited than regular product code.

100% coverage and useful tests aren't the same thing. Why are we still not aware of this?

I'm speaking in the context of building scaffolding for e2e testing, not the tests themselves.

When I say "everything" I mean the frontend, backend, database, seeded data, optimizing runtime etc, I'm not talking about loc coverage. I would not recommend using llms to generate the tests themselves without heavy guidance and review, and you're right that 100% coverage is often a counterproductive goal if the code under test is anything less than pure business logic.

Yeah I'm on the same page - I spend a couple hundred bucks on a low-end-of-midrange android phone every few years (usually because I broke the old one by doing something stupid like walking into the ocean with it in my pocket). I can't fathom why I would want to spend 5-10x on a flagship to do... what exactly?

My current phone (Motorola g34) runs all the games fine, and that's probably the heaviest thing people use phones for. I do take photos, but like I'm not running a photography business, and social media compresses them to shit anyway so the quality is perfectly fine.

Well, you could buy a waterproof phone, which wouldn't break if you walked into the ocean with it in your pocket?

I use my phones as GPS attached to my motorbike's handlebars. They get drenched in downpours, frozen in the winter, and baked in the summer sun multiple times a year. They don't skip a beat and only require the occasional battery change.

My current phone is an iphone 14, still on its original battery. It replaced a 7 which had its battery changed 5 years in. The 7 replaced a galaxy s5 which I stupidly forgot in a taxi, but it was still good enough for my uses.

There are uses for higher-end phones, among which "longer periods between changes".