A team that directs coding agents opens more pull requests than it did before, and each push starts a workflow. Agents push a fix, see a red check, push again, and nobody has to be at the keyboard for the next round. The pipeline reruns every time.
The CI/CD workload grows with the number of pushes, and on hosted runners that shows up on the bill. One of our customers looked at it and moved its CI work to Eyevinn Open Source Cloud (OSC). This post walks through how that setup works.
Where the cost shows up
Standard GitHub-hosted runners are free on public repositories. On private repositories, and for larger runners, usage is billed per minute after the included allowance, and the rate depends on the runner type and operating system. The details are on the GitHub Actions billing page, so check the current numbers before you run your own math.
What matters is the shape of the curve. As an illustration, a team that merges a few dozen PRs a day will not notice a rerun here and there. A team where agents iterate on every ticket will notice, because billed minutes follow the number of pushes.
Two ways out
The first is to set up the runner infrastructure yourself, for example self-hosted runners on your own Kubernetes cluster. That works, but someone has to operate the cluster, size it and debug stuck runners.
The second is to move the CI work itself onto a platform you already use. A customer of ours did that on OSC and reports a clear saving on its CI bill. Everything below is built from things any OSC customer has access to.
What running CI on OSC means
OSC does not host a GitHub runner service, so this is not a drop-in change of runs-on. The checks run on OSC instead of on GitHub-hosted runners, and the result is reported back to the PR as a status. Here is how the customer's setup works.
A small OSC My App polls the GitHub API for open pull requests and for the main branch. When it sees a new head commit, it runs the CI legs as OSC My Jobs. A My Job is a scheduled background job that runs a script from a git repository, and the setup uses one job per CI leg. A handful of legs cover lint, type checks and unit tests.
For each leg the app points the job at the PR branch and commit, triggers a run through the deploy API, polls until the run finishes and collects the result. It then posts a commit status back to GitHub under a named status context, with one of the values pending, success, failure or error. The status is not marked as required, so it shows up on the PR page without gating merges. You can promote it to a required check once you trust it.
Running this for real added some safeguards. Each job checks at start that its commit is still the head of the branch, so it never tests something that was already superseded. A cooldown keeps a burst of pushes from queueing the same work over and over. Alarms fire when GitHub could not be read and when the queue stalls, since a CI system that quietly stops looks the same as a quiet day.
Getting started from a prompt
You do not have to build this by hand. The OSC MCP server exposes tools such as create-my-app, create-my-job, run-my-job and get-my-job, plus wait-for-app-ready and get-my-app-logs for checking the app. An AI client connected to that server can create the app and the jobs from a description.
In practice that means describing the setup to an agent connected to OSC MCP: which legs your pipeline has and where the scripts live. The agent creates the pieces. It is not a one-click import of your GitHub Actions workflows, so read what it creates and expect to spend time on the commit status and the safeguards above.
What to check before you move
Not every pipeline fits. Jobs that need macOS or Windows, or that need a GPU, are different from a lint, type check and unit test run, and the second kind is the place to start. Pick the repository where agents push most often, since that is where the minutes go.
Be careful with untrusted code. A pull request from a fork should not get access to credentials or to your own capacity without isolation, whichever way you run CI.
Then measure on your own bill. Move one busy repository, keep the old workflow running in parallel for a while, and compare the two.
Try it
If agents open most of your pull requests, check your Actions usage page. If the line is climbing, sign up for OSC, connect the MCP server and ask an agent to set up CI for one repository.
Top comments (0)