Are there any coding plans for this? (aka no token limit, just api call limit). Recently my account failed to be billed for GLM on z.ai and my subscription expired because of this... the pricing for GLM went through the roof in recent months, though...
I bought a glm-4.7 subscription and paired it with with claude code. According to usage, I have already used millions of tokens, yet I have barely reached the prompt limits for the tier I have per the 5 hour window. I haven't done anything crazy with my prompts as well.
Now if this were something else billed per 1 million tokens it would have cost me a lot more.
Yet apparently the majority of LLM providers are billing for 1 million tokens.
What's the catch? What I am not understanding? What other providers have similar usage/pricing pattern?
I can't see any of the providers billing per 1 million tokens to be useful/cost effective at all for coding.
Granted, I am new to all of this, I want to see what the fuss is about so perhaps I am blind to something obvious.
The only medical condition I can think of which they would not disclose is pregnancy. That would lead to further questions and is controversial despite being very simple. Further evidenced by the fact that the affected crew member is unknown to the public.
What features have you used for shaping with pf/FreeBSD? I remember (around 8ish years ago) using dummynet with pf, but it wasn't supported out of the box and I used some patches from the mailing lists for this purpose. It wasn't perfect, at times buggy. Back then ipfw had better support for such features, but I didn't like the syntax just as much as iptables. I eventually settled on Linux as I have grown to understand iptables (I hate that nftables is the brand new thing with entirely different syntax to learn again... and even requires more work upfront because basic chains are not preconfigured...) but traffic shaping sucked big time on linux, I never understood the tc tool to be effective, it's just too arcane. I always admired pf, especially on OpenBSD since it had more features but the single threaded nature killed it for any serious usage for me.
I learned some Gleam a while ago, my familarity with F# helped, but I didn't find a use case for it. Some while ago I wanted to play with raw sockets so I figured, why not Gleam, its binary parsing syntax will be handy so I looked into the erlang sockets module and attempted to write some ffi wrappers for the necessary functions. Turns out it is not as straight forward, especially that the definitions on erlang side are often complex, with many variants and the dynamic nature doesn't often map very well to Gleam. The documentation was also quite sparse for interop. Interop also involves a lot of Dynamic types so encoding/decoding back which is cumbersome. Sooner or later I hit a wall. By virtue of reading Erlang docs to write the ffi wrappers I eventually got familiar with Erlang syntax which at first was quite alien, but turns out it is rather simple with just some rules to remember. I settled on writing Erlang directly. I am not sure how Elixir compares, never tried it, but I was initially put off by the syntax resembling Ruby, which I have fond memories of, but was always very implicit which I didn't like. Writing pure gleam is pretty fun, but a lot of interesting things require either ffi interop or decoders/encoders even for simple things like json which takes away some of that fun.