Anthropic had a special extra usage promotion going on during non-peak hours that ended recently.
They didn’t do a great job of explaining it. I wonder how many people got used to the 2X limits and now think Anthropic has done something bad by going back to normal
It very much depends on the workloads. If you inspect existing code (that somebody else wrote over the years) usage runs out quickly. If you are building your own greenfield stuff the sky is the limit.
For me it's surprising that they expected anything other than heavy utilisation at that price point. People don't subscribe at those prices and forget about it.
Perhaps. So let them come clean about what they can offer. At that price, people are going to make the best of their subscription whatever it is that's on offer.
Sounds backwards -- your company is getting the benefits of your increased productivity and doesn't want to pay for it. Im not sure that's Anthropics problem?
It's like I was a graphic designer and my finance company said "photoshop is too expensive". I wouldn't be mad at Adobe for it
You are not allowed to use multiple accounts to bypass the rate limit. You can only use different accounts for different uses like a work account and then a personal account. You can't rotate through 5 for personal use.
"Should be forbidden in companies"? I think you need to see some fresh headlines and read a few articles.
I presume that if you're such a vocal opponent of CC, you're also fighting using IDEs and other tools useful in software engineering, like CI pipelines?
Emacs/vim and make should be the maximum a person is permitted!
> If the programs you’re using refuse to let you remove those icons (or they keep re-adding them against your wishes) then those programs are bad citizens and you should probably stop using them!
I always love these types of arguments. Program does one thing bad so stop getting value of out it. lol.
You’re seeing that primarily because it’s what people can show off easily. Side projects they do for fun.
I use all of this stuff daily at work. Normally, I’m working on 2 to 4 features in parallel (so worktrees). This might not be simultaneously, but it’s at least across days or weeks.
Skills, agents, tasks, etc are really about creating repeatability in certain parts of my workflow without needing to be hands on.
The flip side of that is now you're running old software and CVEs get published all the time. Threat actors actively scan the internet looking for software that's vulnerable to new CVEs.
These tools are useful, but I can't help to feel like they're solving the wrong part of the problem. I really don't have much concern that an agent has access to one of my credentials. Outside of production, most of these credentials are going to be limited in privilege and self-rotatable.
What remains terrifying is the ability to exfil important data or run commands that are malicious.
In my experience, a lot of these types of migrations aren't incredibly deep in terms of actual code being written. It's about being able to assess all of the affected facets accurately. Once that's all mapped out, it's pretty straight forward to migrate.
Most of this isn't that damning. SOC IIs are already highly templatized, so pages matching up really isn't meaningful. In fact, an overly detailed or overly verbose template is more likely to have matching pages since you'd never have to add additional content to it.
System descriptions don't necessarily hold much weight. They're often more about giving a general shape of the system to help orient the reader, rather than providing a technically complete picture.
Most of the meat in these is about the controls being tested (which are semi-standardized within an auditor) and the results. Many of these controls are really basic and easy to get "no exceptions noted".
That being said, nearly everyone has at least one exception, even if it's minor. The fact that they didn't find any across all of their clients is a strong indicator they're not diving deeply enough.
Every time I look at graph databases, I just cannot figure out what problem they're solving. Particularly in an LLM based world.
Don't get me wrong, graphs have interesting properties and there's something intriguing out these dynamic, open ended queries. But, what features/products/customer journeys are people building with a graph DB.
Every time I explore, I end up back at "yea, but a standard DB will do 90% of this as a 10% of the effort".
In virtually all cases, you want a normal relational database and a sensible schema. Far easier and fewer sharp edges. Reaching for a graph database should never be the default choice.
A handful of data models have strongly graph-like characteristics where queries require recursive ad hoc joins and similar. If your data is small, this is nominally the use case for a graph database. Often you can make it work pretty well on a good relational database if you are an expert at (ab)using it. Relational databases usually have better features in other areas too.
If you have a very large graph-like data model, then you have to consider more exotic solutions. You will know when you have one of these problems because you already tried everything and everything is terrible. But you still started with a relational database.
A standard DB ala Postgres will be a perfectly functional graph database unless you're doing very specialized network analysis queries, which is not what most of these "knowledge graph" databases are being used for. It's only querying and data modeling that's a bit fiddly (expressing the "graph" structure using SQL) and that's being improved by the new Property Graph Query (PGQ) in the latest SQL standards.
This is the same topic I had an intense argument with my coworkers at the company formerly called FB a decade ago. There is a belief that most joins are 1-2 deep. And that many hop queries with reasoning are rare and non-existent.
I wonder how you reconcile the demand for LLMs with multihop reasoning with the statement above.
I think a lot what is stated here is how things work today and where established companies operate.
The contradictions in their positions are plain and simple.
I maintain LadybugDB which implements WCOJ (inherited from the KuzuDB days). So I don't disagree with the idea. Just that it's a graph database with relational internals and some internal warts that makes it hard to compose queries. Working on fixing them.
Also an important test is the check on whether it's WCOJ on top of relational storage or is the compressed sparse row (CSR) actually persisted to disk. The PGQ implementations don't.
There are second order optimizations that LLMs logically implement that CSR implementing DBs don't. With sufficient funding, we'll be able to pursue those as well.
CSR is an array-based trie hence very costly to update. It can serve as an index for parts of the graph that basically will almost never change, but not otherwise.
That's coming to Postgres 19 this year, had a brief exchange with a committer earlier this week and it's actually available in the Postgres repo to try (need to run your own build of course). Very exciting development!
For starters, LLMs themselves are a graph database with probabilistic edge traversal.
Some apps want it to be deterministic.
I'm surprised this question comes up so often.
It's mainly from the vector embedding camp, who rightfully observe that vector + keyword search gets you to 70-80% on evals. What is all this hype about graphs for the last 20-30%?
It comes from people who develop LLMs. Anthropic and Google. References below.
My other favorite quote: transformers are GNNs which won the hardware lottery.
Longer form at blog.ladybugmem.ai
You want to believe that everything probabilistic has more value and determinism doesn't? Or that the world is made up of tabular data? You have a lot of company.
The other side of the argument I believe has a lot of money.
2 weeks ago, I had only hit my limit a single time and that was when I had multiple agents doing codebase audits.
reply