Gemini API Managed Agents Just Got Free Tier, Budget Controls, and Cron Triggers – Here’s What That Means for You

If you’ve been following the Gemini API’s managed agents (the ones that run in an isolated sandbox with code execution, file management, and network access), you probably had two reactions: “this is incredibly useful” and “how do I keep costs under control?”

Google just addressed both. The latest updates – free tier availability, budget guardrails, and scheduled triggers – turn managed agents from a powerful but slightly risky tool into something you can actually deploy without holding your breath.

I’ve been testing the Antigravity agent since its preview, and the biggest obstacle was always the uncertainty around token consumption. You give it a task like “clone a repo, audit deprecated classes, generate a migration report,” and it does exactly that – but the number of turns and tool calls can vary wildly. Now, with these three additions, the calculus changes.

Let’s walk through each one, how to use them, and where they actually matter.

Free Tier: You No Longer Need a Billing Account to Try Managed Agents

The most immediate change is that managed agents are now available to free tier projects.

Previously, any call to the Antigravity agent required a project with active billing. Even if you just wanted to run a small demo – say, a few thousand tokens – you had to attach a credit card. That’s not a huge financial barrier, but it is a friction point, especially for individual developers or early-stage teams who want to validate the tool before committing.

Now, if your API key is linked to a project without billing enabled, your interactions will not be charged. They run under the free tier’s rate limits and usage quotas – same API, same endpoints, just no cost.

This matters because managed agents aren’t like regular API calls. You can’t fully assess whether they’ll handle your specific workflow just by reading the docs. You need to run them against real tasks – cloning repos, parsing logs, generating reports. Free tier removes the “should I bother?” hesitation.

A practical note: the free tier has rate limits (RPM and TPM). The exact numbers aren’t in the announcement, but based on other Gemini free tiers, they’re reasonable for experimentation but not for production-scale frequency. Check the official pricing page before scheduling 100 triggers a minute.

Budget Controls: The Financial Circuit Breaker Your Agents Need

This is, in my view, the most critical addition.

An Antigravity agent runs in an autonomous loop: it plans, executes code, calls tools, observes results, and decides what to do next. That loop can take 5 turns or 50 – you don’t know in advance. Every turn consumes tokens: input, output, and reasoning tokens all count.

The problem is that a seemingly simple task can balloon. For instance, if you ask the agent to “audit all modules in a Java project for deprecated APIs,” it might:

• Clone the repository
• Resolve dependencies (which may involve network calls)
• Traverse directories
• Read source files one by one
• Generate analysis
• Write a report

If any step fails – network timeout, missing file, permission issue – the agent may retry, adding more tokens. Without a limit, you’re flying blind.

How to set a token cap

Pass max_total_tokens inside agent_config. This controls the combined total of input, output, and thinking tokens for the entire interaction.

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

const interaction = await client.interactions.create({
  agent: "antigravity-preview-05-2026",
  input: "Clone https://github.com/google/guava, audit all modules in guava/src for deprecated classes and internal utilities, and generate a comprehensive migration audit report with code examples in /workspace/migration_audit.md.",
  agent_config: {
    type: "antigravity",
    max_total_tokens: 10000,  // total cap for this interaction
  },
  environment: "remote",
});

console.log(`Status: ${interaction.status}`);
console.log(`Tokens used: ${interaction.usage?.total_tokens}`);

When the agent hits the limit, it stops safely and returns status: "incomplete". The key point: the filesystem state and environment are preserved. All the work done so far – cloned repos, installed packages, intermediate files – remains in the sandbox.

Resuming an incomplete interaction

You can continue exactly where it left off by creating a new interaction with the same environment and passing the previous_interaction_id. You also get a fresh token budget for the continuation.

if (interaction.status === "incomplete") {
  const continuation = await client.interactions.create({
    agent: "antigravity-preview-05-2026",
    input: "continue",
    previous_interaction_id: interaction.id,
    environment: interaction.environment_id,
    agent_config: {
      type: "antigravity",
      max_total_tokens: 10000,  // new budget for continuation
    },
  });
  console.log(`Continuation status: ${continuation.status}`);
}

This design is clever because it lets you be conservative with the initial budget. Start small, see how many tokens the agent actually uses for a given type of task, then adjust upward or downward. And if it stops, you don’t lose progress – just resume.

Why this matters beyond cost
It’s not just about saving money. It’s about predictability. With a hard cap, you can integrate managed agents into CI/CD pipelines or production workflows without the risk of a runaway job that hangs indefinitely or racks up an unpredictable bill. It turns the agent into a bounded, measurable operation.

Scheduled Triggers: No More External Cron Servers

The third piece is scheduled execution via triggers.

Before this, if you wanted your agent to run on a schedule – say, daily at 9 AM to triage GitHub issues – you had to set up your own cron infrastructure: a VM, a scheduler, retry logic, logging. That’s overhead, especially for small teams or side projects.

Now you can create a trigger resource that binds an agent, an environment, a prompt, and a cron schedule into a persistent, self-managed job.

Creating a trigger

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

const trigger = await client.triggers.create({
  schedule: "0 9 * * *", // every morning at 9:00 AM
  time_zone: "America/Los_Angeles",
  display_name: "daily-issue-solver",
  interaction: {
    agent: "antigravity-preview-05-2026",
    input: [
      {
        type: "text",
        text: "Review open PRs in our repo for new comments and address feedback. Check for new issues labeled 'accepted', skip any tracked in /workspace/solved-issues/, fix the rest, and open PRs. Save reports to /workspace/solved-issues/.",
      },
    ],
    environment: {
      type: "remote",
      network: {
        allowlist: [
          {
            domain: "api.github.com",
            transform: {
              Authorization: "Bearer ghp_example_token",
            },
          },
          { domain: "github.com" },
        ],
      },
    },
  },
});

console.log(`Trigger created: ${trigger.id}`);
console.log(`Next scheduled run: ${trigger.next_run_time}`);

Each scheduled execution reuses the same sandbox environment. That means files created or cloned in one run persist and are immediately available in the next. In the example above, the agent writes solved issues to /workspace/solved-issues/ – the next day, it reads that file to avoid re-processing already-fixed items.

You can also list execution history:

const executions = await client.triggers.listExecutions(trigger.id);
for (const ex of executions.trigger_executions) {
  console.log(`${ex.id}: ${ex.status} (${ex.start_time} - ${ex.end_time})`);
}

Where scheduled triggers shine

• Daily regression reports – run tests, collect results, send summary.
• Nightly repository maintenance – auto-close stale PRs, update dependencies.
• Periodic data scraping – fetch external data, transform, store.
• Automated documentation generation – pull latest code, build API docs, commit.
• Proactive monitoring – check system health, run diagnostics, alert only if anomalies found.

The trigger removes the need for external orchestration. You define the schedule once, and the agent runs reliably, in the same environment, with the same network rules and credentials.

What You’re Actually Running: The Sandbox Environment

To make sense of these features, it helps to know the underlying execution model.

When you call the Interactions API, Google spins up an isolated Linux sandbox (Ubuntu-based) with:

• Python 3.12 and Node.js 22 pre-installed
• Persistent filesystem across interactions (for the same environment)
• Unrestricted outbound network access by default, with optional allowlists
• Automatic shutdown after 7 days of inactivity

Your agent can clone repos, run tests, install packages, and write files – just like a local development machine. Each agent gets its own environment, isolated from others.

One more technical detail: the Interactions API itself reached General Availability in June 2026 – it’s the recommended primary interface for Gemini models and agents, not a beta experiment.

A Few Details Worth Noticing

Context compression
When the agent’s context window approaches ~135,000 tokens, the system automatically compresses it. This prevents out-of-memory errors, but compression is lossy – some early details may be summarised or dropped. If your task requires full historical context, keep this in mind.

Cold starts
After a period of inactivity, the sandbox may be shut down. The next request triggers a cold start – there’s some latency while the environment is restored. If your use case is latency-sensitive, you might want to keep the agent warm with periodic lightweight tasks.

Agent quota
Each project can have up to 1,000 managed agents. That’s sufficient for most teams, but if you’re building a multi-tenant service, plan accordingly.

Credential security
In the network allowlist, you can inject authentication headers via transform. Google recommends using minimal-permission service accounts, short-lived tokens, and regular rotation. This isn’t just boilerplate advice – your agent has full access to whatever credentials you provide, so scope them narrowly.

Putting It All Together: What These Updates Mean

The three features are not random add-ons. They form a coherent story:

Together, they transform managed agents from an experimental tool that you handle with care into a production-grade automation component that you can schedule, limit, and monitor.

That said, it’s not a silver bullet:

• Lossy compression at ~135k tokens may affect long-running tasks.
• Cold start latency can be a problem for real-time interactions.
• Free tier rate limits are fine for testing but not for heavy production loads.

But these are known constraints, not fatal flaws. Knowing them lets you design around them – for instance, break long tasks into smaller interactions, or use triggers for offline batch jobs rather than synchronous API calls.

My Take (After Running This for a Few Weeks)

I started testing the Antigravity agent with a simple task: audit internal Java libraries for deprecated methods. The first run consumed about 8,000 tokens. The second run, with a larger repo, hit 22,000. Without budget controls, I’d have been nervous about every new task. With the cap, I set it to 15,000 initially, let it run, and if it stopped early, I’d check the logs, decide if I needed to increase the budget or break the task into smaller pieces.

The trigger feature saved me from setting up a scheduled GitHub Action just to run a daily report. I created one trigger, pointed it to my repo, and forgot about it – the execution history shows me each run’s status and duration.

The free tier let me hand the API key to a junior developer on my team for experimentation without worrying about accidental charges. They explored different prompts, compared results, and only when they were confident did we move to a paid project.

Is it perfect? No. The cold start can be annoying if you need a quick response. And the compression, while necessary, means you can’t always rely on the full conversation history for very long sessions. But for scheduled, batch-oriented automation – which is where agents shine – these updates make a real difference.

One-Page Summary

• Free tier – no billing required; good for prototyping and validation.
• Budget cap – set max_total_tokens; agent stops gracefully and can resume.
• Triggers – cron-like scheduling without external infrastructure.
• Sandbox – persistent Linux environment with Python, Node, network.
• Context compression – automatic at ~135k tokens, lossy.
• Quota – 1,000 agents per project.

FAQ

What are the exact rate limits for the free tier?
The announcement doesn’t specify numbers. Check the Gemini API pricing page for current free tier quotas.

Does max_total_tokens include both input and output tokens?
Yes – it covers input, output, and reasoning tokens combined.

If the agent stops due to the budget cap, can I retrieve the work done so far?
Yes. The filesystem and environment are preserved. Use the previous_interaction_id and same environment to resume.

What’s the minimum cron interval for triggers?
The cron expression supports minute-level granularity, but actual execution frequency depends on your quota and task duration.

Can multiple triggers share the same environment?
Yes, you can reference the same environment ID across different triggers.

Is the Interactions API still in preview?
No, it became generally available in June 2026.

How do I get my GitHub token into the trigger safely?
Use the network.allowlist with transform to inject the Authorization header. Store the token securely; consider rotating it regularly.

What happens to the sandbox after 7 days of inactivity?
It’s permanently deleted. You’ll get a new environment on the next request, but any persisted files are lost.

The bottom line: if you’ve been curious about Gemini’s managed agents but hesitated due to cost or operational complexity, now is a good time to revisit them. The free tier gives you a sandbox to experiment, the budget controls give you safety, and the triggers give you automation – all without spinning up extra servers. Go clone a repo and see what it can do.