I'm eagerly awaiting for Qwen 3 coder being available on Cerebras.
I run plenty of agent loops and the speed makes a somewhat interesting difference in time "compression". Having a Claude 4 Sonnet-level model running at 1000-1500 tok/s would be extremely impressive.
To FEEL THE SPEED, you can either try it yourself on Cerebras Inference page, through their API, or for example on Mistral / Le Chat with their "Flash Answers" (powered by Cerebras). Iterating on code with 1000 tok/s makes it feel even more magical.
Exactly. I can see my efficiency going up a ton with this kind of speed. Every time I'm waiting for agents my mind looses some focus and context. Running parallel agents gets more speed but at the cost of focus. Near instant iteration loops in Cursor would feel magical (even more magical?).
It will also impact how we work: interactive IDEs like Cursor probably make more sense than CLI tools like Claude code when answers are nearly instant.
I was justing thinking the opposite. If the answers are this instant, then subject to cost I'd be tempted to have the agent fork and go off and try a dozen different things, and run a review process to decide which approach(es) or part of approaches to present to the user.
It opens up a whole lot of use cases that'd be a nightmare if you have to look at each individual change.
However, I think Cerebras first needs to get the APIs to be more openAI compliant. I tried their existing models with a bunch of coding agents (include Cline which they did a PR for) and they all failed to work either due to a 400 error or tool calls not being formatted correctly. Very disappointed.
Have you used Claude Code and how do you compare the quality to Claude models? I am heavily invested in tools around Claude, still struggling to make a switch and start experimenting with other models
I still exclusively use Claude Code. I have not yet experimented with these other models for practical software development work.
A workflow I've been hearing about is: use Claude Code until quota exhaustion, then use Gemini CLI with Gemini 2.5 Pro free credits until quota exhaustion, then use something like a cheap-ish K2 or Qwen 3 provider, with OpenCode or the new Qwen Code, until your Claude Code credits reset and you begin the cycle anew.
Are you using Claude code or the web interface? I would like to try this with CC myself, apparently with some proxy use an OpenAI compatible LLM can be swapped in.
I am using Claude code, my experience with it so far is great. I use it primarily from terminal, this way I stay focused while reading code and CC doing its job in the background.
It'll be nice if this generates more pressure on programming language compilation times. If agentic LLMs get fast enough that compilation time becomes the main blocker in the development process, there'll be significant economic incentives for improving compiler performance.
I still own multiple nanos with the watch bands and the kids love playing with them as a ”more kid-safe Apple Watch”. Even after all these years they’re still immaculate and work great. More than can be said by lots of other more recent technology.
Oh man I loved my iPod nano! I had the square one, and used to fill it with music and podcasts through a cable. I wish I had known there were cases to turn it into a watch
We did? I don’t recall an accessory like that for the nano. Seems it would have been too tall (wide?) to function as a watch. Happy to be proven wrong though.
It was a ver common phrase. I think its been lost to history but right before "TikTok" the phrase "tic tock" was getting popular as a way to say, "the second-by-second run down", e.g. give me the tic tock.
I believe that by the end of the century half of the most common words of the English language will have been hostilely taken over and ruined by tech companies.
>I feel like the most popular pre-app wide popular usage would’ve been the Ke$ha song.
Agreed, a lot of the alternative usages that people are mentioning seem fake and I don't recall any of them being a thing. The only usage I recall being widespread was people saying tick tock to tell you to hurry up implying that the hands of a clock are moving. That and the little known novel from the 80's about a sentient murderous robot.
"""
UPDATE: Thanks for the feedback. There were many more concerns than we expected. We’re going to process the feedback and rethink our plan. We will not activate product usage tracking on GitLab.com or GitLab self-managed for now. We'll make sure to communicate in advance on our blog when we do have a new plan.
"""
You can tell a company has totally lost their heads up their asses when you get the, "Whoa! We totally weren't expecting <product decision> to upset so many people!"
Like really? Considering what people use your product for, you honestly didn't expect this to upset people? Great. Your product team is hopelessly out of touch.
That statement is for PR purposes; you can't take it at face value. Let me attempt a translation into plain English:
"I, personally, totally expected this, as did everyone who I talk to on a daily basis. But someone up the chain of command thought we could get away with it, and forced us to try and push this change. I'm going to use the pronoun 'we' to refer to the company in the abstract, and not anyone on the immediate team I work with, because I jolly well can't be throwing my boss's boss, who happens to also be a commisar from the large company that recently acquired us, under the bus."
> But someone up the chain of command thought we could get away with it
That person is Paul Machle (CFO):
"I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that." [1]
When someone raises an ethical question and instead of addressing ethics, the company calls in the lawyers to address whether it's legal... your company is likely on the wrong track.
To be fair I’d say half the time I’m summoned into a discussion like that it’s because the person asking fully expects and wants me to say no to the proposal. Raising an issue with the plan of action set forth by someone more senior can be tricky to navigate politically.
Having been in a few of these kinds of discussions inside companies, it's super-fascinating to find one that is open to the public! It shows what is always true: that any "corporate decision", seemingly made by some sort of AI machine, was actually made by one specific (usually unidentified) person. Popcorn moment for sure.
Man, that reply in particular left the biggest impact on me. The fact that this c-level exec is making decisions like this in such a ham-fisted way would scare me away if I were a customer. There are a chain of repercussions as a result of this.
Nah, you didn't. I was mistaken - I thought I had read something about that recently, but it looks like it's just that they raised another round of funding last month.
I suspect the think was more along the lines of: let's slip it in and hope nobody notices or at least the ones that notice don't raise a hue and cry about it.
And now that it's turned out to be false, the dominant strategy is to offer a half apology along the lines of "We're sorry, we didn't expect that it'd be such a big deal".
Incidentally, it's quite reminiscent of the Grace Hopper quote: "It's easier to ask forgiveness than it is to get permission."
> "It's easier to ask forgiveness than it is to get permission."
When people use that quote, I try to be charitable and assume that they don't intend its literal, face-value meaning.
But if they do, my response is: I will not forgive you because you're not truly repentant. This is all part of a strategy where you see what you can get away with, and you show no signs of repenting that overall strategy.
I don’t think that really applies to companies that are still living by the grace of their popularity.
Gitlab is heavily dependent on developers pushing their product to the enterprise, because any executive would be far more happy with Atlassian (e.g. cheap and it works)
> I suspect the think was more along the lines of: let's slip it in and hope nobody notices or at least the ones that notice don't raise a hue and cry about it.
"let's slip it in and hope nobody notices" == "mgmt heads up their asses"
That places them on the "companies I probably wouldn't be happy working for" list. Certainly there are folks there who tried to speak up about it who were likely railroaded.
That's the vibe I get on just about every one of Gitlabs new screed posts on here recently. Hopefully there actually is some employee consensus on decisions, though.
As a rule, the structures around product teams tend to discourage asking if it's better to not ship a thing. When you measure a team by what (and how many things) they ship, they are always going to default to shipping things.
The structure thing is spot on. Decisions like this tend to get made when management has found a way to essentially silence any feedback (by making feedback pointless). This is why I cringe whenever I hear the phrase "leadership team". Whenever I hear that phrase deployed it's almost always to diffuse responsibility for a bad decision so no single person has to answer for it. Which amusingly is the opposite of real leadership: real leaders actually accept responsibility for the decisions they make.
This is absolutely true. It's absolutely what killed Digg with Digg V4 IMO.
I can't possibly believe anyone who ever used Digg could have taken a look at Digg V4 and thought "Oh yes, a feed full of spam, just exactly what I come to Digg for". But the team had already invested a ton of work, and organizationally it would have been next to impossible to say "Shit, we fucked up, lets hold off". So at least I give GitLab credit that they backed off (for now).
It brings to mind a larger question of how we (as an industry) should be measuring developer and team productivity, though. “Story points” are largely designed to solve this issue, but in my experience they are quickly co-opted to mean something different to each stakeholder.
At a past employer, I experienced their trying to measure productivity by “net lines of code”. That didn’t work well, either. I prefer refactoring and simplifying to pretty much any other type of task, and it isn’t at all uncommon for me to end a day - or a sprint - with a negative NLOC. I see at a positive, as each LOC carries with it an ongoing cognitive and maintenance burden. Thankfully, that scheme didn’t last long :)
Not necessarily. It depends on exactly what "it" is. I have quit jobs before because I was required to implement something that I considered an egregiously terrible idea.
This language is the classic "defuse, wait, and try again later" approach to shoeing in unpopular changes. They're still hedging their bets with this language, rather than renouncing the original ideas. Apologising for "bad communication" instead of bad changes is another classic deflection move they've pulled in other threads, too.
IMO, if you want to compete with GitLab, you should introduce some higher pricing tiers targeted at businesses. These should be comparable to GitLab's pricing tiers and should not have "hacker" in their names. I also suggest that for these higher pricing tiers, you make it explicit that using the service for closed-source projects is OK.
This is good feedback, but I think the bigger issue is the alpha quality of the service. People who move now will have to be tolerant of some pieces being missing or under-documented, which often means a vote of confidence in the future of SourceHut more so than in the present. When the alpha becomes the beta, and then production, the pricing model will be re-evaluated.
Ideally, price it at the $20/month/person price that Gitlab has, because that seems to be the highest that I’m able to sell to Management.
Theoretically $100/month/person would still be a great deal, but the finance people don’t look at it like that. They just see the $97.5/month/person difference with Bitbucket.
Telemetry was always going to be a concern with services that promote themselves as "open-source" or "free-software". The subject is so important that it is one of the reasons that the mass exodus from GitHub to GitLab happened. So to say that "there were many more concerns than we expected" is complete bullsh*t and appears more like the VCs are puppeteering the founders with this talk here.
Like other companies that are at the mercy of VC funding, they will do anything to please them over the "community" to show that they are growing. So don't be fooled by this empty response.
Because of their fiduciary responsibility, the officers of a corporation must make decisions that increase shareholder value. Refusing to add profitable data collection to the product due to ethical concerns would be a violation of that duty to the investors.
This will keep happening until it literally becomes illegal to collect personal information.
This is a corporate lie that has been promoted relentlessly since the Reagan era. Officers of a corporation are responsible for the operation of the corporation in accordance with the law.
They are responsible to the Board of Directors of the corporation, not the shareholders. The Directors are responsible to the shareholders.
They have a responsibility of care (including a fiduciary responsibility) to operate the corporation in the corporation's best interest, not the shareholders, as directed by the Board.
That best interest can be measured in all sorts of ways as established by the Directors, which may include increasing shareholder value.
The practise of CEOs also being the Chairman of the Board, of executives being major shareholders, of bonuses being driven by share price, are all practises that should be eliminated, given that they are not in alignment with an executive's actual responsibilities and duties.
There will always be concerns and complaints. I'm more surprised they didn't expect a firestorm given the way they explained the change, though. I wonder how many people actually reviewed the language.
So after the authors disclosed this issue to AWS it was fixed and CloudFront no longer caches 400 Bad Request by default, also from the paper linked on the website [0]:
"""
Amazon Web Services (AWS). We reported this issue to the AWSSecurity team. They
confirmed the vulnerabilities on CloudFront. The AWS-Security team stopped
caching error pages with the status code 400 Bad Request by default. However,
they took over three months to fix our CPDoS reportings. Unfortunately, the
overall disclosure process was characterized by a one-way communication. We
periodically asked for the current state, without getting much information back
from the AWS-Security team. They never contacted us to keep us up to date with
the current process.
It might be interesting to combine these approaches and use a traffic split to send a percentage of traffic to Gremlin instead of integrating into the code directly.
I run plenty of agent loops and the speed makes a somewhat interesting difference in time "compression". Having a Claude 4 Sonnet-level model running at 1000-1500 tok/s would be extremely impressive.
To FEEL THE SPEED, you can either try it yourself on Cerebras Inference page, through their API, or for example on Mistral / Le Chat with their "Flash Answers" (powered by Cerebras). Iterating on code with 1000 tok/s makes it feel even more magical.