If you're not paying for the model through Open router, then which provider are you buying it from? I thought that if that provider was listed on open router it would be the same price as going directly to the provider? Are you buying from a provider that isn't listed on open router already?
> Are you buying from a provider that isn't listed on open router already
I am using openrouter with zdr guardrail which routes to any provider that supposedly doesnt train on user data. I also use fireworks (directly, not via openrouter) which is a provider promising zdr and has a bunch of open weights models. My issue is that these zdr providers dont transparently disclose caching/tokens etc and so they end up being far more expensive than directly using DS.
> OpenRouter has taken the stance that in-memory caching of prompts is not considered “retaining” data, and we therefore allow endpoints/models with implicit caching to be hit when a ZDR routing policy is in effect. [0]
OpenRouter doesn’t list DeepSeek as ZDR combined with Caching. Thanks for the tip of Fireworks as Fireworks has Zero Data Retention by default. [1]
It is lovely to see experimentation like this going on. I think this has a lot of potential with something like Haskell's green threading model, basically taking it up a notch and doing threading across pthreads instead of being restricted to the VM threads. Surely, if this can be well fleshed-out, it could be implemented at the compiler-level or library-level so existing multi-threaded Haskell software can switch over to something like this to squeeze out even more performance. I'm not an expert here, though, so ¯\_(ツ)_/¯ take my words with a grain of salt.
I can second this. NYC has plenty of companies accepting applications, but an extremely small number of interviews actually happen, and an even smaller number of people are getting hired. It feels like there are 200-300 job seekers for every job posting that makes it onto a job board, with titles like "Senior Software Engineer."
I think the hip thing to do is just use your spare time to build stuff, and organically learn from building stuff. Self-sufficiency, creativity and generally being a self-starter is what's hip. More time spent building translates into an incentive to pickup tricks and relying on yourself to find hip solutions to actual problems.
Do the people who think like seriously imagine that this is something reasonable and expectable, and not totally subjective to the style and habits of individual developers? I'm always baffled by managers or business people who seem to think quantification of productivity is easy. They must be incredibly lazy to not want to invest themselves in understanding what their developers are doing to gauge productivity themselves. Is this a sign of horrible management, or at least, as you say it, management that has become horribly out of touch with their developers?
You're not missing anything. What you and the author are describing (in terms of pattern/architecture) has existed for quite a while but was widely popularized recently by Facebook's [Flux](https://facebook.github.io/flux). The author is either naive towards current state of the JavaScript landscape or their just being arrogant about what is actually unique to 'functional' programming.
Thank you. The problem with HN-like sites is that they are nearly impossible to analyze, since they function more like crowdsourced link aggregators rather than original sources.
An example of a "good" (in my opinion) source is Sean Carroll's blog:
> The crux of my argument is relying on methodologies to write good software or to guide a design is pointless.
> Instead of trusting everything you read, you should question it an consider it in practice before you actually follow it.
But once you've questioned and evaluated it, its still a methodology. If you just mean you shouldn't take published methodologies on faith but consider how they work in your particular environment, that's widely accepted truth. Its, among other things, a central idea of the Agile software movement, as well as central to Lean methods (not just in software, either) and, more generally, to all models based around a Plan-Do-Check-Act cycle and variants thereof.
Its hardly a controversial or new observation, though there are plenty of failures to put it into effect.
>The crux of my argument is relying on methodologies to write good software or to guide a design is pointless.
I already got that. It's already in the title of your post. You're just restating the title again.
But in the body of the text, you gave your reasoning and arguments attempting to explain why it was pointless. I'm pointing out that your reasoning (e.g. "different definitions") does not support your title. You need to construct a better set of arguments to convince people of your thesis.
