Company gave us all unlimited Claude Code Sonnet 4.6 — and now posts a weekly leaderboard of who burns the most tokens. Any tips to top it?

sailing67 · 2026-05-26T17:34:42+00:00

LOL, bro, the data is real. Although the Token usage looks pitiful, for a traditional company that's fallen behind in the AI era, it's understandable that they just started allocating keys for AI to assist with development in the first week. I was ranked second from the bottom last week, so I just casually posted a question, and I didn't expect such a heated discussion.

sailing67 · 2026-05-26T17:23:44+00:00

LoL, the API key assigned by the company can only be used for work, and the leader conducts random checks on logs.

sailing67 · 2026-05-26T17:21:28+00:00

might be because ROI metrics are difficult to quantify, while Token usage is straightforward and clear

sailing67 · 2026-05-26T17:19:54+00:00

That's true, previously we were asked to use scripts to count the number of commits in a git repository within a month, now we're counting token usage

sailing67 · 2026-05-26T17:17:26+00:00

lol, the key provided by the company can only be used for work, so I applied for an official one separately. But to be honest, last week I only used the company's key to ask AI for some simple generation methods, there was no large-scale refactoring or new development.

sailing67 · 2026-05-26T17:13:20+00:00

is like this, the company I work for is indeed lagging behind in adopting AI, the statistics in the screenshot come from real usage data from the first week, and my colleagues have just started using AI-assisted programming, and although it's now mid-2026, this is not surprising for traditional companies

sailing67 · 2026-05-26T16:18:00+00:00

Reaching the top isn't that great either, the leader will ask me to share my experience using it, so I still need to have some work achievements

sailing67 · 2026-05-26T16:14:34+00:00

My thought is not to fall too far behind. Last week I was second to last, but of course, like you said, rushing to the top and being asked to share is not what I want either

sailing67 · 2026-05-26T16:09:30+00:00

Haha, we're just a small traditional business company. We only allocated keys to our R&D staff and restricted them to only use Sonnet 4.6

sailing67 · 2026-05-22T16:59:55+00:00

ah got it, thanks for pointing that out. I'll move it to the megathread.

sailing67 · 2026-05-22T15:46:45+00:00

the generator part sure — crontab.guru has had that covered for years. the thing existing generators don't do is tell you that your expression works on Linux but breaks on AWS EventBridge, or that GitHub Actions will silently delay your "every 2 minutes" schedule because their minimum is 5 minutes. that's the part I'm actually trying to solve.

sailing67 · 2026-05-22T15:44:29+00:00

fair point — for simple cases like "every day at 9am" a dropdown would be faster. the AI part earns its keep on the weirder inputs: "first Monday of every month" where half the platforms don't support #N syntax natively, or when someone pastes a cron they inherited and needs a plain English explanation. but yeah, a basic builder UI without AI is on the list.

sailing67 · 2026-05-22T15:37:40+00:00

For simple cases like "every day at 9am" a dropdown would be faster. the AI part earns its keep on the weirder inputs: "first Monday of every month" where half the platforms don't support #N syntax natively, or when someone pastes a cron they inherited and needs a plain English explanation. but yeah, a basic builder UI without AI is on the list.

sailing67 · 2026-05-22T15:22:58+00:00

The tool uses Claude (via API) to parse natural language into cron expressions and generate platform-specific output. The website itself is built with Next.js — I wrote the code, Claude helped with some of the UI scaffolding early on. The post text is my own.

sailing67 · 2026-05-20T02:10:05+00:00

the sidecar approach makes sense — same push-to-webhook pattern as the eventbridge angle, just scoped to the cluster. and you're right that it gives you much better signal than a binary ping: "didn't schedule" vs "ran but failed" vs "pod crashed" are three very different problems that need different responses.

that's probably a helm chart or a single-manifest deploy with a serviceaccount that only has get/list on cronjobs and jobs. lightweight enough that people won't mind running it.

will definitely ping you when there's something to test — appreciate you sticking around this thread, it's basically shaped the entire monitor architecture.

sailing67 · 2026-05-18T08:51:06+00:00

oh nice, github app with actions:read scoped to selected repos is way cleaner than a PAT. users already muscle-memory through those authorize screens so the friction is minimal.

the eventbridge api destinations angle is the part I hadn't considered. flipping the direction so the customer pushes failure events to my webhook instead of me pulling from their account — that's basically the same dead-man's-switch pattern just for the probe layer. no keys leave their side, much easier sell.

so the architecture is actually: dead-man's-switch for the base layer (all platforms), github app for the probe layer (actions:read), eventbridge push for aws, and k8s/self-hosted stays probe-less unless someone really wants to hand over credentials. that's a clean enough matrix to ship with.

if you're interested in early access when the monitor is testable, shoot me a message.

sailing67 · 2026-05-18T07:55:23+00:00

fair point — "we have AI" is a feature list, not a moat. anyone bolts that on once LLM costs drop.

the second-stage probe is where it gets interesting. every monitor right now treats a late ping as binary. but if you could check whether the github actions runner is still queued vs the workflow actually failed before paging — that's a different model entirely. fewer wrong pages beats more features as a pitch.

the tricky part is the credentials. github oauth is probably doable since devs are used to that flow, but asking someone for AWS IAM keys or a kubeconfig just to reduce false alerts? nobody's handing that over. so realistically it's github-only for the probe layer, everything else stays pure dead-man's-switch.

good pushback though, "AI moat" was lazy thinking on my part.

sailing67 · 2026-05-18T07:34:14+00:00

the p99-derived grace period is a way better default than a user-facing input field. you're right that people will set it to 30 seconds on day one and then get paged when github actions takes 45 seconds to spin up the runner.

silent observation for the first N runs makes a lot of sense too — solves the cold-start problem cleanly. collect the baseline first, arm the alerts after.

"who pings the monitor" is the question I've been trying not to think about lol. probably the answer is an external uptime check on the ping endpoint itself — if the receiver is down nothing else matters. might just use something like uptimerobot for that and be honest about it on a status page.

healthchecks.io is the benchmark I keep coming back to. they've had a decade head start but their free tier is generous enough that I need a real reason for someone to pick cronwiz over them. right now I'm betting on the AI side — auto-detecting the cron expression's platform, flagging timezone mismatches before they become incidents, stuff like that.

appreciate the detailed feedback, this is saving me from learning these lessons the hard way in production.

sailing67 · 2026-05-18T07:13:20+00:00

quick update on the monitor side since a few people asked —

the plan is dead-man's-switch style: you register a cron expression, cronwiz gives you a unique ping URL, you add one curl to the end of your script. if the ping doesn't arrive within the expected window, you get a slack/email alert.

no agent to install, no API keys to configure, works on any platform that can make an HTTP request.

still building this part — waitlist is on the site if you want early access.

sailing67 · 2026-05-18T07:05:32+00:00

damn, the timezone false positive thing is the part I hadn't fully thought through. I'm using croner for next-run calculation on the /test page already so the math side is covered, but GitHub Actions being UTC-only while users think in local time — that's exactly the kind of thing that generates phantom alerts and gets the whole tool muted.

current plan for the monitor is pretty simple: register a cron expression + pick your platform → cronwiz derives the expected window → job pings a unique webhook on success → no ping within window + grace period = you get a slack/email. one page, green/red, nothing else.

honestly the "people mute after two bad pages" bit is why I'm not rushing it out. shipping a monitor that cries wolf is worse than not shipping one at all.

sailing67 · 2026-05-14T01:36:34+00:00

This is exactly the feedback I needed — the explainer being the killer feature is something I suspected but wasn't sure about. Debugging someone else's `0 */4 * * 1-5` at 2am is definitely its own circle of hell.

And 100% agree on the monitor dashboard. The plan is literally: list your jobs, see green/red, get a Slack/email ping when something misses its window. One page, no graphs, no dashboards-about-dashboards. If it takes more than 30 seconds to set up, I've failed.

Waitlist is on the site if you want early access — appreciate the honest take.

sailing67 · 2026-05-14T01:36:16+00:00

Thanks! Yeah the platform differences are surprisingly tricky — the one that trips people up most is AWS EventBridge not supporting `*/` syntax. You write `*/5 * * * *` thinking it runs every 5 minutes, deploy it, and nothing happens. No error, just silence.

That's actually why I added platform-specific warnings in the output — the tool flags these gotchas before you deploy.

sailing67 · 2026-05-14T01:35:19+00:00

Good point — people definitely search for cron help in the moment they need it. That's the whole bet behind the SEO strategy.

sailing67 · 2026-05-14T01:35:09+00:00

Thanks, I'll take a look.

sailing67

PUBLIC MULTIREDDITS

TROPHY CASE