Paulo Victor Leite Lima Gomes

Posted on Jul 25

agent credit limits are the new timeout

#ai #agents #githubcopilot #platformengineering

GitHub added AI credit session limits to Copilot CLI and the Copilot SDK this month, and the feature is much more interesting than the billing language makes it sound.

The obvious reading is simple: agents cost money, so vendors are giving users a knob to stop the meter.

Fine. That is true.

But the better reading is this: agent credit limits are becoming the new timeout.

In old automation, a runaway job burned CPU, memory, disk, locks, queue capacity, and maybe someone's Sunday morning. In agent automation, a runaway session burns tokens, API calls, tool executions, CI minutes, review attention, cloud sandboxes, branch names, and the patience of the person who has to explain why the agent opened a pull request after wandering through half the repository.

That is not only a cost problem.

It is a control problem.

timeouts were never only about time

Timeouts look like small configuration values until you operate a real system.

They decide how long a service waits before admitting a dependency is unhealthy. They stop background jobs from becoming immortal. They protect worker pools. They make failure visible. They force engineers to decide what "too long" means for a particular workflow.

Good timeouts are not arbitrary. They encode a belief about the work.

How long should this request take? How much delay can the caller tolerate? What happens if the dependency is slow but not dead? Should we retry? Should we fail fast? Should we degrade? Should a human be paged?

The number is the least interesting part. The interesting part is the ownership conversation behind it.

Agent credit limits have the same shape.

GitHub's changelog says Copilot can now cap AI credit use across a session, including model calls, subagents, and background work like compaction. In noninteractive runs, a command-line flag can bound a single run. When the limit is reached, the agent wraps up instead of continuing until the task is done or manually stopped.

That is a product feature.

It is also a design constraint.

unattended work needs a budget boundary

The scary word in the GitHub changelog is not "credits."

It is "automation."

GitHub explicitly frames the feature as useful when nobody is actively monitoring the agent's work. That is the moment the mental model changes. A chat assistant with a human staring at it can be sloppy in ways a scheduled agent cannot. The human can interrupt, redirect, or decide that the assistant is now confidently renovating the wrong building.

An unattended agent needs a harder boundary.

Not because agents are evil. Because unattended work is where small mistakes compound.

A coding agent with no spend cap can keep searching, keep summarizing, keep spawning helper work, keep compacting context, keep trying another test, keep reading another file, keep explaining itself into another model call. Each step may look reasonable in isolation. The total path can still be waste.

This is familiar from distributed systems. Most outages are not caused by one dramatic villain request. They are caused by ordinary retries, queues, fallbacks, and defaults interacting badly under pressure.

Agents are bringing that same pattern to knowledge work.

the credit limit is a product opinion

A credit limit is not neutral.

Set it too low and the agent stops before it has enough context to do useful work. Set it too high and the agent can turn a small task into an expensive archaeology expedition. Make it global and simple teams will understand it, but complex workflows will hit weird ceilings. Make it too flexible and every repository invents its own little budget policy nobody remembers.

That means platform teams will eventually need agent budget standards.

Not just "monthly AI spend."

Something closer to:

a maximum credit budget for a dependency bump
a different budget for security autofix
a higher budget for migration research, but with mandatory human review before code changes
a separate budget for subagents
a hard stop when CI failures repeat without new evidence
a rule that expensive model use must leave a trace explaining why it was needed

That sounds bureaucratic only if you still think agents are toys.

If agents are workers, budgets are part of the work contract.

review cost is still cost

The related GitHub Copilot code review post makes this even clearer.

GitHub described an internal change where moving Copilot code review to shared Unix-style exploration tools initially made the review agent worse: cost went up and fewer useful issues were caught. The fix was not a magical new model. It was reshaping the workflow around how reviewers actually inspect pull requests.

That is the lesson.

Agent cost is not only price per token. It is workflow shape.

A review agent that browses a repository broadly can consume more context, more money, and more human trust without producing better review. A better review agent starts from the diff, asks narrow questions, collects evidence, and stops when it has enough.

That is exactly how good human reviewers work too.

The difference is that humans usually feel the fatigue. Agents need the fatigue translated into policy.

Credit limits are one translation.

this belongs next to logs, not pricing

I do not want agent credit limits hidden only in billing screens.

They belong next to logs, traces, tool calls, task templates, and repository policy.

When an agent stops because it hit a credit limit, the useful question is not only "how much did it cost?"

The useful questions are:

what was the task trying to do?
what evidence did it gather?
which tool calls consumed the budget?
did it broaden the search too early?
did subagents help or just multiply activity?
did it stop with a useful partial result?
should this task type get a higher limit, or was the task badly framed?

That is observability work.

If the only output is "limit reached," the feature is a meter. If the output explains the path, the feature becomes operational feedback.

This is where mature agent platforms will separate themselves. The winning products will not only let companies spend less. They will help teams understand why a task spent what it spent.

credits are the new blast radius

Cloud made teams learn that money is an architecture signal. A bad autoscaling rule, chatty service, forgotten log stream, or oversized database can turn into a real bill. That did not make cloud bad. It made cost part of engineering.

AI agents are doing the same thing, but at a more intimate layer.

The spending unit is attached to reasoning, tool use, and generated work. A sloppy instruction is not just a confusing prompt. It can be a recurring cost pattern. A vague automation is not just low quality. It can become a standing budget leak. A missing stop condition is not just untidy. It is a production risk in miniature.

This is why I like the timeout analogy.

Nobody serious says, "timeouts prove distributed systems are too dangerous to use."

We say, "of course the system needs timeouts."

We should say the same about agents.

Of course the session needs a limit.

Of course the limit should depend on the job.

Of course the stop should leave evidence.

Of course teams should review the tasks that keep hitting the ceiling.

the punchline

Agent credit limits look like billing controls because billing is where the pain first becomes visible.

But they are really early control-plane features.

They force a team to say how much autonomous reasoning a task deserves before it should stop, summarize, and ask for a different decision. That is healthy. It turns agent work from "keep going until the model feels done" into "operate inside a boundary we chose."

The future of agentic software engineering will have all the boring controls we already learned to respect: timeouts, quotas, budgets, retries, logs, traces, ownership, and escalation paths.

Wonderful.

That means the category is growing up.