That’s like (at least) third GPU-related project named Triton

I was expecting DirectX in triton-lang https://github.com/triton-lang/triton

Nobody named theirs Deuteron? (Sorry could not resist)

I seriously considered this name for a triton related project. Well there’s helion (metas autotuning dsl) at least.

Or Trident, which was (and maybe still is?) Joyent's flagship product in the private cloud space.

On the other hand, it is not uncommon for the exiled old guard to form new companies, teams, products and realize their vision under new management.

It is not like their knowledge and experience gets literally purged.

Specific change to ToS: https://codeberg.org/Codeberg/org/commit/96fac426a32d1ba91ff...

> 7. You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).

The rationale in the ToS change and the rationale in the blog post don't match up.

The ToS change grammar could do with tightening up as well.

True, and even selling token price may not be illustrative of what it actually costs them to provide the service. Tokens may be sold at a loss if majority of spenders are running agents 24/7

The industry and users moves on from single chat-based to more and more "agentic" workflows that may generate longer workloads with multiple simultaneous agents (separate agents - separate contexts - separate KV caches).

My estimation is based on, say, running a Kimi3 on a 24 B200 GPUs - it is very easy to lose money when selling tokens at "market" prices.

One thing that I tried was porting an old and obscure 32-bit VST plugin from PowerPC to modern architectures

Any recommendations for non-typescript-based coding TUI harnesses/agents other than Codex? Given that Codex is open source someone should've built an untethered client?

2 of the most promising Rust ones

https://github.com/1jehuang/jcode https://github.com/gi-dellav/zerostack

Please consider adding `cargo watch` - that would be a killer feature!

Yes! This is definitely on the list of features to add. Thank you for the feedback!

/*

* Check if 1M context is disabled via environment variable.

* Used by C4E admins to disable 1M context for HIPAA compliance.

*/ export function is1mContextDisabled(): boolean {

  return 

isEnvTruthy(process.env.CLAUDE_CODE_DISABLE_1M_CONTEXT)

}

Interesting, how is that relevant to HIPAA compliance?

I'd guess some constraint on their end related to the Zero Data Retention (ZDR) mode? Maybe the 1M context has to spill something onto disk and therefore isn't compliant with HIPAA.

Super-relatable.

Now that I think about it, most of my advice starts something like "Here's what you're gonna do..."

Wait, that itself sounds like a problem, but how do I fix it...

Probably LLVM runs different sets of optimization passes for C and C++. Need to look at the IR, or assembly to know exactly what happens.

It doesn’t as far as I know.

(I have spent a good amount of time hacking the llvm pass pipeline for my personal project so if there was a significant difference I probably would have seen it by now)

You are correct, that was an uneducated guess on my part.

I just glanced at the IR which was different for some attributes (nounwind vs mustprogress norecurse), but the resulting assembly is 100% identical for every optimization level.