> I always hated how the "Login" button is smaller on every website than the "Sign Up" button.

I always assumed that was because it's the least common flow. Once you've signed up, you're logged in, so the only time you should ever need the "login" button is on a new computer, or after logging out to switch accounts, or if the service offers a "remember me" checkbox (don't do that) and doesn't check it by default (definitely don't do that), or if the user genuinely wants to not be remembered (e.g. they used private browsing).

If you're having to use "login" on any regular basis, something in the overall flow needs improving.

Same for me too. Hunting for the login whilst a massive splash screen for sign up

Is it really that common? On some sites the only way to find signup is to first go to login page

People were not upset at Github for pausing new signups. It was the existing customers upset at token-based billing replacing their effectively unlimited $40 a month subscription.

If anything, this suggests Kimi K3 is underpriced, forcing rationing of compute resources. Anthropic even struggles to avoid 503 errors at the $50/mtok point.

Seems like a different problem. You can't offer hardware at a price you can't buy new hardware with, so there isn't much of a choice there. But pricing away existing customers simply to lower demand is a bold move, especially if you could simply solve the supply issue instead.

no...

Well, to be clear, there was some feedback (e.g. it was calling subagents and printing some thinking messages).

That said, yes, it is pretty common for me to wait 10, 20 and sometimes even 30 minutes without steering the model or looking at what its doing. I usually write a pretty detailed prompt at the start that describes the issue, the usecases, the testing to do and the definition of success; then I sometimes ask it to draft a plan and give it a read, but after that I just press enter, let it run and come back when it's done.

In the end I do a manual review, both of the code and the functionality, but most of the time I get exactly what I wanted.

Usually, the longer the AI works on something the crappier its output because that means the context is getting filled up.

If my AI prompt takes more than 5 minutes to execute, I'm almost certain to stop it and break up the task or be more specific about what files it should look at or what subtask it should tackle first. The people who let it run for hours are absolutely not getting anything worth keeping in the end.

I have workflows that run for 8-10 hours unattended regularly. This is on frontier models though.

But if I were to look in on them they’d be giving feedback during that time, but they wouldn’t need steering.

I recently had GPT 5.6 work on something for 54 minutes while I went to sleep

K3 is relatively slow, but 12 minutes points to the harness not the model IMO.

I have Claude workflows that it takes 30+ minutes to get any feedback while it thinks

What local model?

I feel like this is the right way to do it. Especially if you're using your own credits. Unless it's obnoxiously long task.

So often it'll cut off just as it's about to finish.

Moonshot AI has two subscriptions archetypes and the one they link to from their main page is the subscription for the web interface/research/agents/OpenClaw (that they host for you)

There is a small link below the tiles for these plans saying something "looking to use it for code? Use Kimi code" and upon clicking you'll get a basically identically looking subscription page with different sub prices and more quota

Non coding plans:

   * Plus (19 "base agent" -- wahtever that might be)
   * Pro (39 x2 )
   * Max (99 x6)
   * Ultra (199 x12)

Coding plans:

    * Starter (19 - "base coding")
    * Explorer (49 - x4)
    * Expert (99 x10)
    * Master (219 x25)

I stumbled on that when i tried Kimi K2.5 back when that was released.

It's also worth mentioning that the $20 get you a 0.25 priority for API usage - because the others get x4 priority. So get ready for a _slow_ experience

Yes, although then people came up with reasonable ways of parallelizing RNNs entirely or in part anyway. There's also the need for lookups in transformers. Queries still need to be multiplied with old keys, all of them, so RNNs don't have to be totally incompatible with parallelism. It's just that you can't have a matrix inside them like in the linear RNN h_t = Ah_t + Bx_t that you have to multiply together step after step. If A is an input-dependent scalar or something you can multiply together easily you're fine.

mLSTM layers are completely parallel (the update rule for the cell state is C_t = f_t C_{t-1} + i_t x_t where f_t and i_t are gates that can be computed from x_t alone, x_t is the input at time t and this means that you can compute F_s = \prod_{s<t} f_s as fast as a cumsum and an exponential and then compute C_t = \sum_{s<t} F_s i_t x_t, again as a cumsum, so it's as good as if though it were parallel). I think the sLSTM layers that are the other component of the xLSTM have something else like this and presumably there's some trick also to training the Kimi "delta attention" RNN.

I'm not sure whether this is hardware or optimization dependent to some degree, but I get the impression that good custom kernels are an important part of this kind of thing.

Yes, but how would it have been if the EU governments just piled on, subsidized whoever had reasonable qualifications who wanted to try, straight-up funded accelerator development so that the chips don't just become investment in US AI companies, straight up built the supercomputers for training, straight up offered access to groups that had previously had reasonable success in training some model.

I don't think it would even be that expensive. I think with EU chips we could do it for 20 billion EUR + 5 billion EUR per year. After all, an H200 doesn't cost 40k to manufacture, probably one-tenth, and if we are making the chips we can get the money circulating just as the Americans have.

Add in some state effort to create suitable training data-- maybe encourage academics to create some things that are AI-friendly, and let all the people trying have that. There would hardly be anyone in the game other than us if we went for this package.

We already have VSORA. Maybe Euclyd is ready soon too. If enough are ordered we have 85% of the inference need gone, so that whatever accelerators are freed can be repurposed for supercomputing and training? Maybe we could have some organized effort to make many of the VSORA and Euclyd chips so that the chips we need for training are freed up while we wait for our own training chips.

Edit: So in the end I think the thing we need to do is to order enough VSORA Jotunn8 cards and enough Euclyd cards that we flood the inference market so much that the price of H200eds etc. drops and we can buy them second hand and assemble huge supercomputers out of them. This may require some diplomatic effort from the commission, something like 20B EUR almost immediately and some coordination, but it's easy, it's doable and it requires only being a little bit decisive. Since these cards are faster less memory will be tied up in serving the models, so it'd have a positive effect on memory prices too, which in turn would have a positive effect on European supercomputer centers, who are currently of course constrained by high memory prices.

I just pay metered usage via OpenRouter. I've spent no more than $10-$20/mo, but my usage is, by the standards of so-called "agentic coding" these days, very light and confined.

I doubt my workflows match the profile of "daily driver" as you're conceiving of it. I'm mostly in the IDE chat box asking for a hand here and there, but no "long horizon" / big vision / architecture things. Occasionally, I'll solicit a general opinion, quite abstractly, which isn't very token-intensive. My contexts are tiny and I aim to keep them that way.

The only token-intensive thing I do is occasional analyses of open-source codebases along the lines of "what is the actual behaviour when message X comes in and is malformed like this?", or something else similarly far-reaching. For that, I use DeepSeek's Reasonix, which they savvily dropped at the exact moment the sting of Claude API pricing became a sensation. It's a very cache-oriented harness, and delivers on its promise of being very economical. I doubt I've spent more than $10 with DeepSeek over the months I've used it. When I want a harness to inhale a codebase and give me an answer, Reasonix has been the go-to for a while now, and it's great. DeepSeek-V4-Flash is enough for many simple things, though I just run it on DeepSeek-V4-Pro because it's so cheap that I don't care.

Currently this is still just going to Moonshot, since they didn't release the weights yet (scheduled for 27th).

I fully agree. This isn't my usual pattern. I have a Claude pro subscription + some money loaded into DeepSeek which is super cheap. Just wanted to try out Kimi K3 and sort of got into the flow with the personal project. I am definitely not going to be burning more cash on this once the current recharge amount runs out.