So that seems about what you should expect.

The key question is how well it a given model does the work, which is a lot harder to measure. But I think token costs are still an order of magnitude below the point where a US-based developer using AI for coding should be asking questions about price; at current price points, the cost/benefit question is dominated by what makes the best use of your limited time as an engineer.

They're not quite growing that fast, but there's nothing inherently inconsistent between these claims... as long as the growth curve is crazy.

Can you share details on what you're experiencing with us? https://zulip.com/help/contact-support.

But for most other projects, it probably only costs $3 worth of tokens. So you should assume the bad guys have already done it to your project looking for things they can exploit, and it no longer feels responsible to not have done such an audit yourself.

Something that I found useful when doing such audits for Zulip's key codebases is the ask the model to carefully self-review each finding; that removed the majority of the false positives. Most of the rest we addressed via adding comments that would help developers (or a model) casually reading the code understand what the intended security model is for that code path... And indeed most of those did not show up on a second audit done afterwards.

It's inspiring to see that Anthropic is capable of taking a principled stand, despite having raised a fortune in venture capital.

I don't think a lot of companies would have made this choice. I wish them the very best of luck in weathering the consequences of their courage.

A way something like this could be interesting is if founders started donating 5% of equity when they started a company to an open source foundation like this one.

It doesn't impact the founder much financially: Success is very binary for founders. But in aggregate, if thousands of startup founders do this, there would be some hits and some of those hits could generate a significant endowment.

(You can also try to get people to donate who feel their success was built on top of open source, but I feel that after 10 years building a company to IPO, one's attention as a founder has likely been on business metrics and spending time with business people, not on technology and spending time with technologists, and that shift in attention can reduce people's feeling of gratitude for the amazing inheritance that is open-source software).

We were able to reproduce the search icon centering issue in mobile web, which is being fixed here:

https://chat.zulip.org/#narrow/channel/9-issues/topic/center...

I lead the Zulip project, and I'd like to clarify that Zulip's free community pricing does not have user limits, either in Cloud or self-hosting. The 10 user limit for free mobile notifications only applies to workplace/business use. Larger communities are encouraged to submit a simple form to get approved for notifications beyond 10 users.

And this complaint seems quite strange:

> Even for self-hosted plans, anything above the free tier requires a zulip.com account for plan management.

How would a paid subscription work without an account for managing it?

This is an important and timely topic, but I wish a more deeply researched article was the one being widely circulated.

For example, if you had it open on your laptop with a window open, suspend it, and open it up on a plane, you can read the last few weeks of message history, compose replies that will send when you regain network, etc. I do this regularly on flights.

We always have ideas for how to improve this further, and the mobile app doesn't do as extensive caching as the web app does, but it's not an issue of technical feasibility. The protocol was designed for mixed online/offline use from the beginning.

And Zulip is specifically designed by some very capable people to be resilient. While we can mess up future versions, but you can always run (forks of) the older version. And as discussed on our values page, we've worked very hard to make the code readable and maintainable. (Various professors use Zulip as a teaching codebase).

We've made a lot of investments in the goal of having keeping-the-lights-on work for Zulip to be doable with a couple excellent people working part-time. It's good for our ability to spend our limited time on improving the product. But it also means that it doesn't require a lot of people to care in order for Zulip to remain functional and maintained. And I certainly care quite a bit.

So while I'd certainly expect other maintainers to introduce a lot more regressions, especially if doing significant changes... If you like the product today, probably the option will exist to continue using roughly that for a long time.

(My understanding is we are far from the only web app broken by Safari 26, and we're working on it).

One of the other nice features of the new design implementation is there are handy settings for font size and line spacing. It turns out that different people have very different desires for how dense content is in chat apps, and empirically there's a significant portion of users with just about every combination.