I had that for a few months and cancelled. They have minutely rate limits as well so you get 3-4 hyperspeed responses and then a 45 second pause waiting for the throttling to let your next request through.
And then, depending on what you're working on, the 24M daily allotment is gone in under an hour. I regularly burned it in about 25 minutes of agent use.
I imagine if I had infinite budget to pay regular API rates on a high usage tier, it would be really quite good though.
> They have minutely rate limits as well so you get 3-4 hyperspeed responses and then a 45 second pause waiting for the throttling to let your next request through.
I haven’t really gotten that, though have noticed on some occasions:
A) high server load notifications, most commonly, can delay an answer by about 3-10 seconds
B) hangs, this happens quite rarely, not sure if a network issue or something on their side, but sometimes the submitted message just freezes (e.g. nothing happening in OpenCode), doesn’t seem deliberate because resubmitting immediately works, more often than not
> And then, depending on what you're working on, the 24M daily allotment is gone in under an hour. I regularly burned it in about 25 minutes of agent use.
That’s a lot of tokens, almost a million a minute! Since the context is about 128k, you’d be doing about 8 full context requests every minute for 25 minutes straight.
I can see something like that, but at that point it feels like the only thing that’d actually be helpful would be caching support on their end.
You must be on some pretty high tier subscriptions with the other providers to get the same performance!
Interesting. I'm also nearsighted, so I've always assumed that I don't need glasses when wearing VR headsets. It's easier to just take them off before putting on the headset (MQ3) and I've not noticed a difference in clarity — but I do experience eye strain and visual exhaustion if I wear the headset for too long, so it might be worth comparing longer sessions with and without glasses.
Nothing's stopping users who want an AI summary from feeding the content into their favourite GPT. But it's not contributing anything meaningful to a HN discussion.
Yes, as everyone knows, you are only entitled to an opinion about software if you are also a successful business entrepreneur without external funding.
Good type systems increase velocity by leaving less room for error, so that you don't have to waste half your time debugging and fixing issues that could have been easily prevented. They also provide helpful structure and an IDE experience (the right values, functions, actions, etc are actually suggested for you wherever you are) that really does speed up development a lot.
There's of course always a trade-off: bad type systems can get in your way with boilerplate that you have to wrangle. But I don't think that's the typical experience.
> Yes, as everyone knows, you are only entitled to an opinion about software if you are also a successful business entrepreneur without external funding.
That's not it. I disagree with the GP, but they do have a point: coding for pay, coding for fun, and coding for your own business are all markedly different. So the question whether something works or not in one of those contexts is a valid one.
I disagree with conclusion, though. Successful products are written in whatever the authors know intersected with whatever will get the job done. If you're Chuck Moore and work on embedded stuff, you'll use Forth and will be hugely successful, running circles around your competitors who use C. The relative strengths of a static type system vs unityped language are more than offset by familiarity and experience of the authors.
The story changes a bit when your product grows and you need to hire a larger team of people to work on it. The benefits of a static analysis become more pronounced when the codebase gets bigger. However, if you somehow luck out and get a team of highly competent people, they will use whatever mechanisms are available to make your larger codebase still tractable, even if they use Lisp, PHP, or PERL.
You can bet on something that explodes (Windows Phone...) and then your product gets done in by the choice of tech. Outside of those cases, though, the tech doesn't matter that much. Whatever you do, you'll have problems. Going for a really powerful language will severely limit your choice of libraries. Going with the most common language will leave you fighting decades of accrued nonsense. Going with statically typed language (without sane macros) will lead to lots of boilerplate code and will severely limit what you can do on runtime with the code (unless you use reflection, but then you're back to untyped land). Going with unityped/untyped language will make you hunt the inter-dependencies between your modules and you'll likely become conservative with removing old code (and other forms of refactoring) as a result.
Finding a right trade-off for a tech for your product is never about a single feature of that tech. It's about a complex interplay of what you have, what you think you can get, and what you want to do.
It does. Here in the UK at least, it's usually a lot cheaper to take cards than to pay transport (this is a real pain) and deposit fees (the latter is 2% on top of a fixed monthly fee, for my business account) so its usually only tax dodgers that go cash only
I think in the US merchant fees for card transactions are much higher though so may be a different ball game over there.
I thought that was really clever when the supermarkets started offering cashbacks - customers get a means of getting cash easily and they reduce the amount of cash they have to transport and deposit.
Mind you - haven't used that for years and I think most supermarkets have stopped offering it.
