GitHub Agentic Workflows cost: the default caps, and what 1M credits means in dollars

GitHub Agentic Workflows cost two things: GitHub Actions minutes for the runner, and AI Credits for the model, where one credit equals $0.01. According to GitHub's docs, each run is capped at 1,000 credits ($10) and each workflow at 5,000 credits a day ($50) unless you change them, and the K and M suffixes in the docs' own examples change that fast.

We read GitHub's general availability announcement and the cost management, billing and AI Credits specification pages on October 29, 2026. These docs change often, so check them again before you set a budget.

GitHub Agentic Workflows cost two meters, and only one is small

GitHub says an agentic workflow incurs two types of cost: Actions minutes for compute and AI inference from the model provider, and both appear independently on your bill. A typical run has a pre-activation job of 10 to 30 seconds and an agent job of 1 to 15 minutes, and each job adds roughly 1.5 minutes of runner setup.

In our view the minutes meter is cheap. GitHub's runner pricing page lists $0.006 per minute for a standard 2-core Linux runner. The cost docs estimate about 100 Actions minutes a month for a busy repository that reviews every push (100 pushes), which is $0.60 at that rate before any included minutes. That is our arithmetic, not a figure GitHub publishes.

In our reading of the docs, inference is the meter that moves. Who pays depends on the engine, and the billing page splits it like this:

• Copilot, organization billing: inference is charged as AI Credits against your organization's Copilot tenant. It needs centralized billing enabled for Copilot CLI, and the workflow must declare copilot-requests: write.
• Copilot, personal token: if those conditions are not met, you supply a COPILOT_GITHUB_TOKEN and inference is limited by that token owner's Copilot entitlements.
• Claude, Codex or Gemini: inference is billed directly to your Anthropic, OpenAI or Google account.

GitHub's announcement adds one gate: the feature is generally available on github.com for Free, Team and Enterprise, but "using the default GitHub Copilot CLI engine to power a workflow requires a Copilot license." The quickstart also says a Claude subscription token is not supported; it wants an API key or Anthropic workload identity federation.

The built-in caps: 1,000 credits per run, 5,000 per day

The cost docs list guardrails that exist before you configure anything. We converted each credit figure to dollars using the documented rate of $0.01 per credit.

The defaults come from the cost management page and the specification, which fixes 1,000 and 5,000 as the built-in values and lets an organization variable override them. The daily figure sums every run of the same workflow in the past 24 hours across the repository, whoever triggered it.

Do the multiplication before you treat the defaults as a budget. A single workflow that reaches its daily cap every day could spend $50 a day, or $1,500 over 30 days. In our view, the cap is a ceiling, not a forecast.

There is also a separate turn cap. The max-turns key limits how many chat iterations a run may take, and the docs say it works across Claude, Codex, Copilot, Gemini and Pi.

What 1M credits means in dollars: the suffix trap

The cap keys accept plain integers or K and M suffixes, and the specification says the suffix is expanded literally: "1M → 1000000" for the per-run key and "100M → 100000000" for the daily one. At $0.01 per credit, 1M credits is $10,000.

Now read the docs' own examples with that in mind. The shared-defaults example sets default_max_ai_credits to "5M" and default_max_daily_ai_credits to "15M", and a daily example shows max-daily-ai-credits: 15M. By the documented conversion that is $50,000 per run and $150,000 per day, against built-in defaults of $10 and $50.

We don't know whether those examples are meant as recommendations, and the docs do not say. In our view, anyone who copies them into a real organization has removed the cap in practice while believing they set one. Write the number you mean in plain credits, and divide by 100 to check the dollars.

To disable a guardrail on purpose, the docs use -1. In our view, an explicit -1 that a reviewer can search for in a pull request is a better way to get there than a stray suffix.

How to see what a run cost: logs, audit and forecast

Start with the command line. The docs name three commands, and the AI Credits column they show is the number to watch.

1. Run gh aw logs to list recent runs with duration, token usage, AIC and turn count. Add --start-date -30d and --json to script it.
2. Run gh aw audit with a run ID to see one run's token counts, tool calls and inference spend.
3. Run gh aw forecast to project monthly credit use from recent history. GitHub's announcement says forecast is no longer experimental and now covers threat-detection credits and monthly ranges.

Two cautions from the pages themselves. First, the docs say AIC values are computed "on a best-effort basis" from the models.dev catalog and "may not exactly match your provider's actual billing," so reconcile against the provider's dashboard. Second, the CLI reference says forecast numbers are estimates "derived from historical samples and may be inaccurate", and it only accepts 7 or 30 days of history.

One practical snag: the billing page and the cost page show different jq paths for the same logs command (per_run_breakdown on one, runs on the other). Run the command without jq first and see which field your installed version prints.

Four changes that cut the bill before you touch a cap

The cost page says the main lever is how often a workflow runs. It rates push, check_run and check_suite triggers as high risk and warns that attaching an agent to them in an active repository "can generate hundreds of runs per day." Issue and pull request triggers rank medium-high, and schedule and workflow_dispatch rank low and predictable.

• Start on a schedule: begin with schedule or workflow_dispatch while you measure, then move to event triggers once you know what a run costs.
• Skip the agent when there is nothing to do: the skip-if-match and skip-if-no-match keys run in the cheap pre-activation job, so a skipped run never starts the agent.
• Use a smaller model for routine work: the docs suggest lighter models for triage and labeling and frontier models only for hard tasks.
• Batch instead of reacting: a nightly run that handles all of the day's new issues in one pass sends the shared instructions once, which the docs say lets providers cache that context.

If you are comparing the engines you can plug in, the AI coding tools category on Upfynd lists 246 products as of October 29, 2026, and developer tooling lists 952. For a different kind of automation without an agent in the loop, see automation and no-code, which has 546.

What the caps do not cover

The guardrails have documented edges, and a few matter for a budget.

• Dispatch runs skip the daily check. The docs note the daily guardrail is skipped for workflow_call, repository_dispatch and workflow_dispatch runs. That note is about the daily cap only; the pages we read do not say whether the per-run cap behaves differently for them.
• The admission service is not a hard stop. For shared budgets across an organization, the docs describe an optional admission authority you must deploy yourself, and say it is "cooperative, not a hard spending cap."
• The numbers are guardrail accounting. The docs state the totals "are not provider billing."
• A cap can look like an auth error. The billing page says Copilot CLI can print "Authentication failed with provider ... (HTTP 403)" when the proxy enforces max-ai-credits, so a 403 does not always mean a bad token.

Separately, GitHub's Copilot CLI session limit is documented as a "soft limit" that lets the response in progress finish, so spend can slightly exceed it. That is a different feature from the gh-aw per-run budget, which the cost page calls a hard stop. We found no statement in the gh-aw pages about whether a response in flight can overshoot it, so leave some headroom.

A sensible first setup

Our suggestion, not GitHub's: for your first workflow, set max-ai-credits well below 1,000, set max-turns, use a schedule trigger, and run gh aw logs after a week. The quickstart example is a daily repository status report that takes about 10 minutes to add. Then read the credits column, set the cap to roughly double your worst observed run, and only then consider event triggers.

Upfynd also lists GitHub's official blog under developer tooling. For how GitHub and other vendors moved to credits this month, our earlier piece on credit-based pricing at GitHub, Notion and Warp covers the pattern.