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

FAQ

Can BayLeaf handle student data?

Yes. BayLeaf services have undergone a security review by UCSC ITS, and it has been approved to handle P3 data including FERPA-protected student records. However, users should take care not to use BayLeaf to handle P4 data or use the service in ways restricted by FERPA, HIPAA, or other regulations that apply to all information technology services.

Who can access the chat or agent data that passes through BayLeaf?

There are three channels to consider:

In BayLeaf Chat, your data is visible only to yourself and the (sole) BayLeaf operator. If you delete your chats (or let them be automatically cleaned up after a period of inactivity), they are truly deleted. If you use the Temporary Chat feature, BayLeaf servers never keep, even temporarily, a copy of your chat data.
In the standard inference route of the BayLeaf API, consistent with problematic industry standards that already far exceed the protection of other campus-approved AI services, your data is handled by BayLeaf and our inference providers as cleartext. In standard inference, the BayLeaf API and its inference providers operate on a zero data retention (ZDR) basis, but you have to trust our written agreements that we don't save your data for future use.
In the sealed inference route of the BayLeaf API, your data is encrypted end-to-end in a way that neither the BayLeaf operator nor the inference provider can decrypt it: only the specific, attested server can decrypt it, and only you can decode the reply it encrypts.

Is BayLeaf really free to use?

Yes, by anyone who can log in with their UCSC account, but it is not quite unlimited. In BayLeaf Chat, your conversations with the Basic agent are subject to rate limits (e.g. messages per minute/hour/day) and depth limits (e.g. size of assistant reply as a function of the number of conversation turns). In the BayLeaf API, your activity is subject to a daily spending limit (allowing more usage of cheaper models). If your usage pattern outgrows these free limits, we can recommend outside low-cost subscription and/or pay-per-usage services that provide privacy equivalent to BayLeaf.

Who pays for BayLeaf?

Development, maintenance, and operation of BayLeaf is supported by the personal funds of a single faculty member. BayLeaf is not supported by campus, state, or federal grants, and does not involve special deals or agreements with upstream AI infrastructure providers. Thanks go to InCommon Federation (via CILogon) for providing authentication services that allow us to identify the UCSC community among thousands of other institutional partners.

Does BayLeaf use a custom-trained LLM? Does it run its own GPUs?

No. BayLeaf services only use pre-existing models. Specificity to the campus comes through prompts, skill documents, and other retrieved context data, not training. We access commodity inference services on a pay-per-token basis. At this time, it does not make sense to use a campus-specific model or operate on-campus inference services.

Is BayLeaf a wrapper around ChatGPT, Claude, or Gemini?

Nope. For political, ethical, economic, and other reasons, OpenAI, Anthropic, and Google AI services have been carefully cut out from BayLeaf. However, because we support standard protocols, parts of BayLeaf can be directly connected to these services on an individual basis (recommended for advanced users also).

Which models can I access through BayLeaf?

The landscape of available models (e.g. for text, image, audio, and other modalities) is rapidly evolving, faster than we care to update this FAQ. Currently, the model powering the Basic agent on BayLeaf Chat is a medium-sized (sub-trillion-parameter) open-weight language model. The BayLeaf API can be used to access almost any model available through OpenRouter, under the condition that it is an open-weight model being served by a zero data retention (ZDR) provider. These conditions are enforced programmatically, so the available model catalog can shift from day to day without intervention or direct oversight from the BayLeaf operator. On the extreme side for privacy and autonomy, we can help you set up local inference on your personal devices.

Can BayLeaf access the data on my computer?

It depends on how you use it:

Typical conversations on BayLeaf Chat are isolated from your computer and the broader internet. (Enable the Web Context toolkit to allow your agent to search the web in that conversation.)
If you enable the Code Sandbox toolkit, your agent can access a virtual machine, that we call your sandbox, assigned only to you. Your agent can use this to build and deploy custom tools on your behalf or work with data across conversations. Although you can drag and drop files between your personal computer and your sandbox, agents cannot use the Code Sandbox feature to directly read data from your computer.
If you use a desktop agent harness like OpenCode or OpenChamber on your personal computer, with free inference services from the BayLeaf API, the agent can access your local files subject to the in-app permission system (which typically limits access to just a specific, user-selected project folder by default). This has risks and benefits from a privacy perspective. The agent can see more of your data, but your conversation data is no longer stored on BayLeaf servers, only your personal computer.

Is there an equivalent of the Claude Cowork or ChatGPT desktop app for BayLeaf? How about Claude Code or Codex?

Yes, but it is not a BayLeaf-specific app. We can help you install the OpenChamber desktop app (based on the lower level OpenCode agent harness) and connect it to the BayLeaf API for free inference. Or you can connect it to other services. Meanwhile, many of the productivity features of those commercial apps are available inside of BayLeaf Chat when you enable the Code Sandbox toolkit. You don't need to give up access to your personal files for most tasks.

Can a teacher (or anyone else) restrict how BayLeaf is used in a course?

Somewhat, and via multiple channels. Instructors can work with the BayLeaf operator to develop course-specific agents in BayLeaf Chat (alternatives to the Basic agent) that start from custom prompts and/or have access to specific tools. Instructors can also provide texts that students should copy-paste into the start of generic chat sessions or attach to a folder that contains all of the chats for a specific course. If students are using coding agents, instructors can provide course-specific AGENTS.md or skill files in project starter code. This strategy is reasonable to use outside of computer programming courses because the agent, if instructed to do so, can handle software version control on the student's behalf.

Does BayLeaf connect to the Canvas LMS? (And how about GMail and other campus-related cloud services?)

Not automatically, but you can set it up. If you can get yourself a Canvas Access Token, your agent (running code on your computer or in a BayLeaf-provided sandbox) can access and manipulate Canvas on your behalf. A similar strategy is possible for GMail and other campus-related cloud services. Ask your agent for help setting it up, but be ready to accept responsibility for anything it does on your behalf.

Will BayLeaf be adopted as an officially supported UCSC IT service? Will it get shut down by the administration?

We hope neither will happen. Among other reasons, BayLeaf exists to set a very high privacy and autonomy bar and very low cost bar on whatever AI services that campus may adopt. At the same time, it lets the community safely access and experiment with AI in ways that are completely decoupled from the current mainstream AI vendors. Even after BayLeaf shuts down, the upstream contributions we've made to associated open-source software efforts will make it easier for other campuses to adopt and support BayLeaf-like AI services.

How can I help?

Write in public about your experience using BayLeaf. We can feature your writing on the BayLeaf Blog.
If you have one, cancel your ChatGPT/Claude/Gemini subscription and use BayLeaf services to help you through the transition to low-cost, commodity alternatives that don't cede control to the big players. Your experience and feedback will help us fix bugs and smooth over sharp edges so that it is easier for others to follow your path. Resubscribe to those services later, by choice, after that you're experienced with alternatives.
Accumulate prompts and skills into plain text files that you can carry between AI apps and services or share with others in the campus community. You and your agents can enact knowledge level machine learning that bypasses the need for centralized data collection and model training. It's a way to practice the writing side of AI literacy without getting lost in algorithms, data structures, code, or model weights.

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.