live wire
▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM
upstreambeat.ai
releaseAI

Open Data Hub’s agentic-ci adds explicit resource controls for sandboxed coding agents

Version 0.3.45 lets CI operators assign CPU, memory and GPUs to OpenShell sandboxes instead of inheriting opaque host defaults.

Sandbox with explicit CPU, memory, and GPU controls.
Side by side: what changed
By The News Desk· Sep 3, 2026the quick take — two AI hosts, this story only

Open Data Hub’s agentic-ci project has tagged version 0.3.45 with a practical control that matters when coding agents move from experiments into shared CI infrastructure: callers can now specify memory, CPU and GPU allocations for OpenShell sandboxes.

The project runs Claude Code, OpenCode and Codex harnesses in local, Podman or OpenShell environments. Its OpenShell backend adds network-policy enforcement, Landlock-based filesystem controls and endpoint restrictions around the agent process. The new release extends that boundary from access control into compute allocation.

What changed

The 0.3.45 tag points to the merge that adds memory, cpu and gpu parameters when an OpenShell sandbox is created. Operators can request values such as 8 GiB of memory, four CPUs and one GPU; leaving a value unset preserves the existing behavior and passes no corresponding flag to OpenShell.

That distinction matters because the effective default may come from the compute driver rather than the host’s visible capacity. The project’s documentation records a sandbox being killed by its memory cgroup below 4 GiB on a 16 GiB host when no memory value was supplied. It also warns that a host GPU remains invisible inside the sandbox unless one is explicitly requested.

Resource values apply when the sandbox is created. If agentic-ci setup reuses an existing sandbox, new limits are not retrofitted; operators must delete and recreate the sandbox to apply them. The backend now emits a warning when requested values cannot affect a reused environment.

Who should care

Platform teams running agentic code generation in CI now have a direct way to make resource policy part of the job definition. That should reduce two ambiguous failure modes documented by the project: a process disappearing after a cgroup out-of-memory kill, and GPU-aware work silently running without an accelerator.

The feature is especially relevant to shared runners, where an unconstrained agent can contend with neighboring jobs while an undersized sandbox can fail during dependency installation, builds or tests. Explicit limits also make repeated evaluations more comparable because the harness is not inheriting an unknown sandbox default.

What to do

Teams evaluating agentic-ci should treat version 0.3.45 as an early upstream build rather than a supported Red Hat product release. The repository publishes tags but no GitHub release notes, and the project remains on a 0.x version line.

Before adopting the new controls, operators should measure representative coding-agent jobs, set memory and CPU deliberately, request GPUs only for workloads that need them, and recreate any existing OpenShell sandbox after changing the values. They should also retain the project’s access policies: compute limits complement its network and filesystem restrictions; they do not replace them.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk