惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
有赞技术团队
有赞技术团队
博客园_首页
IT之家
IT之家
爱范儿
爱范儿
量子位
小众软件
小众软件
Jina AI
Jina AI
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 聂微东
The Cloudflare Blog
博客园 - 司徒正美
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
大猫的无限游戏
大猫的无限游戏
月光博客
月光博客
雷峰网
雷峰网
V
Visual Studio Blog
博客园 - Franky
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
美团技术团队
Last Week in AI
Last Week in AI
S
SegmentFault 最新的问题

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
AI Coding Agents Need Runtime Telemetry Before Commit Tel...
Assili Salim · 2026-06-26 · via DEV Community

A new arXiv paper published on June 23, 2026 scanned more than 180 million Git repositories to detect traces of AI coding agents in open source. The authors used multiple signals, including configuration-file scanning, commit-message analysis, author-identity matching, and bot-signature lookup.

The most useful result for developers is the visibility gap.

In one snapshot, multi-method detection found 850,157 Claude Code commits.

Bot-account lookup found only 28,154.

That is 3.3%, or a 30x relative recall gap.

The paper also reports more than 320,000 commit-attributed agent commits per month across snapshots from December 2024 to April 2026.

The immediate takeaway:

AI coding agents are being used heavily.

The engineering takeaway:

Single-signal observability is weak.

Commit telemetry is too late

A commit is the end of an agent run.

It does not tell you enough about the run itself.

A commit may not show:

how many model calls happened
how many retries happened
whether prompts repeated
whether tools failed
whether the model price was known
whether the run exceeded budget
whether the agent made progress
whether fallback models were used
whether the agent stopped safely

If you only inspect the repository after the fact, you are observing the artifact.

You are not observing the execution.

For agent systems, execution is where many failures happen.

Agents are loops

A coding agent is usually some version of this:

while (!task.done) {
const response = await model.call(task.context);

const action = parseAction(response);

const result = await runTool(action);

task = updateTask(task, result);
}

This is useful.

It is also incomplete.

There is no budget.

No max-step limit.

No retry control.

No prompt-loop detection.

No known-pricing check.

No no-progress stop.

A safer runtime shape puts a decision before the provider call.

const decision = guard.beforeCall({
runId: task.id,
model: task.model,
prompt: task.currentPrompt,
stepCount: task.steps.length,
retryCount: task.retryCount,
previousPrompts: task.previousPrompts,
budgetRemaining: task.budgetRemaining,
progressState: task.progress,
});

if (!decision.allowed) {
return {
status: "stopped",
reason: decision.reason,
error: decision.error,
};
}

const response = await model.call(task.context);

The important part is not the exact API.

The important part is timing.

The check happens before the provider call.

That means the runtime can stop unsafe execution before more cost is created.

What to log before the call

A useful agent runtime should log decision inputs, not only final outputs.

For each provider call, consider recording:

type AgentCallDecision = {
runId: string;
model: string;
modelPriceKnown: boolean;
stepCount: number;
maxSteps: number;
retryCount: number;
budgetRemaining: number;
estimatedNextCallCost: number;
promptSimilarityScore?: number;
progressScore?: number;
allowed: boolean;
stopReason?: string;
};

This gives you data that a commit cannot provide.

You can now ask:

Which tasks hit max steps?

Which runs stopped because pricing was unknown?

Which prompts repeated?

Which models caused budget pressure?

Which agent workflows produced commits only after many failed attempts?

Which agents consumed budget without progress?

That is runtime telemetry.

Guardrails to implement first

  1. Max-step limits

Agents should not run forever.

if (stepCount >= maxSteps) {
return {
allowed: false,
reason: "max_steps_exceeded",
};
}

This is basic.

It is also one of the highest-value controls.

  1. Unknown pricing blocks

If the runtime cannot price the model, it cannot enforce a budget.

if (!pricingCatalog[model]) {
return {
allowed: false,
reason: "unknown_model_pricing",
};
}

Do not guess.

Fail closed.

  1. Budget guards

Budgets should exist at the task level, not only at the account level.

if (estimatedNextCallCost > budgetRemaining) {
return {
allowed: false,
reason: "budget_exceeded",
};
}

A small refactor and a multi-hour migration should not share the same ceiling.

  1. Retry-storm detection

Retries are normal.

Retry storms are not.

if (retryCount > maxRetries && recentErrorsAreSimilar(errors)) {
return {
allowed: false,
reason: "retry_storm_detected",
};
}

The goal is not to ban retries.

The goal is to stop blind repetition.

  1. Prompt-loop detection

If the current prompt is almost the same as previous failed prompts, the agent may be stuck.

if (similarToRecentPrompt(currentPrompt, previousPrompts)) {
return {
allowed: false,
reason: "similar_prompt_loop",
};
}

Even a simple similarity check can catch obvious waste.

  1. No-progress detection

A run can be active and still not moving.

Track progress signals:

tests passing
errors decreasing
files changing meaningfully
checklist items completing
user-defined success criteria improving

If those signals do not change after several steps, stop.

Why this matters now

GitHub has already said Copilot moved to usage-based billing on June 1, 2026, with usage calculated from token consumption including input, output, and cached tokens. GitHub also described Copilot as moving from an in-editor assistant into an agentic platform capable of long, multi-step coding sessions across repositories.

That means agent runtime behavior increasingly has direct cost impact.

A loop is no longer just a UX problem.

It is a billing problem.

A retry storm is not just noisy.

It is spend.

A prompt loop is not just inefficient.

It is measurable waste.

Where AI CostGuard fits

AI CostGuard is the local-first TypeScript / Node.js runtime safety layer I’m building for this problem.

It focuses on stopping agent failures before provider calls execute:

retry storms
prompt loops
max-step explosions
no-progress runs
budget overruns
unknown model pricing
runaway agent behavior

The key design question is simple:

Should this next provider call be allowed?

If the answer is no, the runtime should return a structured stop reason before the call happens.

Takeaway

The new arXiv paper shows that even detecting AI coding-agent activity in repositories requires multiple signals.

That lesson applies directly to runtime engineering.

Do not wait for the commit.

Do not wait for the dashboard.

Do not wait for the invoice.

Instrument the loop.
Add one pre-call decision log to your agent runtime before adding another dashboard.
https://github.com/salimassili62-afk/ai-costguard