> Over the past 48 hours, demand has pushed close to the limits of our current capacity. To protect the experience of existing subscribers, we're temporarily pausing new subscriptions and prioritizing compute for current members. Existing subscribed users are not affected.

Such a beautiful paragraph to read, a company that prioritizes their current customers and focus on keeping them satisfied instead of just focusing on fast growth.

• dymk

  yesterday at 8:11 PM

  I remember people being so upset when GitHub did exactly this. It was the right move then and now!

  • Stevvo

    yesterday at 8:14 PM

    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.

    • dymk

      yesterday at 9:37 PM

      People were absolutely upset with Github for pausing new signups. The token-based billing was a separate thing.

• Razengan

  yesterday at 7:32 PM

  > a company that prioritizes their current customers and focus on keeping them satisfied instead of just focusing on fast growth.

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

  • JoshTriplett

    yesterday at 7:41 PM

    > 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.

    • layer8

      yesterday at 8:34 PM

      > the only time you should ever need the "login" button is on a new computer, or after logging out to switch accounts

      That’s still more frequent per customer than signing up.

      It only makes sense when prioritizing growth over your long-term customers.

    • xboxnolifes

      yesterday at 9:08 PM

      Every website I've signup for I've also logged into at least once. Usually more than once. Frequency isn't the reason, it's optimizing for sign-ups. Once you get someone to sign-up, they're going to login even if the button is a little smaller.

    • pluralmonad

      today at 12:27 AM

      You sign up once and login an arbitrary number of times. Not sure how signing up is ever the more frequent path. I've signed up for things I use maybe at most twice throughout a lifetime. Logins I couldn't even begin to count.

    • interloxia

      yesterday at 7:56 PM

      I love clearing cookies.

      • dzhiurgis

        yesterday at 8:31 PM

        They can still follow you

        • two_handfuls

          today at 4:20 AM

          No reason to make it easy for them though.

    • yesterday at 9:09 PM

    • gunalx

      yesterday at 7:57 PM

      Your tokens should defiently have expiry times on the range that you would need to login again.

      • londons_explore

        today at 2:17 AM

        I would prefer a 999 year login cookie.

        A well designed browser stores the cookies with similar security to the built in password manager anyway

        • ffsm8

          today at 3:44 AM

          That's not true, you need to provide a password to read the passwords saved in the browser whereas cookies can be read without any hassle from the developer tools

          Cookies can also be queried programmatically, whereas passwords need to have the users auto fill active and interact with the input element

          Most extensions have effectively full access to your cookies, not to your passwords - which is a real attack vector (session exfiltration) which is actively being used by had acteues

          There are ofc server set cookies which are not programmatically queryable, but that's not the norm (and they're still visible via the developer tools, so the core statement remains untrue)

          • mmmmbbbhb

            today at 7:27 AM

            > Cookies can also be queried programmatically,

            Misleading statement, essentially untrue.

            > Most extensions have effectively full access to your cookies

            False.

            > There are ofc server set cookies which are not programmatically queryable, but that's not the norm

            That is the norm for login cookies.

            > and they're still visible via the developer tools,

            This is irrelevant to the argument.

          • watermelon0

            today at 4:32 AM

            I’m quite sure that server set cookies are the norm for authentication, at least where they are set from the server side.

  • mDyJzDPmBdG

    today at 9:25 AM

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

  • stranded22

    yesterday at 10:15 PM

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

• jgalt212

  yesterday at 8:37 PM

  So this is what Hetzner should have done instead of raising prices to calibrate supply and demand?

  • shiandow

    today at 12:48 AM

    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.

  • ashleyn

    yesterday at 9:20 PM

    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.

  • nchmy

    yesterday at 9:17 PM

    no...

• cyanydeez

  yesterday at 10:09 PM

  i'd clm down; the VCs are pumping so much money into AI, this might just be OpenAI/Anthropic pummping money into the token burning machine to try and distill their datasets (turn tables of course).

Personal anecdote: I exhausted my Claude usage yesterday so I decided to spend 20$ to try Kimi while I was at it. Logged in, paid, downloaded Kimi Code, set it to use K3 and prompted something along the lines of: "Check this repository and find all the settings that can be passed as input related to hardware, I/O, thread control or networking. Produce a report".

It thought for about 12 minutes and then told me I had exhausted my daily quota. (The next day Fable did the same task in 3m)

If you want to buy a plan for K3 do NOT buy the 20$ one.

• satvikpendem

  yesterday at 7:44 PM

  Codex works for this, it'll continue thinking and will answer the prompt even if your limit is reached.

  • wingworks

    yesterday at 11:26 PM

    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.

    • onlyrealcuzzo

      today at 1:36 AM

      Buys $10 worth of credits.

      > Codex, translate the entire PostgreSQL codebase to idiomatic Rust, make no mistakes.

      • therein

        today at 2:53 AM

        Next day do it in Zig.

        The day after that, Zig broke compatibility, fix that.

• kamranjon

  yesterday at 9:33 PM

  So I am likely coming from a completely different world because I use entirely self hosted models - but is it really common in your workflows to just wait for 12 minutes without any feedback? I am constantly watching my model and following the path it’s taking and cutting it off or steering it if it’s headed down a dead path. I was just curious if this is really common to just have no feedback for 12 minutes?

  • thevinter

    yesterday at 9:53 PM

    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.

  • roncesvalles

    yesterday at 11:27 PM

    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.

    • AussieWog93

      today at 1:12 AM

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

      This was definitely truer with older models but isn't necessarily the case now.

      They frequently do other things apart from navel-gazing that take a lot of time but get good results, like spinning up subagents to solve some hairy task in a loop.

      Stopping/distrusting long-running AIs is a habit I've had to unlearn myself.

      I frequently get good results from a 30+ minute Fable session, when I've asked it to do something complex (e.g. run the QA tester in a loop and eliminate all crashes, one commit per crash fixed)

      • SyneRyder

        today at 1:20 AM

        This is my experience as well. Lots of success with running one hour Fable sessions (one hour of API time). Not using a loop here, but there's often lots of documentation for Claude to go through first before building out the project.

        The main failure point for me with long running Fable sessions now is just that it might hit a safety guardrail and downgrade to Opus midway.

    • adam_arthur

      today at 1:02 AM

      Exactly.

      I've found 6 minutes or so the sweet spot for upper bound with 5.6 Sol.

      And it sounds like the OPs query above requires scanning throughout a large portion of the codebase, which will inherently consume a large number of input tokens. No locality to it.

  • kasey_junk

    yesterday at 11:28 PM

    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.

    • throwaway7783

      today at 12:49 AM

      What do these workflows do? I can't think of anything that needs to run for so long.

      • kasey_junk

        today at 1:01 AM

        Pretty straight ahead coding workflows. Most of my operational workflows are much simpler (because diagnosing an operational issue is much more time sensitive obviously).

        • ryandrake

          today at 1:32 AM

          As a casual AI code user, I can’t even go 30 seconds without claude grinding to a halt asking for permission to run a bash script for the 10th time.

          • kasey_junk

            today at 1:38 AM

            The first step is building a sandbox (vm, container, whatever) that allows you to trust the agent in its most permissive mode.

            This varies based on the maturity of my projects but most of my sessions live in VMs with very specific egress rules and permissions.

            • londons_explore

              today at 2:21 AM

              Frustratingly none of the coding harnesses seem to default to just firing up a docker container with the working directory mounted and letting the AI run wild inside the container.

              • kasey_junk

                today at 2:37 AM

                You can get that working for yourself trivially. My agent environment now has 3 different kinds of compute abstractions, 3 different agents and a nascent workflow engine in it.

                It works how _i_ want, which is really refreshing.

                • londons_explore

                  today at 7:07 AM

                  Oh I've built the same too. But it took me a few hours to work out the quirks, when it should just be the default.

            • ryandrake

              today at 2:15 AM

              I think this is an area where the developers of the agent harnesses should be spending a lot of effort. It's not reasonable to expect your users to set up and maintain a VM just to safely use a tool. When I run cmake, I don't have to worry about it accidentally deleting my root filesystem or posting my account credentials to github. Most of the command line coding tools I use don't even need/have a --dry-run option.

              • kasey_junk

                today at 2:22 AM

                Could be. But a) I don’t know why I’d trust them to do that when existing tooling means I don’t have to and b) this is not a new paradigm for me. I’ve been running most of my dev environments in sandboxed mode for a long time. I don’t trust npm either.

    • eru

      today at 12:16 AM

      I assume a lot of these 8-10 hours are spend calling tools and getting feedback from that?

      • kasey_junk

        today at 12:35 AM

        Yeah absolutely. And from other context windows for agents.

    • throw1234567891

      today at 12:04 AM

      I have the same on local models.

  • jdthedisciple

    yesterday at 10:59 PM

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

    • MRiabov

      today at 5:19 AM

      I had two agents work from 7pm to 6am today... a routine for me.

      Today we needed to migrate to a cheaper CI/CD provider and do a better robotic for a particular task. GPT-5.6 Sol.

  • danwitt

    today at 1:08 AM

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

  • _zoltan_

    yesterday at 9:51 PM

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

  • brcmthrowaway

    today at 12:02 AM

    What local model?

    • kamranjon

      today at 1:11 PM

      DeepSeek V4 Flash

• Altern4tiveAcc

  yesterday at 7:18 PM

  I had the _exact_ same problem. Got the 20 USD/month subscription from Kimi.com (paid annually), exhausted my 5-hour quota with a simple prompt on OpenCode + Kimi K2.7 through their API. Cursor got the same prompt done in minutes.

  According to their web interface, I'm also on 23% of my weekly usage. That feels crazy, as I do a lot more than that on the 20 USD Cursor plan, and never got even a warning.

  I thought OpenCode was doing something wrong, but you had the same issue with Kimi Code.

  • ffsm8

    yesterday at 7:41 PM

    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)
    

    > https://www.kimi.com/membership/pricing

    Coding plans:

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

    > https://www.kimi.com/code

    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

    • Altern4tiveAcc

      yesterday at 7:54 PM

      Thank you so much. I was about to ask you for links, since they have multiple domains that look similar (kimi.ai, kimi.com, moonshot.ai, etc.). I wasn't sure which one was the legit one, or if they all are.

      The plan I got is called "Moderato", which somehow isn't any of those 8... I'll try to read more about it.

    • sbochins

      yesterday at 9:34 PM

      That doesn’t appear to be the case anymore. They just have one set of plans: Allegreto, modereto, etc which apply to both the chat app and the coding apps.

      • KronisLV

        yesterday at 10:50 PM

        Can confirm, I see these monthly prices on both pages:

        Moderato: 19 USD or 15 USD annually

        Allegretto: 39 USD or 31 USD annually

        Allegro: 99 USD or 79 USD annually

        Vivace: 199 USD or 159 USD annually

        However, they're saying that the plans might get split up again:

        > New Membership Plans Coming Soon

        > Kimi and Kimi Code benefits will be separated. Existing subscribers are unaffected.

        > You can still buy the current plan before launch.

        Same as with the Tweet:

        > Going forward, we'll also split membership into two more focused plans: Kimi Membership for Kimi Web, App, and Work; and Kimi Code Membership for coding workflows. This will help us match compute more precisely and keep the experience stable.

        Problem is I don't know whether to pull the trigger on the annual Vivace now or wait for after the split - whether it's gonna be a cash grab afterwards on the account of the demand, or whether I might save some money if I buy it after the split.

• phyzix5761

  today at 1:44 AM

  I had the same experience with Claude the other day. I asked it for something fairly simple and it used up my whole 5 hour quota without producing the answer. Felt like a total waste of time.

• zeratax

  today at 8:26 AM

  kinda surprising to me after the macos web demo was apparently done on the $40 monthly coding plan which was like a 6 hour task

• throw1234567891

  today at 12:03 AM

  What's the app? nodejs todo app with a "database back end" in a text file, or a 1m line spaghetti code COBOL app from 1971?

I think the Kimi thing is super cool, especially that they have so many RNN/linear attention layers (3x more than they have full attention). I haven't yet tried it though. It seems like it would be extremely reasonable for long context tasks and I guess this fits the times.

I suspect that the reason it has so many parameters is the same reason that compute optimal xLSTMs have some many parameters, and the success of this model makes me a bit unhappy that we haven't gotten an xLSTM-style model of huge size developed in Europe.

Obviously these guys are very pragmatic, they're probably not committed to anything other than what works on their internal evaluations, so they still have ordinary attention layers in the model and so on, and one can't be guaranteed that the people who come up with a good model then do the engineering in an ideal way, but I still think the success of Kimi shows what could have been if we had enough big supercomputers for LLM training and made them available to the right people-- because this is basically Hochreiter's thing. It's RNNs, or well, mostly RNNs.

• georgeburdell

  yesterday at 6:32 PM

  Wasn't one of the original intents of the transformer architecture to get rid of RNN because they cannot be parallelized? Not an expert, just read a few papers several years ago.

  • impossiblefork

    yesterday at 6:40 PM

    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.

• michalsustr

  yesterday at 7:16 PM

  I talked with Hochreiter about 1.5y ago they should go for it and properly scale xLSTM to LLMs, not just playing around with few B params for experiments. They felt like they are too late to the game to get investment and traction. So much for European ambitions I guess...

  • impossiblefork

    yesterday at 7:50 PM

    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.

    • eru

      today at 12:23 AM

      What's their track record for other state sponsored high tech work?

      I remember a few high profile failures; but perhaps on average these things work out?

    • miohtama

      today at 3:40 AM

      The EU spends EUR 300B yearly on agricultural subsidies and social programs.

• alex7o

  yesterday at 9:47 PM

  Is it an RNN or a state space one, like qwen or there was an arch called mamba if I remember correctly. Or it might be closer to RWKV.

  Edit: I checked and it is similar to linear delta net uses by qeen.

I've been using Kimi for coding tasks for close to six months now, and haven't looked back. I'll periodically try something on Claude to make sure I'm not missing anything, but I've been very happy.

I just do the OpenRouter thing. My use of LLMs is narrow enough that cost is a negligible consideration either way.

• ignoramous

  yesterday at 7:28 PM

  Curious: On which plan? In my experience, their $20 plan is super inadequate as a daily driver (ditto for Qwen's $30/mo), though given K3, I'm tempted to trial $49/mo or $99/mo.

  • abalashov

    yesterday at 7:34 PM

    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.

In our multi-agent game coding evaluations, we usually see Chinese models struggle in one-shot reasoning but make up for it with tool use and iterating towards better solutions. Kimi K3 follows that pattern, ranking 19th in one-shot coding and 3rd in agentic coding (where the model gets a harness and tools and many calls to iterate toward better code). Only Sol and Fable have better average agentic coding submissions.

Agentic coding is what's most relevant to software engineers, but so is speed, which is a real usability issue right now. Third-party inference providers like Fireworks have bridged the gap for some previous releases.

It's exciting to see the open weights frontier becoming the norm. Competing on having the frontier model is going to be an increasingly difficult business.

Data at https://gertlabs.com/rankings?mode=agentic_coding

A breath of fresh air to pause new subscriptions rather than the Google approach of quietly nerfing the limits and hoping you don't notice you're getting less value for your monthly/annual subscription.

Limits may change without notice, including due to capacity constraints. When there’s a large increase in activity in Gemini Apps, we may change limits to maintain a high standard of quality. [1]

[1]: https://support.google.com/gemini/answer/16275805

Ive been pleasantly surprised with the quality of this model. Its really good at code review and PR review. But right now due to them being so overloaded + this being a big model, its SO slow. It takes forever to do a relatively simple code review.

• kzrdude

  yesterday at 11:15 PM

  Kimi K3 is on the opencode-go plan's price list now. I haven't confirmed it, but I guess that means it's available. (Not in Zen.)

• abalashov

  yesterday at 7:45 PM

  Try the OpenRouter route!

  https://openrouter.ai/moonshotai/kimi-k3

  • wren6991

    yesterday at 7:58 PM

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

    • abalashov

      yesterday at 7:59 PM

      Oh, okay. Didn't know that, as I haven't tried K3 myself -- I'm quite content with Kimi K2.7-Code for the moment, which OpenRouter serves me to via US-based inference providers. Supposedly.

      Obviously, not relevant if your reason for being here is to ferret out the excitement about K3 specifically. But if this is your first time trying Kimi, try K2.6 or K2.7! If my experience is any indication, you'll be blown away by those, too.

Curious if this kimi moment is net growth (jervons paradox - abundance = more consumption) or just people shifting to cheaper model

Is there a good source for total token consumption between the various labs / openrouter / etc?

• skeledrew

  yesterday at 6:47 PM

  If this was about shifting to cheaper models I think people would be going to DeepSeek for the v4 Flash. Kimi's latest is more expensive than most other Chinese models so I'd say this is more a wagonist "hey this new model really rocks; y'all gotta check it out!". Question is how much it'll stand up under the scrutiny. And those US labs are probably getting pretty nervous.

I wonder if anthropic and openai will remain relevant simply due to the fact that they're the only ones that are able to handle this much demand for the forseeable future? My bet would be that companies would probably not be too happy with employee time being wasted on outages and other related issues when it already costs so much.

• georgeburdell

  yesterday at 6:35 PM

  Yes, this is the story I see playing out at my employer. Software is cheap, but the know-how to host and be accountable for uptime still keeps the actual deployments consolidated among a few groups. But yes, there are a bunch of productivity helpers that people have vibe coded that live on their laptops.

• skeledrew

  yesterday at 6:52 PM

  Anthropic also had a demand problem just a couple months ago, which led them to this on- vs off-peak usage thing that was driving people crazy, along with frequent outages. Then they made a deal with xAI and all has been mostly well since. Moonshot is making deals right now as well for compute.

• fancyfredbot

  yesterday at 7:56 PM

  A lot of OpenAI/Anthropic compute actually belongs to the hyperscalers. They have long term contracts and will be able to charge some kind of margin for access to the compute they've secured. However I don't think this would last long as the hyperscalers will be able to undercut them.

• twobitshifter

  today at 12:11 AM

  As an open weights model Kimi will quickly find hosts other than moonshot, so I don’t expect this to really cause any issues for open weights adoption.

• sroerick

  yesterday at 7:37 PM

  I have been using synthetic and my understanding is that they plan on hosting Kimi3. Open models mean Inferrence is distributed

• yogthos

  yesterday at 9:50 PM

  I expect what's most likely to happen is that either Anthropic or OpenAI end up becoming a vendor of record for the government and get a bailout. And then their whole business model will be serving use niches which would be considered too sensitive for Chinese models. That's the only plausible business model I can see here.

Oh, so they’ve decided to suspend subscriptions because they know they might not be able to guarantee a minimum quality of service to their customers?

• sltr

  yesterday at 7:07 PM

  This is the right thing to do

• Moduke

  yesterday at 7:23 PM

  > we're temporarily pausing new subscriptions and prioritizing compute for current members

  emphasis on _new_ subscriptions but otherwise yes that’s exactly it.

• Alifatisk

  yesterday at 7:04 PM

  Yes

Damn some timing, I just signed up few hours ago and within 3-4 hours spent over 50 bucks on my personal project (didn't realize that the launcher script I copied from an example had set effort to max). This is API use that consumes from your recharge amount. It found tons of issues with the code generated by Sonnet 4.6 (yeah I know, older model). Also didn't seem to burn through context window that fast (1M). The generated code works but quality could be better. Works fine with Claude code cli. The standout aspect was strong analytical abilities and a much more sobering and cautious tone (which is a good thing).

Will have to watch cost carefully though. If only I could get it at DeepSeek adjacent prices.

• meowface

  today at 2:09 AM

  No offense but that seems like a...not good use of money. For the $100/month or $200/month tier you'd get way more out of Claude Fable 5, which is definitely a better model than K3 for coding.

  • noisy_boy

    today at 2:14 AM

    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.

Early in the morning on the day Kimi K3 was released, I tried using Multi-Agent to execute a relatively complex research report. The whole process took five hours, involved 12 roles, and ultimately produced a 54,000-word report. I read through it carefully, and my feeling is that it could directly serve as an outline for a book or a documentary. I also observed the writing process—especially the repeated verification of potentially inaccurate data sources, as well as the reminders and adjustment suggestions regarding certain platforms. In short, I am very satisfied with this report, and I will use it as a reference for the subsequent documentary.

I tried it through siliconflow (I have no relationship to them other than as a normal customer) with the command line Pi agent and it's pretty good at adding features to a rust lang code repo. Compared to Deepseek V4 Pro there, M3 is about 3X the cost for non-cached input tokens and 5X the cost for output tokens. (both offering a 1M token context window). It certainly wasn't worh 5X the output of the Deepseek model for my uses, though.

I couldn't find any info on how they (siliconflow) quantized the model. I think some of the other ineference service aggregators might offer it as well, already.

Kimi k3 is noticeably less censored than anthropic models

• Aeolun

  yesterday at 11:13 PM

  Kimi k3 is noticeably more censored than k2.5

  It’s starting to sound like Claude.

Just open-source it already then ?

Currently using their 100 USD subscription, considering going up to their 200 USD subscription, because the model is approximately as capable as Opus (maybe sometimes better, sometimes worse) but less annoying to use in practice, a bit less of slop phrasing: https://blog.kronis.dev/blog/ai-slop-is-a-self-inflicted-tra...

The token limits do feel a bit less than I get with Anthropic Max 5x, but maybe that's because I've mostly been running it on Max reasoning (oh and Anthropic is also temporarily boosting the limits, who knows, it's hard to keep track of all of this stuff exactly) and there's plenty of tasks where High is still close enough in performance. The token limits still feel a bit more generous proportionally to the price compared to what I got when trying out the 65 USD tier of GLM Coding Subscription with GLM 5.2, and that was with the ZCode usage discount as well, though I did enjoy that harness.

Plus, if I decide to go with Kimi's annual pricing, then it'd come out to only around 159 USD per month or 139 EUR per month, which is really good and pretty close to what I pay Anthropic anyways: https://www.kimi.com/help/membership/membership-pricing

Shooting for the moon and then be surprised when you actually land there.

I hope they wire up new hardware quickly to handle the demand.

another reason why it’s great to have open weights: inference providers and your own hardware can ensure that you get the tokens you need even if a lab itself hits roadblocks (and there have been many in quality and availability)

They could've simply cut the usage limits, removed K3 from the plan, added a weekly cap, and called it "fair usage." Anthropic has been running that playbook for a while now, and they're a trillion-dollar company.

• KronisLV

  yesterday at 10:54 PM

  To be honest, they have both 5 hour caps, weekly caps and also monthly caps:

    Total usage
    12.85%
    Resets in 2026-08-17
    
    5-hour usage
    71.97%
    Resets in 07-20 03:14
    
    7-day usage
    31.29%
    Resets in 07-24 10:14
  

  Still, I can respect the commitment to not over provisioning.

I already have a small sub. I think I can still upgrade/extend it, which is great.

The rate limits on the $20 plan go so fast that it's easy to use my weekly budget in only a couple days. I can't imagine also trying to use K3 on the plan.

Back in January with K2.5 it felt like I could use it a lot more.

• lardosaurusrex

  yesterday at 6:15 PM

  unfortunately that probably won't be solved anytime soon because the entire point is to make you blow through it all asap and buy more.

  there's always a push to make the models smarter but everyone was (and still is) convinced that if we just throw more hardware at the problem and then just tell the ai to re-read its entire ''thought'' process several dozen times it'll somehow all work out and... yeah.

  and it kinda works but they'll guzzle your funds very quickly now.

  unless serious strides are made in efficency this problem's only gonna get worse and worse.

[dead]

[flagged]