BayLeaf

A situated counterplatform for Generative AI at UC Santa Cruz

Blog Use Cases Source Support

About BayLeaf

BayLeaf Chat and BayLeaf API are the working services of a situated counterplatform for Generative AI, designed to serve the entire UC Santa Cruz campus community (students, faculty, and staff). BayLeaf is operated by Adam Smith (faculty from the Department of Computational Media) as a living prototype of a possible future university-managed service.

For concrete recipes (chasing down a half-heard funding lead, rescuing a misconfigured Canvas assignment, drafting a workflow doc from scattered emails), see the use cases page.

Anarchist AI Infrastructure: a 45-minute guest lecture series making the political case for campus-owned AI, given by Adam Smith for a UCSC course.

Blocking Closed-Weight Models And other lines we could draw Sep 2, 2026
Military-grade Encryption *pew pew* Sep 2, 2026
Reduce, Reuse, Recycle reflections on a recent boo-boo Aug 27, 2026
Offramps and where they lead Aug 25, 2026
Tokens are Words, Not Money even if they seem to cost money Aug 21, 2026

Counterplatform Design

BayLeaf is a counterplatform: one situated response to the terms on which Generative AI is offered to universities. Building and operating a platform makes another set of terms concrete and available for use, scrutiny, and revision. BayLeaf treats AI as normal technology: consequential, but neither autonomous nor inevitable. The commitments below govern how this alternative is designed and operated at UC Santa Cruz.

Energy: Smaller models, smaller footprints. AI's growing energy and resource footprint is a legitimate concern. The flagship models from mainstream providers can have trillions of parameters, and training compute, energy, and cost all scale with parameter count. BayLeaf Chat uses a curated model selection rather than an unrestricted catalog, with resource footprint among the selection criteria. The API recommends a mid-sized model by default. Plaintext API inference enforces an open-weight policy, while API Sealed currently draws from Tinfoil's open-weight catalog.
Reciprocity: Keep open-weight models available. Large-scale AI is often criticized for concentrating power in a few corporations behind closed APIs. BayLeaf Chat's curated OpenRouter ZDR selection can include both proprietary and open-weight models. The API holds a stricter line: plaintext OpenRouter inference permits only open-weight models. OpenRouter must publish a nonempty Hugging Face repository ID and that repository must resolve; otherwise BayLeaf returns HTTP 403. API Sealed currently offers only the open-weight models in Tinfoil's catalog, a provider-catalog property rather than a BayLeaf-side check.
Privacy: Providers never retain your data, and our API never stores it. Many commercial AI services retain copies of user conversations, sometimes for 30 days or longer, creating exposure that users cannot control. BayLeaf leverages zero-data-retention (ZDR) inference services so that no LLM provider stores a copy of your data; they keep only request metadata. Chat and plaintext API inference use OpenRouter ZDR. API Sealed uses Tinfoil, with the requested model and body encrypted from BayLeaf. Non-streaming usage metadata can report which model executed. We apply the non-retention standard to ourselves: the BayLeaf API retains no copy of your prompts or completions and has no standing operator access to your request content as it passes through, an approach inspired by zero-operator-access designs. Chat is different by necessity: so you can carry conversations between devices, the chat interface keeps one copy of your messages in an encrypted database accessible only by the system administrator.
Governance: Start with harms in context, not model safety in isolation. AI governance often concentrates on benchmarks, guardrails, and other properties of models, even though harms arise through interactions among models, people, tools, policies, and institutions. A sociotechnical approach to AI risk instead begins with the people who could be harmed and the particular setting in which AI is used. BayLeaf responds by treating each campus use case, not its underlying model, as the relevant unit of governance: prompts, tools, data access, and permissions are scoped to particular roles and purposes, while consequential uses involving protected records require separate authorization. These measures do not make BayLeaf safe by definition; its design, limitations, and governance questions remain public so affected communities can scrutinize and reshape them.
Pedagogy: Support and resistance, not just answers. Commercial AI assistants are optimized to be maximally helpful, which in practice means maximally doing-it-for-you: students mistake speed for understanding, and the skills education is supposed to build quietly atrophy. BayLeaf's models use system prompts and agent skills written by educators for their students and peers, designed to scaffold learning rather than shortcut it. Faculty control means the tool can be co-designed with students, not imposed by a product team.
Inquiry: Grounded in sources of truth. General-purpose chatbots reward fluent output over rigorous inquiry: they generate plausible answers without grounding them in the user's actual data, documents, or methods, producing false confidence where skepticism is needed. BayLeaf connects models to grounded tools (web search, Google Workspace, code execution) so that AI-assisted inquiry can be anchored in evidence the user can verify. The system itself is counterfoil research: a working experiment in AI infrastructure that doesn't teach dependence on commercial platforms.

BayLeaf relies on a small set of subprocessors (OpenRouter, Tinfoil, DigitalOcean, Cloudflare, Daytona, Tavily, CILogon): see the privacy notice for the full list, what each one does, and the retention policies that govern your data.

Institutional Footing

A path toward institution-managed inference. UC has in-place data-protection agreements with Google Cloud and Amazon Web Services, but BayLeaf is faculty-operated from a personal administrator account and is not covered by those agreements. Its Vertex AI, AWS Bedrock, and NRP inference back-ends are disabled and carry no traffic. Active inference uses OpenRouter ZDR or Tinfoil Sealed. The full contract and retention analysis is public in our FERPA notes.

Security-reviewed by UCSC ITS. BayLeaf has undergone a security review by the UC Santa Cruz Information Technology Services (ITS) office. The campus Chief Information Security Officer (CISO) and his team reviewed the service and deemed it ready to launch: technically cleared to handle data up to Protection Level 3 (P3). That is a security determination about how BayLeaf protects data; it is distinct from legal authorization to process specific regulated records. In particular, clearance to use BayLeaf with actual FERPA student education records is a separate process, still underway with the Registrar, and is not yet granted. To be clear about scope, BayLeaf is not an ITS-operated or ITS-supported service; it remains faculty-operated. The review attests to its security posture, not to institutional adoption.

Chat Service

Our Chat service provides two models to all users:

Basic is a general-purpose assistant (which underlying model varies as better ones become available). Its system prompt is written for the campus community, orienting the model as a concise assistant with self-knowledge of BayLeaf and the Chat interface.
Help is a help desk for BayLeaf itself. It can answer questions about the service, list a user's groups and available models, inspect model configurations, and grant access to specialized groups. Users who receive invite codes from instructors or program coordinators redeem them here.

Beyond the public models, specialized models and toolkits are available to members of specific access groups (e.g. course sections, departments, or programs).

Chat uses a curated OpenRouter ZDR selection that can include both proprietary and open-weight models.

The Code Sandbox toolkit gives models access to a persistent, sandboxed Linux environment, making it possible to run command-line tools directly from the browser. This enables tasks like file processing, scripting, and interacting with external services through CLI tools without leaving the chat interface.

Most chat models are subject to a rate limit mechanism that ensures fair and cost-efficient access for all.

Tip: Chat message replies from models are limited in length based on the number of turns in the conversation so far. Users should prefer many short conversations on distinct topics rather than one long one that meanders through unrelated topics.

API Service

Our API service provides key-less access to users connecting from the campus network (e.g. 169.233.x.x), and it allows authenticated users to grant themselves an API key for off-campus access.

The API leaves system and developer instructions under the caller's control rather than adding BayLeaf-specific instructions to proxied requests.

To allow for experimentation, API requests are not closely rate limited, but individual keys are subject to a reasonable total daily spending limit.

The plaintext API uses OpenRouter but permits only verifiably open-weight models. OpenRouter must publish a nonempty hugging_face_id and the Hugging Face repository must resolve. Positive and definite-negative decisions are cached in MODEL_STATUS KV for 24 hours. An unknown result fails closed with HTTP 403 and is not cached. OpenRouter's public catalog is broader than BayLeaf's permitted set and includes models BayLeaf will reject.

API Sealed is an active confidential-inference lane through Tinfoil. It currently offers only open-weight models, and clients encrypt the requested model and body to an attested enclave before either reaches BayLeaf. Non-streaming usage metadata can report which model executed. There is no plaintext fallback.

Code Sandbox

The API also provides sandboxed Linux environments (backed by Daytona) for code execution and file management. Users get a persistent sandbox that retains files across sessions. Sandbox access requires a personal sk-bayleaf- API key, including on campus; the same key authenticates both LLM inference and sandbox access.

Web Search & Fetch

The API provides web search and page content extraction as first-class endpoints, both backed by Tavily. Agents can search the web for information and fetch clean, extracted content from one or many URLs in a single call, all authenticated with the same sk-bayleaf- API key used for LLM inference and sandbox access.

Tool Integrations

The API dashboard distributes setup instructions and credentials for CLI tools that extend what coding agents can do on behalf of authenticated users:

Google Workspace CLI (gws): Access Drive, Gmail, Calendar, Sheets, and Docs. BayLeaf distributes the OAuth client configuration so users don't need their own GCP project.
Canvas LMS CLI (canvaslms): Manage courses, assignments, grades, and announcements. Users authenticate with their own Canvas access token.

Adoption

BayLeaf is in active use across UCSC courses. A representative sample:

CMPM 118S-04: Research Pathway: Summer Vertically Integrated Project. Summer 2026 (~20 students). Using the BayLeaf API via various terminal and graphical agent harnesses.
CMPM 120-01: Game Development Experience. Spring 2026 (~30 students). Brace3, a generalized course agent customizable by instructors directly on Canvas.
CMPM 120-02: Game Development Experience. Spring 2026 (~75 students). Using the BayLeaf API in OpenCode terminal coding agent harness.
CSE 185E: Technical Writing for CS&E. Spring 2026 (~120 students). Pre-draft brainstorming and drafting feedback.
CMPM 171: Game Design Studio. Winter 2026 (~160 students). Gambit, an agent for rapid game prototyping.
CSE 185E: Technical Writing for CS&E. Winter 2026 (~50 students). Drafting feedback alongside other LLMs.
CMPM 121: Game Development Patterns. Fall 2025 (~120 students). Brace2, the first course-specific agent built on BayLeaf.
CMPM 121: Game Development Patterns. Fall 2024 (~170 students). The original Brace assistant, a precursor to BayLeaf.

Course-specific agents (Brace, Brace2, Brace3, Gambit) are built atop BayLeaf Chat with custom system prompts and toolkits. Other courses use BayLeaf's general-purpose Basic model directly.

For more granular examples of what individual users (faculty, students, and staff) actually do with BayLeaf, see the use cases page.

Ad-hoc faculty use

Beyond enrolled courses, faculty across campus use BayLeaf for one-off course-management tasks: running scripts in the Chat Code Sandbox or driving agentic CLI tools through the BayLeaf API to manipulate Canvas. Reported uses include:

Auditing multiple-choice quiz options to ensure each wrong answer has useful feedback.
Building custom interfaces for processing free-form feedback surveys.
Generating student project group rosters from enrollment and preference data.
Reverse engineering implicit learning objectives from legacy course materials.
Auditing outbound hyperlinks in blog posts and course materials to ensure they are valid, updated, and point to resources that match the rhetorical intent of citing them.

In the News

UCSC's Newly Established AI Council Is at a Crossroads (City on a Hill Press, March 2026.) Student journalism covering UCSC's AI Council and the campus debate over vendor deals vs. faculty-built tools. BayLeaf is cited as an example of the latter approach.
Secure AI Tools Now Available to Staff (UCSC News, February 2026.) Official campus announcement of Google Gemini Chat and NotebookLM (since renamed Gemini Notebook) for staff, developed in consultation with the AI Council. BayLeaf predates and complements this rollout. Update (July 2026): access was extended to all faculty as of July 1, 2026, announced in an internal campus email from the iCPEVC's office (subject: "Secure AI tools now available to UCSC faculty," 29 June 2026). This is the Gemini baseline bundled with Workspace for Education at no additional cost, not the paid Google AI Pro for Education add-on: in raw capability it is broadly comparable to Google's free consumer tier, and the meaningful institutional difference is data governance. It also provides only the web chat and Notebook interfaces: no API key or command-line access, so campus Gemini cannot be used in coding agents.

Spinoff Projects

Lathe: The open-source toolkit powering the Code Sandbox feature above. Reusable by any Open WebUI deployment. Includes support for tools like canvaslms (a Python/CLI Canvas LMS client) for agentic course management from the browser.
GWS Toolkit: Deep integration with Google Workspace (Drive, Gmail, Calendar, Sheets, Docs) packaged as a reusable Open WebUI toolkit. Per-chat, per-service user consent. Built for BayLeaf Chat; drop-in for any Open WebUI deployment with Google Workspace.
Code Mode: A single run_python(code) filter for Open WebUI that wraps a model's enabled toolkits behind a typed-Python API and dispatches sandboxed calls to the real tools. Lets models orchestrate tools as code rather than one call at a time.
OWUI CLI: An admin command-line tool for operating Open WebUI instances, used to manage BayLeaf Chat.
Perk: An OpenCode plugin that lets agents efficiently react to external events without polling. Comparable to the Monitor tool in Claude Code.

Beyond UCSC

BayLeaf is open source, built in a municipalist spirit: it serves one campus, not the entire higher education sector. The architecture is not UCSC-specific, but it is intentionally local: designed to be copied and remixed to fit the needs of other campuses, not scaled into a platform that governs them. This is the prefigurative counterpower move: build small, autonomous systems that embody the values you want to see, rather than waiting for centralised infrastructure to be reformed from within.

A 2026 Inside Higher Ed survey of campus CTOs found that half question whether their AI investments are paying off, while 41% cite "falling behind peer institutions" as a top worry through 2030. That combination, doubt about value paired with fear of missing out, is the imitation trap BayLeaf is built to refuse. A campus-owned service can be small, problem-led, and accountable to its own community rather than benchmarked against whatever neighboring institutions just bought.

If you're evaluating AI tools for your campus, read the case for universities owning their own AI infrastructure, or explore the source.

GenAI Disclosure

Nearly 100% of the code, documentation, and other project data in the BayLeaf repository was created using generative AI in agentic coding tools. This is an intentional choice: it demonstrates that sufficient capacity exists within the university to build and operate a service like this, without ceding control or responsibility to external parties. If you are a critic, ally, or other human who wants a direct human connection, please contact Adam Smith directly.