How we handle books could keep our ai costs lower
There’s a quiet, consistent pattern with digital platforms: once a platform scales, owners optimize for rent extraction and make it more expensive no matter how “efficient” things started out.
AI tools are heading down the same path. To keep rent seekers honest, we need designs and use patterns that resist the “always more expensive” trajectory.
A few concepts of budget-friendly social infrastructure for AI could help keep our costs sustainably lower. Small prototypes could begin bringing them to life.
/* truncate */
A rich body of knowledge: libraries
AI infrastructure and the way we use it can borrow from various conventions we use at libraries. A library works because it balances three things:
- Access is easy
- Community can be broad and open
- Costs are shared and amortized
- Availability is made equitable with holds, returns, and time windows
1) The model library
“Checkout a model license for a loan period.”
Instead of paying full price for every request or tying everyone permanently to a fixed model, organizations (or shared platforms) could offer time-boxed “model availability windows.”
What this could unlock:
- People can choose tools that match the moment, without permanently locking in the most expensive option.
- Idle compute can be reduced because access can be provisioned for when people actually need it.
Why it maps to real usage habits:
We already love fast and low-friction workflows (e.g., one-click download, holds, and waiting until items are available). People don’t always optimize for “instant,” they optimize for “works when I need it.”
Prototype ideas:
- A “checkout” UI that handles holds and returns for model access.
- A scheduler that provisions resources only for active loan periods.
- Automated onboarding/offboarding so patrons don’t keep unused capacity alive.
2) The model librarian
“Hi, librarian—here’s my task. What tools should I use?”
This concept is about recommending the right model for the job, not just the first model people think of. The librarian should route requests toward the best cost/quality trade-off.
Core ingredients:
- Recommendation logic (similar in spirit to Netflix-style “you might like this”).
- Understanding whether you need recency (new knowledge) versus deep principles (older models can work well).
- Awareness of availability: what’s currently ready, and what’s on hold.
Prototype ideas:
- A task classifier that predicts which models are “good enough” and which are overkill.
- A “now vs later” decision: if you can wait, use the cheaper option; if you can’t, escalate.
- A routing layer that outputs both:
- recommended model(s)
- expected quality/risk category (so users can decide consciously)
3) The Model Lab
“I want to build something small and specialized—can I rent time on a cost-effective machine tonight?”
This is the “mainframe time-share” idea, modernized. Instead of each effort buying dedicated capacity forever, people share compute by time block, and scheduling becomes part of the product.
Key features that make this workable:
- Automated deploy/job scheduling.
- Better “debug and test beds” so teams can iterate with more confidence per dollar.
- Publicized availability: internal teams can discover what’s running and what can be forked or reused.
Prototype ideas:
- A time-slot marketplace for compute jobs (e.g., evenings, weekends, low-demand windows).
- A standardized workflow for training/evaluation so experiments are repeatable.
- “Model sandboxes” that make it easy to publish results and let others reuse them.
4) The Model Book Club
“This month we’ll all work through [model X]. Then we talk.”
Book clubs are a classic efficiency engine: they convert individual curiosity into shared learning. Applied to AI, that means less duplicate effort and fewer one-off “try it once” evaluations.
What this could look like:
- Monthly cohorts centered on a specific model or capability.
- Social-but-structured sessions (not just meetings—something like guided testing plus critique).
- Written reviews, inspired by formats like Siskel & Ebert: clear, opinionated evaluations.
Prototype ideas:
- Templates for “model reviews” with consistent benchmarks and real use cases.
- Lightweight rating/recommendation after club sessions.
- A repository of “model outcomes” so people don’t rerun the same evaluation from scratch.
5) The Model Sleight of Hand
“I want a familiar interface—but I don’t much care which model you point it at, as long as answers are decent.”
This is the “abstraction layer” approach. Users keep the same workflow (“Claude code” or whatever interface they already trust), while the system swaps underlying models dynamically to keep cost down.
This can work if the platform can:
- Manage provisioning and access safely.
- Detect when a task can be handled by cheaper models without noticeable quality loss.
- Handle experiments in a controlled way.
Prototype ideas:
- Dynamic model selection under the hood based on task type and current budget.
- Device management / config deployment automation so access is frictionless.
- A controlled experiment system where some users silently receive a cheaper model for evaluation—then ratings determine what gets promoted.
Bringing it together: costs stay low when access is planned, not just billed
The common thread across all five concepts is this:
- Stop treating compute as a constant burn.
- Treat compute as a managed resource: loaned, scheduled, routed, shared, and reviewed.
If you want, tell me a bit about your target audience (personal users, a specific business size, or internal team at “Breeze”) and what constraints matter most (budget predictability, latency, compliance, or developer experience). I can then turn 1–2 of these into a tighter prototype spec (user flows + data model + MVP scope).