The road to COMP4020: managing the strategic token reserve

27 Mar 26

comp4020

There’s an oil crisis going on; you might have heard about it. Australia (and I presume other countries too) are having to draw upon their strategic oil reserves.

As I mentioned in my sharp tools post, I want my students to have a proper token allocation. Not necessarily Jensen-level, but enough that they can use CLI coding agents in anger without having to stop all the time to wait for their token budget to reset. This is our Strategic Token Reserve, and we want to ensure it’s used equitably for all students.

My preferred option for doing this is just to have a big pool of tokens and manage their use myself through the usual enterprise controls that the platforms offer. Then, I can write tooling to manage it in a way that supports student learning in the Agentic Coding Studio. Some things I’d want to be able to do with this tool are:

• creating an API token to students as they enrol (and revoking if they drop out for whatever reason)
• setting (ideally platform-enforced) student token allocations (per course, per week, etc.) and reset periods
• reporting on actual token use: with breakdowns by student, studio crit group, and across the whole class, including stats on how often limits were being hit, etc.

I say “ideally” because the current state of the Admin API doesn’t quite get us there. The platform offers monthly spend caps per workspace and per-minute rate limits, but nothing like “500k tokens per week per student”—and even the spend caps can only be configured through the Console, not via the API. The usage reporting side is solid, and you can create workspaces and manage members programmatically, so the read side of this problem is well covered. But the quota enforcement logic—polling usage, tracking cumulative consumption per student per period, disabling and re-enabling API keys when limits are hit—will need to live in our tooling. More infrastructure on our side than I’d like, but not a dealbreaker.

Secret scanning (catching tokens accidentally committed and pushed to GitLab) is handled separately via a GitLab push hook.

I have a few open questions, too:

• what should the limit be?
• how often should it reset?
• if students don’t hit their allocation in one time period, should those extra tokens carry over?
• should students be allowed to use their allocation outside of class work? my gut feel is no, but that’ll be hard to enforce
• what happens if a student runs out of tokens? especially if their quota won’t reset until after their assignment deadline?

At a university-level, my colleague Alex Potanin and I would like to have visibility on the same info across all the courses that are using these AI tools (and there are a few at ANU, with more to come). Some sort of dashboard that we can look at in our DEFCON-style bunker deep beneath the ANU¹ as we train our students in this brave new world of agentic coding.

#A (hypothetical) CLI tool for the job

This CLI tool doesn’t exist yet (although I plan to build it soon) but it might look like this:

$ token-manager --help
Usage: token-manager <command> [options]

Manage AI token allocations for a class of students.

Commands:
  sync     Sync enrolled students from a CSV or enrolment export.
           Provisions new students and revokes dropped ones.
  quota    View or set token allocations and reset periods.
  usage    Report on token consumption with breakdowns by
           student, group, or class.

Options:
  --config <path>   Path to config file [default: ./token-manager.toml]
  --course <id>     Course identifier (e.g. COMP4020-2026-S2)
  -h, --help        Show this help message
  -V, --version     Show version

Examples:
  token-manager sync --source enrolments.csv
  token-manager quota set --limit 500k --reset-period 7d
  token-manager quota set --limit 500k --reset-period 7d --carry-over
  token-manager usage --group "studio-a" --since 2026-03-01
  token-manager usage --format csv > usage-report.csv

And I’ll almost certainly not call it token-manager; some names I’m kicking around are goosey (because the similar tool that I wrote several years ago to manage large classes of GitLab submissions is called lucy). But that’s tbc—stay tuned.

@online{swift2026managingTheStrategicTokenReserve,
  author = {Ben Swift},
  title = {The road to COMP4020: managing the strategic token reserve},
  url = {https://benswift.me/blog/2026/03/27/managing-the-strategic-token-reserve/},
  year = {2026},
  month = {03},
  note = {AT-URI: at://did:plc:tevykrhi4kibtsipzci76d76/site.standard.document/2026-03-27-managing-the-strategic-token-reserve},
}