One thing I noticed is that there's no cost tracking, so it's very hard to predict how much you're spending. This is fine on tools like Cursor that are all inclusive, but is something that is really necessary if you're bringing your own API keys.

Is this feature on the roadmap?

This is a great suggestion. We're actually storing the input/output costs of most models, but aren't computing cost estimates yet. Definitely something to add. My only hesitation is that token-based cost estimates may not be accurate (most models do not provide their tokenizers, so you have to eg. estimate the average number of characters per token in order to compute the cost, and this may vary per model).

It'd probably be useful to just show cost after the fact based on the usage returned from the API. Even if I don't know how much my first request will cost, if I know my last request cost x cents then I can probably have a good idea from there.

Is there anything similar to this that would support arm64? Unfortunately lldb is still not on par with even gdb.

Ok you just blew my mind with this pattern. I created a similar From trait only to take in an extra param so many times. Thanks for this.

Just tried it and it's indeed very good, thanks for mentioning it! :-)

Well, take that into consideration then. Just make it an option. Instead of getting 1000 requests per day with code, you get 100 on the $10/month plan, and then let users decide whether they want to migrate to a higher tier or continue using the API model.

I am not saying Claude should stop making money, I'm just advocating for giving users the value of getting some Code coverage when you migrate from the basic plan to the pro or max.

Does that make sense?

> ... usage limits that would make it very difficult to use for Claude Code.

Genuinely interested: how's so?

Well, I think it'd be pretty irritating to see the message "3 messages remaining until 6PM" while you are in the middle of a complex coding task.

Conversely I have to manually do this and monitor the billing instead.

No, that's the whole point: predictability. It's definitely a trade off, but if we could save the work as is we could have the option to continue the iteration elsewhere, or even better, from that point on offer the option to fallback to the current API model.

A nice addition would be having something like /cost but to check where you are in regards to limits.

I totally agree with this, I would rather have some kind of prediction than using the Claude Code roulette. I would definitely upgrade my plan if I got Claude Code usage included.

I don't what you guys are on about but I have been using the free GitHub Copilot in VS Code chats to absolutely crank out new UI features in Vue. All that stuff that makes you groan at the thought of it: more divs, bindings, form validation, a whole new widget...churned out in 30 seconds. Try it live. Works? Keep.

I'm surprised at the complexity and correctness at which it infers from very simple, almost inadequate, prompts.

They did it!

I did that, but not as a way to abuse the system. I used to export all my streams to YouTube directly from Twitch without downloading it first. I would just trim the beginning of the stream and sometimes split in more than one video if I had multiple content in one stream. I have hundreds of videos starting from 2018. I just thought this was ok and now I'm going through the effort of exporting them individually to a youtube account. I wish they had offered at least a way to export or download them in batch.

Very useful, thanks for sharing.

Claude working fine here. And I think parent meant affected because of the increased volume.