A Decision Tree for Free-Tier AI Automation: Terms, Branches, Worked Leaves

AI turned every developer into a reviewer. The bottleneck moved from writing code to judging it. That judgment is exactly where a cheap model plus a cheap server can earn its keep — if you choose the right job.

Say you maintain a small open-source repo. Every morning, a cron job reads new issues, classifies each one as bug, feature, or question, and drafts a first response. The job is batch, low-volume, and failure-tolerant. Does it belong on a free model and a free server?

This article gives you a glossary, a decision tree, and a worked example at every leaf. No leaderboard arguments. Just a way to decide before you build. It is not a scorecard for model quality; it is a filter for operational fit.

The tools in scope

MonkeyCode is an open-source project that offers free model access and a free server option for automation jobs like this. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I am not going to benchmark it here. The project's own repository is the source of truth for current quotas; as of this writing, the advertised free tier includes 10 million tokens, but those numbers change. Pin your decision to the repo, not to this article. Being open source means you can also read the code and audit what the free tier actually does.

Glossary: eight terms you need before the tree

1. Token budget — tokens per run × runs per day. This single number decides whether a free tier survives a month.
2. Context window — how much input fits in one call. It decides whether you can stuff 200 issues into a single prompt.
3. Rate limit — requests per minute. It matters for bursty loops, not for one cron run.
4. Cold start — the first call after idle can be slow. It kills interactive use; batch jobs barely notice.
5. Structured output — JSON with a schema. It turns model output into something you can validate before posting.
6. Idempotency — running the job twice produces the same result. It is what makes retries safe.
7. Egress — bytes leaving the server. Free servers often cap it harder than CPU.
8. Cron trigger — time-based invocation. It is the natural fit for a free server that sleeps between runs.

The decision tree

Node 1 — Interactive or batch?
If a human is waiting on the response, go to Leaf A. If the job runs on a schedule, go to Node 2.

Node 2 — Can you tolerate failure and retry?
If a missed run causes a real incident, go to Leaf B. If a retry an hour later is fine, go to Node 3.

Node 3 — Is the output structured or free text?
If you need JSON, labels, or a fixed schema, go to Node 4. If free-form prose is acceptable, go to Leaf C.

Node 4 — Does the per-run token volume fit the free quota with 2× headroom?
If no, go to Leaf D. If yes, go to Leaf E.

Worked examples at every leaf

Leaf A — Reject: real-time chat assistant.
A user asks a question and waits. Cold starts and rate limits turn a 2-second model into a 20-second experience. Free servers sleep; interactive products cannot.

Leaf B — Reject: payment reconciliation summaries.
A missed run means a missed deadline. Free tiers have no SLA, so "it usually runs" is not a guarantee. Put this on infrastructure you pay for.

Leaf C — Accept with human review: a weekly team digest.
The model writes a rough summary of merged PRs and open questions. A human edits before sending. Failure means you edit more; it does not mean the world breaks.

Leaf D — Reject or hybrid: weekly digest of 5,000 issues.
At roughly 300 tokens per issue, one run is 1.5M tokens. It fits a 10M quota once, but a second run plus a retry blows past it. Chunk the job, or move it to a paid tier.

Leaf E — Accept: issue triage bot.
Batch, retry-safe, structured output, and 200 issues × 300 tokens ≈ 60k tokens per run. That is 0.6% of a 10M quota. This is the leaf the rest of the article builds.

The artifact: a triage pattern that survives the free tier

The following is an illustrative pattern, not a tested MonkeyCode integration. Adapt it to whatever endpoint your provider exposes.

# Illustrative pattern, not a tested MonkeyCode integration.
# Adapt to whatever endpoint your provider exposes.
import json
import os
import urllib.request


def build_prompt(issues):
    # Truncate to fit the context window; keep the newest issues first.
    lines = [f"- #{i['number']}: {i['title']}" for i in issues[:200]]
    return "Classify each issue as bug, feature, or question. Return JSON.\n" + "\n".join(lines)


def run_triage(issues):
    payload = {
        "model": os.environ["MODEL_NAME"],
        "messages": [{"role": "user", "content": build_prompt(issues)}],
        "response_format": {"type": "json_object"},
    }
    req = urllib.request.Request(
        os.environ["ENDPOINT"],
        data=json.dumps(payload).encode(),
        headers={"Authorization": f"Bearer {os.environ['API_KEY']}"},
    )
    with urllib.request.urlopen(req, timeout=60) as resp:
        body = json.load(resp)
    return json.loads(body["choices"][0]["message"]["content"])


def validate_schema(result):
    required = {"bug", "feature", "question"}
    return all(item.get("label") in required for item in result.get("issues", []))


def post_triage(result):
    for item in result["issues"]:
        # Idempotent: skip issues that already carry the label.
        if not already_labeled(item["number"], item["label"]):
            add_label(item["number"], item["label"])


if __name__ == "__main__":
    issues = load_new_issues()
    result = run_triage(issues)
    if not validate_schema(result):
        raise SystemExit("schema mismatch — do not post partial output")
    post_triage(result)

Three design decisions matter here:

1. Timeout. A hung model call should fail the run, not stall the cron job forever.
2. Schema validation. If the model returns labels that do not match your repo's real labels, do not post. Partial output is worse than no output.
3. Idempotent posting. Check whether an issue already has a label before adding one. Then a retry is harmless.

Walk the tree once more

The issue triage job: batch → Node 2, retry-safe → Node 3, structured → Node 4, 60k tokens per run with 2× headroom → Leaf E. Accept.

Limitations and who should not use this

Free quotas change. Free servers sleep. Data leaves your machine, so never send secrets, customer PII, or proprietary source code you cannot afford to expose. There is no SLA, no guaranteed delivery, and no on-call.

Do not use this approach for real-time products, regulated data, or anything where a missed run is an incident.

Try it

If you want to test the Leaf E path yourself, MonkeyCode's free model access and free server are a reasonable starting point — the README shows current limits. The interesting result is not that it works. It is where it breaks first. That is the data worth sharing.