Opinion: Free Model Access Should Make systemd Drafts Disposable

#systemd #devops #ai #opinion

Free model access and a free server change the economics of infrastructure automation in one specific way: the cost of producing a draft drops close to zero, so the sensible workflow shifts from crafting a single careful prompt to generating several constrained drafts and discarding most of them. The common mistake is using a free tier the way developers used paid generation, accepting the first plausible output and then spending scarce attention defending it. My position is that when generation is free, the review standard should rise, not fall, and a systemd unit draft should be treated as disposable until it passes an explicit scoring gate. This article is an opinion piece, but the workflow I describe is reproducible on any Linux host with systemd.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode provides free model access and a free server option; the article assumes those two availability facts but does not assume particular model names, quotas, hardware, or durations.

Why free generation does not lower the verification bar

A zero-cost draft looks harmless, but its apparent cheapness hides a real cost shift. When each generation is expensive, developers invest in a precise prompt because the model call itself is the scarce resource. When generation is free, the scarce resource becomes human review time, so the rational move is to generate multiple alternatives and spend review effort only on the strongest candidates. That change is useful only if there is an objective way to compare drafts before a person looks at them. Otherwise free generation produces more output, not better output, and the reviewer drowns in plausible variations.

The verification bar has to move in the opposite direction from the generation cost. A free server makes it inexpensive to run static checks, isolation probes, and repeated comparisons, so there is no longer a reason to accept a unit file just because it parses. The point of a free server is not to host an early draft indefinitely; it is to act as a disposable graveyard for the drafts that do not survive the gate.

The scoring gate: check before you adopt

I use a small scorecard because it forces me to compare drafts on observable properties rather than on which output sounds most confident. A score is not a proof of safety, and it is deliberately narrow: it covers unit syntax, shell metacharacters, privilege, restart policy, memory ceiling, and systemd's exposure baseline. Those checks answer the question a free server is best at answering: which draft deserves the next round of deeper review.

The table below shows the weight for each check and the problem it catches.

Check	Weight	Why it matters
`systemd-analyze verify` passes	20	Rejects invalid unit syntax before any execution
No shell metacharacters in `ExecStart`	20	Reduces the risk from unquoted command fragments
Non-root `User` declared	10	Limits the damage if the process is compromised
`Restart=` policy declared	10	Makes failure behavior explicit
`MemoryMax=` declared	10	Prevents an OOM surprise on a small free host
systemd exposure level known	10	Gives a baseline for sandboxing

The weights are not a security audit. They are a cheap triage layer that can run in seconds on a free host and that surfaces the drafts most likely to fail later.

Reproducible artifact: score three systemd drafts

The script below accepts two or more unit files and prints a ranked table from highest score to lowest. It uses only systemd-analyze verify, common grep checks, and awk for the exposure line, so the same logic works across most systemd distributions. Treat the script as a proposal and test it in a sandbox before relying on it.

#!/usr/bin/env bash
set -euo pipefail

DRAFTS=("$@")
if [ "${#DRAFTS[@]}" -lt 2 ]; then
  echo "usage: $0 draft1.service draft2.service [draft3.service ...]" >&2
  exit 2
fi

score_draft() {
  local unit="$1"
  local name score notes exposure mem
  name="$(basename "$unit")"
  score=0
  notes=""

  if systemd-analyze verify "$unit" >/dev/null 2>&1; then
    score=$((score + 20))
  else
    notes="$notes verify=FAIL"
  fi

  if grep -Eq '^(ExecStart|ExecStartPre|ExecStartPost)=.*[;&|`$]' "$unit"; then
    notes="$notes shell_metachar=FAIL"
  else
    score=$((score + 20))
  fi

  if grep -Eq '^User=root$|^Group=root$' "$unit"; then
    notes="$notes runs_as_root"
  else
    score=$((score + 10))
  fi

  if ! grep -q '^Restart=' "$unit"; then
    notes="$notes no_restart_policy"
  else
    score=$((score + 10))
  fi

  if ! grep -Eq '^MemoryMax=' "$unit"; then
    notes="$notes no_memory_cap"
  else
    score=$((score + 10))
  fi

  exposure="$(systemd-analyze security "$unit" 2>/dev/null | awk -F'[[:space:]]+' '/Overall exposure level/{print $NF}' || true)"
  if [ -n "$exposure" ]; then
    score=$((score + 10))
  else
    notes="$notes exposure=UNKNOWN"
  fi

  printf '%s\t%s\t%s\n' "$name" "$score" "$notes"
}

for draft in "${DRAFTS[@]}"; do
  score_draft "$draft"
done | sort -t$'\\t' -k2,2nr

On distributions where systemd-analyze security expects a loaded unit name rather than a file path, place the drafts in a transient directory and call the command against the loaded unit name. The ranking still works because the other checks do not depend on that command.

The ranking helps in two ways. First, it makes the discard step visible: you are not choosing a winner from all outputs, you are dropping the drafts that failed a cheap check. Second, it creates a record of why a draft was rejected, which is more useful than a vague feeling that one output looked better than another.

What the score does and does not tell you

A high score does not mean the unit is safe to run in production. It does not check network egress, filesystem paths, secret material, package provenance, or the actual behavior of the process after launch. It also does not validate that the command line means what the model said it means. The score only answers a narrow question: does this draft survive the first round of mechanical review on a disposable host?

That distinction matters because a free server is often small and ephemeral. It is excellent for burning CPU cycles on failed drafts, but it is a bad place to learn whether a service behaves correctly under sustained load. Use the free tier to eliminate weak drafts and to run a short smoke test, then move the remaining candidate to a proper test environment for the checks this scorecard cannot perform.

Who should not use this approach

If a unit will run in a regulated environment, a multi-tenant production host, or any context where a failure has legal or financial consequences, this scorecard is not a substitute for a real review process. If the service is stateful and a free server may be wiped or throttled, do not keep the only copy of the state there. If your team already has a unit-testing pipeline for service files, this ranking is a triage step, not a replacement for the pipeline.

The strongest use of free model access is not to generate a single perfect unit file. It is to generate enough drafts that you can afford to be ruthless about discarding the weak ones. MonkeyCode's free model and server option makes that workflow cheap, but the scoring gate is the part that actually reduces operational risk.

DEV Community