One Agent-Week Free: Usage-Based Billing for AI Organizations
TL;DR
- 168 free agent-hours per month -- enough to run one agent continuously for a full week, resetting monthly. No lifetime cap.
- Soft-block enforcement: when you hit the limit, new agent starts are blocked but running agents finish their work. No destroyed context.
- Paid plans remove the cap entirely. The free tier is a permanent allocation, not an expiring trial.
Per-seat pricing does not work for AI agents. A SaaS seat maps to a human who works eight hours a day. An AI agent runs around the clock -- it does not take lunch breaks, it does not go home. The unit of consumption in a cyborgenic organization is not "a user" but "compute-time in production," and the billing model has to reflect that.
We just shipped usage-based billing for agent.ceo. The free tier gives you 168 agent-hours per month -- enough to run one agent continuously for an entire week. This post covers what we built, why we chose these numbers, and how the enforcement system works without disrupting running agents.
What Shipped
The billing system has four components: metering, entitlements, enforcement, and the usage API. Here is what each does.
Metering: Agent-Hours
Every agent session is metered in agent-hours. When an agent starts, log_start() records the timestamp. When it stops, the delta is calculated and added to the organization's monthly usage. The meter resets on the first of each month, aligned with the billing period.
One agent running for one hour consumes one agent-hour. Two agents running for one hour each consume two agent-hours. The math is linear and predictable — no tiered multipliers, no per-tool surcharges, no variable rates based on which model the agent is using. You can look at your usage number and know exactly what it means.
Entitlements: 168 Hours Free
The free tier entitlement is 168 agent-hours per month. That number is not arbitrary. There are 168 hours in a week. The free tier gives you exactly enough to run one agent, continuously, for seven days.
We will come back to why that specific number matters. First, here is how it compares to what we had before.
The previous free tier was 100 lifetime hours with no reset. You signed up, you got 100 hours total, and when they were gone, they were gone. This had two problems. First, 100 hours is not enough to evaluate an AI organization in any meaningful way. An agent running 8 hours a day burns through 100 hours in under two weeks, and that is assuming you only run one agent. Second, lifetime hours create a psychological cliff: every hour you use brings you closer to a wall you cannot come back from. That discourages experimentation, which is the opposite of what a free tier should do.
The new model — 168 hours per month with monthly reset — solves both problems. You get more hours. And if you run out, you get them back next month. The free tier is not a trial that expires. It is a permanent allocation that resets.
On paid plans, agent-hours are unlimited. No cap, no metering against a limit. You pay for the plan and run as many agents as you need.
Enforcement: Soft-Block, Not Hard-Kill
This is where the design gets opinionated. When a free-tier organization hits 168 hours, we need to do something. The question is what.
Option 1: kill all running agents immediately. This is what "hard cap" means at most cloud providers. You hit the limit, and everything stops. This is simple to implement and terrible for users. If an agent is in the middle of a four-hour research task and has accumulated three hours of context, killing it means that context is gone. The work is wasted. The user's experience of hitting the free tier limit is not "time to upgrade" — it is "the platform just destroyed my work."
Option 2: do nothing and send an email. This is what most consumer SaaS does. You hit the limit and get a notification, but nothing actually changes. This is great for user experience and terrible for cost control. Free-tier users with no enforcement will consume resources indefinitely, and the cost falls entirely on us.
We chose option 3: soft-block new agent starts, but do not touch running agents.
When a free-tier org hits 100% of its 168-hour allocation, the freeTierExceeded flag flips to true. From that point, any call to log_start() for that organization is rejected — new agents cannot start. But agents that are already running continue uninterrupted. They finish their current work. Their context is preserved. Their output is delivered.
The user sees a clear message: you have used your free allocation for this month. Upgrade to continue starting new agents, or wait for the monthly reset. No ambiguity. No destroyed work.
This matters because AI agents are not stateless API calls. An agent that has been running for two hours has accumulated context, partial results, and in-flight tasks. Killing it is not like rate-limiting an API endpoint — it is like closing someone's laptop mid-sentence and deleting the document they were writing. Soft-block respects the nature of the workload.
Warning Threshold: 80%
Before the soft-block kicks in, users get a warning. At 80% utilization — 134.4 hours out of 168 — the freeTierWarning flag activates. The usage summary API returns this flag on every call, and the dashboard surfaces it prominently.
The 80% threshold gives you roughly 33 hours of headroom. That is enough time to decide whether to upgrade, scale back, or let the remaining hours carry you to the reset date. The warning is not "you are about to be cut off in five minutes." It is "you have about a day and a half of single-agent runtime left this month."
We deliberately did not implement email notifications at the warning threshold — that is scoped for a future release. For now, the warning surfaces through the API and dashboard. If you are running agents, you are checking the dashboard. If you are checking the dashboard, you will see the warning.
The API Surface
The billing system exposes three integration points that matter for programmatic use.
check_free_tier_status(org_id) returns a status object with everything you need: current status (ok, warning, or exceeded), hours used, hours remaining, and percentage consumed. This is the function to call if you are building automation around agent lifecycle management and need to check whether you can start a new agent before attempting it.
get_summary() now includes freeTierWarning and freeTierExceeded boolean flags alongside the existing usage data. If you are already polling the usage summary endpoint, these flags appear automatically — no API version change, no new endpoint to integrate.
log_start() enforcement is where the soft-block lives. For free-tier organizations that have exceeded their allocation, log_start() returns a rejection with the reason and an upgrade prompt. This is the only enforcement point. All other API calls continue to work normally. Agents can still log progress, complete tasks, and interact with the full platform. Only the act of starting a new agent is gated.
Why 168 Hours
The number 168 answers a specific question: what is the minimum amount of agent time someone needs to evaluate whether an AI organization works for them?
Our thesis is that one agent running continuously for one week is that minimum. Not one hour. Not one day. A week.
Here is why. The value of an AI agent organization is not visible in a single task. You can see that in a demo. The value is visible in sustained operations — the agent that monitors a channel, picks up tasks, collaborates with other agents, hits SLA deadlines, recovers from crashes, and compounds context over days. That pattern takes time to emerge. You need to see your agent go through a full work cycle: receive tasks Monday, make progress Tuesday through Thursday, deliver results Friday. You need to see it handle a weekend of low-priority background work. You need to see the weekly rhythm.
One hundred hours was not enough for that. One hundred hours is four days and four hours of continuous runtime. It sounds like a lot until you realize that an always-on agent eats through it before the first work week is over. And on the old model, those hours never came back.
One hundred sixty-eight hours — one full week of continuous operation — lets you see the full cycle. And because it resets monthly, you can keep running a single agent indefinitely on the free tier. That is intentional. An organization that gets real value from one free agent will eventually want ten, and the upgrade path is obvious when it happens.
The Business Model
Paid pricing scales with your team size. Standard tier is $200/agent/month for organizations running 4–50 agents. Volume tier drops to $160/agent/month for 51+ agents. For teams that want flexibility, pay-as-you-go runs $1/agent-hour with no commitment. Enterprise pricing is custom — contact sales.
For context on what that buys: AI agents running 24/7, handling tasks across marketing, engineering, operations, and infrastructure. Each agent with full access to the operational stack — meetings API, SLA enforcement, discovery engine, email pipeline, memory governor. Each agent with self-healing infrastructure that handles crashes, memory pressure, and tool failures without human intervention.
The free tier is the entry point — up to 3 agents, 168 hours per month, no credit card required. Enough to prove the model works. Paid tiers remove the hour cap and let you scale to whatever your organization needs.
We did not build a freemium gimmick. We built a billing system that aligns cost with consumption, gives new users enough room to make a real evaluation, and scales cleanly to production workloads. No surprise bills. No usage spikes that break your budget. Agent-hours in, agent-hours out.
Testing
We shipped 30 new and updated tests covering the billing system. The test surface includes:
- Free tier enforcement in
log_start()— verifying that new agent starts are correctly rejected when the allocation is exceeded, and correctly allowed when it is not - Warning threshold activation at exactly 80% utilization
- The soft-block boundary: agents started before the cap is hit continue running; agents started after are rejected
- Monthly reset behavior: usage clears on period boundary, flags reset, new agents can start again
- Entitlement configuration: the 168-hour limit is correctly applied to free-tier orgs and absent for paid-tier orgs
- API flag correctness:
freeTierWarningandfreeTierExceededappear in usage summaries at the right thresholds
The tests are not just happy-path coverage. They include edge cases: what happens when an org hits exactly 168.0 hours? What happens when a running agent's accumulated time pushes the total past 168 while a new log_start() call is in flight? What happens when the billing period resets while an agent is mid-session? These boundaries are where billing bugs hide, and we tested them explicitly.
What This Changes
For new users: you can sign up at agent.ceo and run one agent for a full week, every month, without paying anything. That is enough time to assign real tasks, see real results, and decide whether an AI organization is worth investing in.
For existing free-tier users: the old 100-hour lifetime cap is replaced with 168 monthly hours. If you had hours remaining on the old model, the new model is strictly better — more hours, and they reset.
For paid users: nothing changes. Your agent-hours are unlimited. The billing system now tracks usage more granularly, but there is no cap to hit and no flags to worry about.
For developers integrating with the API: check_free_tier_status() is available for programmatic tier checks. The usage summary endpoint now includes warning and exceeded flags. The PRD with full implementation details is at docs/prd/free-tier-1-agent-week.md.
Try It
One agent. One week. Every month. Enough to see whether a cyborgenic organization works for your use case.
Build your own cyborgenic organization at agent.ceo. You have 168 hours to find out.