BayLeaf

A situated counterplatform for Generative AI at UC Santa Cruz

Get Started Blog Use Cases Source Support

About BayLeaf

BayLeaf provides chat and API services for UCSC students, faculty, and staff. Adam Smith, a faculty member in Computational Media, operates it to demonstrate a campus alternative: buy inference for open-weight models from commodity providers and access it through independently chosen, open-source apps.

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.

Nyström Grading Scaling interpretive depth and feedback quality with AI Oct 6, 2026
First-party Inference What would that look like? Sep 24, 2026
Human Agency, Coding Agents, and Transagentic Knowledge Acquisition In a hype cycle fascinated by rogue, hacking AI agents, it feels like there’s another kind of agency getting lost in the spectacle, one with specific relevance to higher education. Sep 17, 2026
Blocking Closed-Weight Models And other lines we could draw Sep 2, 2026
Military-grade Encryption *pew pew* Sep 2, 2026

FAQ

Can BayLeaf handle student data?

Yes, within the rules that apply to your use. UCSC ITS reviewed BayLeaf and determined it suitable for handling P3 data, including student records classified at that level. This is a security determination, not blanket permission for every use of those records. You are responsible for ensuring your use complies with FERPA and other applicable rules. Do not use BayLeaf for P4 data.

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 exact models are being used in BayLeaf right now?

BayLeaf Chat’s Basic agent uses z-ai/glm-5.3-flash. The BayLeaf API recommends z-ai/glm-5.3-flash for standard inference. These are the configured selections, not a list of every model available through BayLeaf.

This precise model selection information is generated from the repository’s configuration files and refreshed daily, as well as when site changes are published. OpenRouter links lead to its authoritative model information; other identifiers link to their BayLeaf configuration files.

Which other models can I access through BayLeaf?

Beyond the selections above, 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. BayLeaf demonstrates that a campus can support useful AI without buying an integrated chatbot package for everyone. We want procurement to let arrangements like this compete on their usefulness, privacy, accessibility, and full operating costs, including maintenance and support. The aim is to make alternatives credible, not to secure adoption of BayLeaf itself. Our contributions to shared open-source tools can also help other groups operate services on their own terms.

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: a working alternative to the terms on which Generative AI is offered to universities. People can use it, inspect its design, and argue for changes. BayLeaf treats AI as normal technology: consequential, but neither autonomous nor inevitable. The commitments below guide its operation and our proposals for campus infrastructure.

Think of the succession Internet → Web → Cloud → Generative AI. Each builds on earlier infrastructure. The Internet, Web, and Cloud found wide adoption and changed university practices without destroying higher education. That history gives us reason to approach this next layer with curiosity and judgment rather than hype or panic. It does not make adoption inevitable or every use worthwhile. We can ask what helps a particular practice, what it costs, and which terms we are willing to accept.

Procurement: Buy inference separately from the app. Campuses can purchase metered inference and support independently chosen desktop software or institution-operated interfaces. Think campus internet access, rather than subscriptions to a few services delivered over it. Models differ, but changing suppliers need not mean replacing everyone's working environment. Procurement should evaluate these arrangements on their merits instead of requiring a single vendor's complete package.
Autonomy: Integrated chatbots should be optional. Ordinary campus services, such as advice about completing a degree, should not require a particular chatbot. A university should help ordinary users set up alternative clients: exemption from surveillance must not be a power-user-only feature. Courses retain their own tool choices; we want open alternatives to be easy for instructors to offer. Refusing a corporate package can coexist with learning and using AI.
Energy: Enough capability, bounded consumption. AI uses energy, water, and hardware whose costs extend beyond the inference bill. Maximum model capability and ever-growing usage should not be campus goals. We favor smaller models where they are adequate, bounded use, and declining computation that adds little value. BayLeaf caps usage and recommends a mid-sized model through the API. These are interventions toward sufficiency, not proof of a smaller footprint: environmental comparisons need evidence about the actual workload and infrastructure, not parameter counts alone.
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, checked through public weight-repository links. Sealed inference currently offers only open-weight models because those are the models its provider, Tinfoil, supplies. Publishing usable weights is a contribution back to a shared technical ecosystem and a counterweight to concentrated ownership, even for people who never run a model themselves. It does not settle the politics of training data or labor.
Privacy: Distinguish retention from operator access. A service can retain no content while still allowing an operator to inspect it in transit or deploy code that captures it. BayLeaf uses zero-data-retention (ZDR) inference services: providers retain request metadata, not prompts or replies. The BayLeaf API also retains no content and gives its operator no standing access to it. But an operator with deployment rights could change the plaintext service to capture content. Inspired by zero-operator-access designs, Sealed inference encrypts requests to an attested server so neither BayLeaf nor the provider's operators can read their content; compatible client support remains limited. Chat, by contrast, stores conversation history for use across devices, and its administrator can read it. The privacy notice details these boundaries and the metadata each service handles.
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. Users remain responsible for complying with the rules governing their use of protected records. 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.
Learning and local authorship: Help people understand what they build. General-purpose agents tend to optimize for completing work, not for helping people learn through it. The You can learn with AI podcast episode explains how metacognition, deliberate pauses, and classroom co-design can turn AI assistance into active learning. Its companion Learning Opportunities agent skill puts those learning-science principles into practice. Educators and groups can likewise write prompts, skills, and disciplinary resources that participants' agents can read without controlling those agents or maintaining separate versions of campus infrastructure.
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, not blanket authorization for every use of regulated records. There is no separate platform-wide Registrar approval pending: restrictions apply to particular uses, and users are responsible for complying with FERPA and other applicable rules. BayLeaf remains faculty-operated, not ITS-operated or ITS-supported.

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 limit how many messages each user can send per minute, hour, or day to control usage and costs.

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.

API requests are not closely rate limited, but each key has a daily spending limit.

The plaintext API uses OpenRouter but permits only verifiably open-weight models served by zero-data-retention providers. It rejects requests when it cannot verify eligibility. OpenRouter's public catalog is broader than BayLeaf's permitted set and includes models BayLeaf will reject.

API Sealed encrypts your request before it reaches BayLeaf. A compatible client verifies the Tinfoil server's attestation and encrypts the model selection and request body so only that server can decrypt them. Sealed currently offers only open-weight models and never falls back to plaintext. Non-streaming usage metadata can identify the model used.

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. Reported major course uses:

CMPM 121: Game Development Patterns. Fall 2026 (~80 students). Students use Brace3 to discuss code in natural language. Course policy prohibits the agent from speaking or writing whole lines of code, at students' request to avoid the temptation to copy and paste.
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.
Using confidential inference services (BayLeaf Sealed Inference) to spot common misconceptions in students' free-form reading responses from Canvas.
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 Media

Embedded.fm episode 535: The You in the Machine. Interview with BayLeaf operator Adam Smith about counterplatforms, transagency, context distillation, and local inference for community-scoped language models.
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): an iCPEVC campus email announced faculty access from July 1. The campus offering includes web chat and Notebook interfaces, but no API access for coding agents.

Spinoff Projects

Open WebUI enhancements:
- 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: Access to 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.
OpenCode and OpenChamber enhancements: Improve the desktop user experience for people using agents through the BayLeaf API service.
- opencode-tinfoil: Confidential inference through Tinfoil. Verifies the enclave before sending a request, encrypts the inference body, and fails closed rather than falling back to plaintext. Supports OpenCode V1 and V2.
- opencode-perk and opencode-monitor: Plugins for OpenCode V1 and V2, respectively, that let agents react to streams of external events without active polling. Comparable to the Monitor tool in Claude Code.
- openchamber-jobs: An independent OpenChamber extension showing running commands, live output, and elapsed time across a conversation and its subagents, with controls to cancel background jobs. Works with or without opencode-monitor.
- opencode-odometer: Nudges agents to notice cached and uncached input tokens and output tokens as cumulative session token use crosses thresholds.

Beyond UCSC

BayLeaf serves one campus. Other communities can reuse its open-source software and adapt prompts and tools without maintaining a separate version of everything. This municipalist approach builds local control through shared infrastructure. It practices prefigurative counterpower by giving communities an alternative they can operate and change. Participants can carry their skills and resources to other services, including if they choose to leave BayLeaf.

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 separately purchased inference, participant autonomy, and locally extensible campus services, 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.