I thought I wouldn’t because it’s just another git - but git worktrees are a PITA.
Can I suggest though to focus the readme on the lighting fast checkout for multi agent loads? That seems to be the big selling point and is the real win over git.
I think other commenters here are missing the point - it’s not “for agents” in that the API is somehow agent friendly. Of course git being omnipresent in the training data gives it a one-up. It’s “for agents” in that it aligns with a multi-checkout workflow better than git does.
Agreed on integrals, but the derivative is relatively simple?
If f(x) = exp(x) - ln(x) then f’(x) = exp(x) - 1/x, which is representable in eml form as well.
To the overall point though, I don’t think it helps make derivatives easier though. To refactor a function to eml’s is far more work than refactoring into something that’s trivially differentiable with the product rule and chain rule.
Yes - and this also gives me hope that the (very valid) issues raised by this paper can be mitigated by using models without KPIs to watch over the models that do.
> This attack stems from the combination of two design flaws: overprivileged database access (service_role) and blind trust in user-submitted content.
No, there is only one design flaw, the overprivileged database access. An LLM shouldn't be given more access than the user who is interacting with the LLM has.
I thought I wouldn’t because it’s just another git - but git worktrees are a PITA.
Can I suggest though to focus the readme on the lighting fast checkout for multi agent loads? That seems to be the big selling point and is the real win over git.
I think other commenters here are missing the point - it’s not “for agents” in that the API is somehow agent friendly. Of course git being omnipresent in the training data gives it a one-up. It’s “for agents” in that it aligns with a multi-checkout workflow better than git does.