Hacker Newsnew | past | comments | ask | show | jobs | submit | zackify's commentslogin

Our CI has thousands of tests and is done in 2 minutes. Everytime it grows above 3 I add more parallelization and keep it ultra fast. Been working great for our team

How are you speeding up the provisioning? Most of my tests run pretty quick, but spinning up a new runner takes probably most of the time. I haven’t tried optimizing this yet.

I have lxd containers already running that have everything the system needs.

When starting CI it's doing a DB SQL dump replacement which takes 1-2s to prep, self hosted github actions.

Its been very cheap to run OVH cloud with the newest and fastest AMD EPYC CPUs that have high single core speeds. Did this as it was cheaper than GCP spot to have these always on.

I'll run many always on lxd containers that all match with the same stacks. Add another one when needing to parallelize more


I have a couple hundred line TUI that just clones an LXD container and I get all my repos and infra isolated in 5s with pi having isolation to that container. Swap between any instance. Port forward to host all automatic.

Funny to me how stuff is described these days. Seems like some people lack the full understanding of all these different systems and really overcomplicate their harness setups or use super bloated all in one tooling.


I tried putting my agent in an LXC / Incus container but then I also needed it to process videos stored on a NAS, and that was not easy at all. I tried a FUSE-based NFS client [1] but it was very flaky and would randomly report files having zero length and fail processing.

[1] https://github.com/facebookarchive/nfusr


Do you have any links that would explain this?

I'm looking at changing my AI harness and am definitely interested in this


love this idea!

I just have a slack bot running on a VM that sees a message and invokes pi.

It would be trivial for every request to clone a full lxd container and have all the tools and repos required if I wanted to allow it to do even more.

Not sure why anyone prefers to choose locked in options


How did you set all that up? We built a flow where you push a slack.yaml to github to arrange this

> Not sure why anyone prefers to choose locked in options

Convenience. And OPEX vs CAPEX something something.


Yeah what, I'm using flash models and getting a ton of stuff done. 300-400b param size with pi.dev


I have been using glm 5.3 flash and it feels as good as opus 5. Put a lot of work into it this week (100m tokens). Now I'm curious to try this one. These smaller models are getting very good imo


Neither flash or regular glm 5.3 are close in my experience. I still prefer Sol though.


What type of setup do you use? I have very small 4-5k initial context and do one task then clear. I rarely go above 150k context for most things.


It DOES still hurt.

For example the eBay app. Does not allow installing from the play store on grapheneos.


No memory. No web search 99% of the time.

Two agent.MD files that are very small. One on each project. One at parent project level.

Did 30M tokens through glm 5.3 flash today for 52c

Using pi and a few extensions my initial context is always 4k max


I ran 30M tokens through for 50c... insanity that this is possible.

and it really is opus 4.8 level.


Any plans to offer a way to generate audio books on demand. like if i set kokoro, a book auto imports, it can make the file for me for the whole book after some time of local gpu work?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: