if you are too busy to think consequently everything you are doing is without knowing any justification or explanation

"too busy" is arguing for ignorance, which is defensible but not agreed on

the only thesis/proposition i see in the comment would be:

"poor people don't think about it"

no other claims

Well, I didn't expect I would have to spell it out.

But seriously think about it. Why doesn't your pet dog sit around thinking about what a farce life is?

How many people who were living in the 1700s do you think sat around thinking life is a farce?

Ponder on that question. Out of everyone living in the world today, how many people do you think sit around thinking life is a farce, who are those people? Why do you think they are thinking this?

I think it's an important question to ask and think about. It's saying something about our society, way of life, way of seeing the world.

So poor people and historical people are in the same bucket as dogs, got it.

How lucky we are to be the only generation in history capable of thinking and reflecting!

i would use this, but for the privacy issues:

- no zero data retention available for the router itself (rights to retain data flagged by content scanning).

- no stated privacy policies for the providers served on the api. quote: "we work with providers to understand their policies and can provide information about specific providers on request".

on openrouter, on the positive side, they have transparent retention agreements for almost all providers, and also offer zdr.

i wish there will be a time where privacy is for everyone, not just for people who can afford an enterprise sla

trying to get genuine zero data retention agreements is one of the most exhausting things to do because data retention policies are so opaque or non-existent.

aws, azure, cohere, mistral etc on here are all linked to generic privacy policies, it is impossible to tell what retention sla is in place.

to the credit of openrouter, they do state the data retention policies of almost all, but not all of their providers.

you can check the retention level for models on openrouter with the providers list. i was not able to find a retention policy for their plugin providers (exa and parallel). both log by default with enterprise opt in for zdr.

#Telemetry FUCK OFF export DOTNET_CLI_TELEMETRY_OPTOUT=1 export ASTRO_TELEMETRY_DISABLED=1 export GATSBY_TELEMETRY_DISABLED=1 export HOMEBREW_NO_ANALYTICS=1 export NEXT_TELEMETRY_DISABLED=1 export DISABLE_ZAPIER_ANALYTICS=1 export TELEMETRY_DISABLED=1 export GH_TELEMETRY=false

Also:

  # Atlas
  export DISABLE_TELEMETRY=1
  # CloudFlare
  export WRANGLER_SEND_METRICS=false
  export VERCEL_PLUGIN_TELEMETRY=off
  # AWS
  export SAM_CLI_TELEMETRY=0
  export CDK_DISABLE_CLI_TELEMETRY=true
  # ???
  export DO_NOT_TRACK=true

Also.. Easily opt-out from telemetry collection https://github.com/beatcracker/toptout (last commit 3ya)

you can use a safety model trained on prompt injections with developer message priority.

user message becomes close to untrusted compared to dev prompt.

also post train it only outputs things like safe/unsafe so you are relatively deterministic on injection or no injection.

ie llama prompt guard, oss 120 safeguard.

Unfortunately it's not that simple. Self-policing AI systems will always be gamed. Just one [0] example of this among many.

[0] https://www.hiddenlayer.com/research/same-model-different-ha...

when ai is dead we can use all those gpus for zucc's metaverse xD s

there is no way to cap your billing on gcp.

you can get notifications but that's it.

i don't want to get throttled below my quota but some type of spend limit would be good.

and the notifications can be delayed because the spending system is not updated in real-time, so even if you have a Cloud Task triggering on spending to disable the project it may be too slow and several thousands may already be spent.

Is there a cloud provider that does have hard unbreakable billing caps? Everything I've seen has always been notifications or soft caps.

Not talking about fixed-access things like a Hetzer box.

Bunny.net purports to have a pay-as-you-go prepaid credit system that sounds like it works the way people want, and with their description of the way it works probably being sufficient to be legally enforceable if it turns out that it actually works differently and you were to end up with a surprise bill from them. And evidently it really does work that way; see this post from a couple weeks ago: <https://hackernews.hn/item?id=47676416>

The only other provider known to work that way is NearlyFreeSpeech.NET, which serves a completely different market segment (so much so that it might as well not even be considered the same kind of product/service).

Prepaid only is a fantastic idea, especially for dumb-ass startups. Limiting your liability to $100 or so sound like a big-ass W.

Yes, pre-paid would be fine and it's a well-understood pattern.

No need to retire API keys.

Nobody is thinking about the stock owners, I see

> Of course it doesn't have to be perfect, but even approximating perfection doesn't look much different.

It's pretty easy to get right, if the provider allows you to go (slightly) negative before cutting you off.

> Also, can you imagine the kind of downtimes and complaints that would inevitably originate from a fully synchronous billing architecture?

Doesn't need to fully synchronous.

Open ai has this

Prepaid only is a fantastic idea, until your site goes (desirably) viral and then gets shut off right as traffic is picking up, or you grow steadily and forget to increase your deposit amount and suddenly production is down. Billing alerts are a much better solution IMHO.

No you big dummy, that is especially when you want to limit your liability, lol.

Because these days it will be all worthless bot traffic.

Prepaid/paid limits with shutoff is appropriate for this though.

If you have per key limits, this is not possible, and even in a wild situation you should b able to expect that your firebase key will not use 50k.

Let me choose. This common point seems more like a rationalization for the default behavior of hyperscalers. AWS isn't avoiding prepaid due to concern about my site's virality, just that prepaid = less money.

You can also have both, a cap and one or more billing alert levels below it. Some providers do this (e.g. IIRC Backblaze B2).

Yes in reality, and ideally, you can have both, but GP specifically said "Prepaid only" implying you can't have both (which is what I replied to)

Well, they should also have pre-paid only. Offer a few different options.

Oh please no. And the "alternatives" to API keys aren't going to help much either, they'll just add friction to getting started (as reference: see the pain involved in writing a script that hits gmail or calendar API)

cloudflare