It has never been easier to setup Proxmox, Kubernetes, and Actions Runner Controller (ARC) to do your own CI on old hardware you might otherwise recycle.

We ran actions runners ourselves in kubernetes at previous jobs, and at least back then, a lot of the errors came from the github services simply not telling the runners to handle jobs. So in general it didn't matter how much compute you had, they never got scheduled jobs.

ARC protects you from most common kind of Actions incident as seen over last month: GitHub's runner pool running short. Nothing CI-based can protect from an outage in the Actions service itself.

It should be possible to wire another event dispatcher to ARC instead of relying on actions webhooks. That’s the only part that is a true dependency, it should be possible to basically decouple ARC

Ideally yes. As a backup path I've considered Forgejo with a pull mirror and forgejo-runner on Kubernetes but haven't pursued it.

This is good advice for organizations but if you are an individual GitHub user there is no way to have a pool of a few runners available for all of your repositories.

I don't know why but individual users have to create a single instance runner and mate it with exactly one of their repositories.

Converting from an individual user to a GitHub organization is not simple. The docs certainly make it look that way but I have yet to run into anybody that has done so without some form of catastrophic error that requires support to fix

You do not convert an individual user account to a GitHub organization. You create an organization from your personal account then transfer repos to it.

Yep. Proxmox, Kubernetes, ARC, and t3 code threads spawned inside of kata containers is my current workflow.

They purport 40% drop in costs due to lower token pricing (presumably aimed at winning back the many of us that switched providers in discovering Opus 5 unusable) and improved token efficiency.

That cost reduction seems to stem from cheaper cache reads, mostly.

Significant regression in token efficiency compared to Grok 4.6 suggested by artificialanalysis.ai Intelligence Index Comparisons.

Output tokens from Intelligence Index:

- grok 4.6 (xhigh): 97M (for 44 score)

- grok 4.7 (xhigh): 240M (for 46 score)

No, you can add Grox 4.7 high to the chart. 36k vs 66k

Astra will initiate test suites, find one more thing independently while its running, reinitiate complete test suite after fixing it, then find one more thing, then test again. Easy to burn through GH actions minutes if you're not careful orchestrating.

I wonder too if in training for long horizon tasks agents become worse team players, good at orchestrating subagents they are trained to use, but worse as an agent within an external multi-agent orchestration system or just in turn-taking with humans. That was my experience with Opus 5 and so far it has been my early experience with Astra as well.

In SWE I've found gpt-6-astra (high) inconsistent and oddly focused on overtly taking responsibility for mistakes it made rather than prioritizing concrete steps to rectify problems. Such steps once elicited are often either incomplete or beyond the scope.

Opus also does this and then writes comments in code or PR descriptions describing how it went wrong earlier in the session.

Just imagine how confused a human would have to be to do that. And we want to trust these clankers to build software.

The biggest issue with LLMs is that they still suck at general contextual awareness and ability to judge what is appropriate.

Yes I agree. I got it to vibe up a simple react router app. When it crashed it was obvious that it had totally swallowed all errors in the name of a tidy error page. Getting it to re-add logs and debuggable errors was an exercise in patience as astra just got more and more tweaked while trying to solve the problem.

From an alignment perspective I’ve got no idea who it’s aligned to but it isn’t me, the meat proxy, who just wants to know why it crashed.

I also temporarily had agy as a harness in my orchestrated workflow until I learned about the account bans. IANAL but frontier models examining Google's TOS suggested my use could be in violation. Haven't touched agy for anything since.

I've tested Omnigent superficially, attracted to its thinking around policy, governance, sandboxing, and ui. But it's still alpha at present. I forked its Polly model and got working a somewhat more complex multiagent workflow that I've also modeled in Sandcastle and Gas City but the agent broke after the next update which I would have needed to patch to maintain functionality. Subjectively I also noticed individual models seemed to be performing somewhat worse when wrapped in the platform's framework, presumably due to the extra context introduced (token use was measurably higher). Promising project that I'll revisit when it's further along and I do not doubt the outcomes Databricks claims in committedly dogfooding it.

Double-harnessing distortions seems like a weak point. I wonder if it’s just a temporary measure and long term it’s about writing custom harness going straight to inference APIs across all models.