Running a 48-Hour Hackathon for Internal Model Use Cases

01 · Forty-eight hours, six teams, one shared balance

Last quarter our platform group ran an internal hackathon with one constraint that changed the character of the whole event: six product teams, forty-eight hours, and a single shared metered balance for every model call. No team received a private key with an invisible budget. No one could hide a runaway prototype inside a departmental line item. Every prompt, every retry, and every cached system instruction appeared in the same place, attributed to the same project.

That single rule turned a fun event into an operational rehearsal. Teams had to think about token cost while they designed, which is exactly the habit we need before we move model-assisted workflows into production support, incident review, and release engineering. What follows is the format we would run again, with the decisions that mattered most spelled out for team leads planning something similar.

02 · Choosing six use cases from a backlog of forty

We asked every team to submit candidate use cases two weeks before the event and got about forty of them. The shortlist came down to four questions we applied to each submission. Is this work repeated every week? Is the output checkable by a person in under five minutes? Would a partial win still be useful? Does the input data already sit inside our own systems?

Entries that failed the third question were cut without discussion. A vague research assistant with no defined output is a demo, not a use case. We also cut anything that quietly required new data ingestion, because plumbing work would have consumed the entire event and left nothing to judge.

The six finalists covered work our engineers already do: summarizing grouped error logs after a release, reviewing migration diffs for overlooked call sites, drafting runbook sections from existing notes, triaging failing test output into owner queues, writing cost report narratives from usage exports, and reconstructing an incident timeline from chat and ticket fragments.

Each team then wrote a one-page brief with four headings: input, output, failure mode, and the token budget they expected to spend. We set one shared spend ceiling for the event and made the meter visible on a wall display. Teams that blew past their estimate were not disqualified; teams that ignored the meter were, and only one warning was needed before everyone started glancing at it.

03 · Metering real tokens so the demo budget stays honest

The event ran through Quanta, the pay-as-you-go API relay our platform team standardized on for heavy, sustained workloads. One balance covers the whole catalog our engineers ask for, including Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen and Grok, and it works with Claude Code, Codex, Gemini CLI and any OpenAI SDK, so teams kept their existing tooling and only changed the endpoint. Every call is metered on real tokens, with cache writes and cache reads priced separately.

That cache distinction mattered more than any other budgeting lesson of the event. Teams that put long policy documents, schemas, and system prompts into their requests learned to reuse that context across calls, so cache reads dominated their bill instead of freshly parsed input. Teams that rebuilt the same context from scratch on every request paid for cache writes over and over, and their meters moved visibly faster than their peers.

Three habits emerged from watching the meters during the first evening:

• › Warm the context early. Establish shared instructions and reference material before the burst of interactive work, so later calls read from cache rather than rewriting it.
• › Trim before you generate. Teams that filtered irrelevant log lines and ticket history before sending them spent less than teams that sent everything and asked the model to ignore the noise.
• › Log the reason for every retry. A retry caused by a malformed output is a prompt problem to fix. A retry caused by an impatient human is a budget leak to stop.

By hour thirty, the teams with the cheapest successful runs were not the ones with the cleverest prompts. They were the ones who treated token spend the way we treat database queries in a hot path.

04 · Matching model class to the shape of each entry

We let teams pick freely from the catalog and switch models mid-event, with one requirement: they had to record why they switched and what changed in their results. That produced a better discussion at judging time than any scorecard could.

Two examples capture the pattern. The test triage entry did classification over large batches of output where speed and volume dominated, so the team settled on Claude Haiku 4.5 and spent their budget on breadth of coverage. The migration review entry did deep reasoning over a small number of diffs where a missed call site was expensive, so that team chose Claude Opus 5.5 and spent more per call on fewer, harder cases. Neither choice is universally right; the useful takeaway for team leads is that model selection should follow the cost of a wrong answer, not the novelty of the tool.

We also required each team to keep a fallback path in their brief: if the first-choice model was unavailable or too expensive for a particular input class, what would they route to instead and at what quality cost? Two teams used that fallback during the event, and both were glad the decision had been made before the pressure of the deadline.

05 · Judging on operational fit, then funding the next quarter

We deliberately did not judge on flashiness. The rubric weighted four things: measurable time saved per week, quality of the failure mode description, clarity of the human review step, and honesty of the token accounting. The winning entry was the runbook drafter, not because its output was the most impressive, but because it named exactly which paragraphs a reviewer must check and showed a defensible budget for a month of use.

The week after the hackathon, every finalist presented to the engineering leads who own production systems, and three entries were funded for a quarter of real rollout work. That transition is where most internal events fail, so we made the handoff explicit: each funded team got an owner, a review cadence, and a monthly meter report that goes to the same dashboard as our other infrastructure spend.

One practical note for leads building a sustained program rather than a one-off event. Because Quanta is pay-as-you-go and priced on real token usage, it is straightforward to give each rollout team its own project and its own visibility without provisioning separate accounts or negotiating separate contracts. The referral program is also worth knowing about if your program spreads organically across teams: you earn 19% of the top-ups made by people you refer. If you want this setup for your own organization, open a Quanta account and run the first event on a short horizon.

The largest return from our 48 hours was not the prototypes. It was that six teams now speak the same language about cost, cache behavior, and failure modes before we scale model use across the engineering organization.