Skip to main content
Handing an agent a proxies:write key means handing it the ability to spend money. That is the point - it is also the risk. This page is about keeping both.

​
The one thing that actually protects you

Not prompt wording. A limit on every proxy. setProxyLimits puts a hard ceiling on a proxy. When traffic crosses it, the proxy is suspended in the background and stops passing traffic. A runaway loop hits the cap instead of your balance.
Create the proxy and cap it at 20 GB a month.
Said in the same sentence as the creation request, the cap is applied immediately rather than after the first surprise. Both accept daily or monthly. Daily caps are the better choice for anything an agent drives unattended - the blast radius of a bad loop is one day, not one month.
A limit is not checked when you set it. It takes effect when usage crosses the line, which means a single very fast run can overshoot slightly before the suspension lands. Set the cap below the number that would actually hurt.

​
Scope the key to the job

An agent that only reads cannot spend anything. Match the key to the work: Keep a separate read-only key for reporting agents and dashboards. Revoking it later costs nothing.
proxies:write also permits deletion. deleteProxyResource is marked destructive and carries a confirm parameter, but that protection lives in your client, not on our side. If deletion would be unacceptable, do not issue a write key.

​
A naming convention that pays off

Proxy names are immutable, so the name the agent picks is the name you live with. Ask for a pattern:
Name proxies <project>_<source> - for example q3_enrichment_registry.
Six weeks later, listProxyResources reads as an inventory instead of a puzzle. Names take lowercase letters, digits and underscores only - no hyphens, because hyphens separate parameters in the connection username. The description is free text and can be changed, so put the context there: what the proxy is for, which run, who asked for it.

​
Reviewing what it spent

Ask, or use the /monthly-cost-report prompt:
Show traffic and spend for last month and flag anything unusual.
The runway line is the useful part: not what you spent, but how long the balance lasts at the current rate.

​
Retiring what you stopped using

Idle proxies do not cost anything directly, but they hide the ones that do. Clean up on a schedule:
Find proxies with no traffic in the last 30 days and deactivate them.
Or run /cleanup-unused-proxies, which does the same and is hard-wired never to delete.
Deactivate, do not delete. Deactivation stops traffic and is reversible - set the status back to active and the proxy resumes with the same name, same credentials, same history. Deletion is permanent, and the name cannot be reused the same way.

​
A workable default

1

Two keys

A read-only key for reporting agents, a write key only for the agent that provisions.
2

A cap on every proxy at creation

Daily for anything unattended, monthly for scheduled jobs you understand well.
3

Names that carry the project

<project>_<source>, agreed once and repeated in every request.
4

One proxy per project, not one shared

Per-project resources make the cost report readable, and let you stop one job without touching the others.
5

A monthly review and cleanup

One report, one cleanup pass, and idle resources stop accumulating.

​
Next steps

FAQ

What each error code means, and what an agent can and cannot do.

Billing & Usage

How pricing and the account balance work.