Live data from Hacker News

Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

cerebras.ai

121–130 of 135 posts

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#121

Where I’m unfortunately hitting the wall with these assistants is developing a desktop app in say Java swing - Claude cannot verify that ui it produced is actually functional

what is your AI dev stack? have you tried Kilo Code?

Is Kilo code better than Claude at launching a native or a desktop app and understanding and acting on the desktop UI.

Clicking buttons, reading values from fields, etc

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#123
post #76

I have been using Z.ai's (creators of GLM) "Coding Plan" with GLM-4.6. $3/month and 3x higher limits than Claude Pro, they say. (I have both and haven't run into any limits yet, so I'm probably not a very heavy user.) I'm quite impressed with the model. I have been using GLM-4.6 in Claude Code instead of Sonnet, and finding it fine for my use cases. (Simple scripting and web stuff.) (Note: Z.ai's GLM doesn't seem to…

actually the web search/image needs the higher tier subscription with their mcp. k gladly paid for it, i basically don't care about usage anymore. it's great at execution. i still find it not so great at planning though. i wish i can use api sonnet/codex for planning and glm on claude code for executing easily, with codex/claude code. best thing right now is kilo code with the orchestrator but haven't tried it.

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#124
post #67
post #66

Earlier quoted context omitted.

From what I recall of the original Karpathy definition, it’s only “vibe coding” if you aren’t reading the code it produces

Yes, I vote for keeping that definition and not throw it all into a box. LLM assisted coding is not vibe coding.

My point exactly, it is not vibe coding so it should not be called vibe coding. What should we call it then?

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#125

50 dollars month cerebras code plan, first with qwen-420, now with glm, is my secret weapon. Stalin used to say that in war "quantity has a quality all its own". And I think that in terms of coding agents, speed is quality all its own too. Maybe not for blind vibe coding, but if you are a developer, and is able to understand the code the agent generates and change it, the fast feedback of fast inference is a game cha…

> speed is quality

Plenty of people will agree with you. [1]

[1] https://blog.codinghorror.com/performance-is-a-feature/ (2011)

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#126
I subscribe to the $50 plan, and for the past day, my results have been laggy. Once the query actually starts, it’s as fast as normal, but time to first token wouldn’t even be the best way to describe the issue - it appears to be a problem with getting my request even into the hardware. Possibly an overloaded queue on the front end?

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#127
post #17

Was able to sign up for the Max plan & start using it via opencode. It does a way better job than Qwen3 Coder in my opinion. Still extremely fast, but in less than 1 hour I was able to use 7M input tokens, so with a single agent running I would be able easily to pass that 120M daily token limit. The speed difference between Claude Code is significant though - to the point where I'm not waiting for generation most of…

> For reference, each new request needs to send all previous messages - tool calls force new requests too. So it's essentially cumulative when you're chatting with an agent - my opencode agent's context window is only 50% used at 72k tokens, but Cerebra's tracking online shows that I've used 1M input tokens and 10k output tokens already. This is how every "chatbot" / "agentic flow" / etc works behind the scenes. That…

Many API endpoints (and local services for that matter) does caching at this point though, with much cheaper prices for input/outputs that were found in the caching. I know Anthrophic does this, and DeepSeek I think too, at the very least.

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#128

Earlier quoted context omitted.

My recent experience is that llms are dogshit at rust, though, unable to correct bugs without inserting new ones, going back and forth fixing and breaking the same thing, etc.

A while ago I gathered every HN comment going back a year that contains Rust and LLM and about half are positive and half are negative.

Sounds like the general "LLMs are net useful or not" sentiment here too. Personally Rust+LLMs work great, and workflow is rapid for as long as you can get the LLM to run one command to say "good or bad" without too much manually work, then it can iterate until it all works. Standard advice for prompting like "Don't make tests pass by changing assertions" tends to make the experience better too, but that's not Rust specific either.

Re: Cerebras Code now supports GLM 4.6 at 1000 tokens/sec

#129
post #67

Earlier quoted context omitted.

Yes, I vote for keeping that definition and not throw it all into a box. LLM assisted coding is not vibe coding.

My point exactly, it is not vibe coding so it should not be called vibe coding. What should we call it then?

LLM-assisted Development. Something that for me works in practice, vibe-coding never did, you really need to carefully review and steer constantly if things are to work out longer than just a few features.
Post reply on HN