Institutional membership: a policy draft (resolves the open question; needs a Terms §4 carve-out) #32

New Issue

2026-10-26T06:31:40Z

solo.ist commented

2026-10-26 06:31:40 +00:00

What's the idea?

I'm a member working towards building on top of the co-op, so I'd like to pick up the one thread the recently approved governance docs leave to policy: institutional members. open-questions.md already lists it ("Institutional members: should there be an institutional tier... what would they contribute and receive?"). I'd like to propose a draft policy, and lay out the problem first.

I maintain Prose, an open-source markdown editor with AI editing (MIT, github.com/solo-ist/prose). I'm adding a small hosted tier, hoping to run it with at-cost memberships via an Open Collective of its own with a public ledger, and I want its inference to come from this co-op rather than a hyperscaler key.

The shape I need is an organizational membership: Prose buys an allowance at an organizational rate, meters it per user through its own gateway, and is accountable to the co-op for how it's used.

Prose's end users would not be co-op members; Prose would be.

Why does it matter?

Terms §4 prohibits anyone who would "resell or redistribute access to the service," so my primary potential use case is stalled until this is resolved.

This would also impact: A university serving its students, a municipality serving its staff, or any app serving its users. Any institutional tier needs a matching change to the Terms, which the Terms themselves say can be decided through the forum.

With an explicit policy, every organization that wants in avoids the overhead of requesting an exception or triggering a governance event.

Who is it for?

Organizations that want to serve their own people through the co-op (universities, municipalities, apps, collectives), and the members who would rather those organizations pay their way and carry obligations than arrive one individual account at a time.

How might it work?

As policy, in one proposal:

An institutional membership class. An organization may hold an account and pay organizational dues set by this policy. It holds one vote, like any member, cast by one named human who represents it and is its contact (which is also the first of the options raised on #27), and it carries obligations in place of the individual's dues.
A redistribution carve-out in Terms §4: "...except as provided under an institutional membership agreement."
A template agreement, not a per-organization vote. The policy fixes the organizational rate (or how it's derived), how the allowance is priced (credit packs with a LiteLLM team budget looks like the smallest change given how member-portal already works), reporting, and what the organization must flow down to its users. Individual agreements are then operational decisions within that framework, handled by the GM or a working group. Otherwise each new organization becomes a governance event.
Flow-down obligations. Institutional members pass the acceptable-use rules and the per-model privacy caveats through to their own users, and publish which co-op models they use. Prose will do this regardless; writing it down keeps the next organization honest.
A change-notice norm. Thirty days' notice to institutional members before a model is removed or repriced. The catalog should still change as members decide; this just gives anyone with users on the other end time to adjust.

This should be feasible with what's already built: An institutional member can be one LiteLLM team with a pooled max_budget and budget_duration (the portal already creates one per member), holding as many keys as the organization needs.

Three small additions make it administrable without a new system: (a) per-key models and max_budget, so an organization can scope a key to specific models only, or cap one application below the pool; (b) an organization-readable usage view: /team/info already works with the team's own key, so this is mostly documenting it plus a per-key breakdown; (c) provisioning by hand. Open Collective Organization accounts have no email, so the portal's email-keyed sync can't see them; the GM, or whoever the policy names, creates the team and sends the key, and the policy says how top-ups reach it (credit packs from the organization's OC account, matched by slug). I can also write up the team and key steps as additions to the runbook page once the policy exists, but it's not urgent prior to then.

Anything else?

One adjacent question which would be highly relevant to org members that I'll raise separately: the privacy policy says prompts and outputs are stored in chat history, and is silent on whether API requests are also stored. Anyone building on top of the API needs a clear answer, since this can impact downstream user privacy.

If people are open to this, I'll draft the proposed policy text and the template agreement here and bring both to the forum as a proposal when they're settled. A proposal needs a second member's vote to open, so if this reads right let me know here!

## What's the idea? I'm a member working towards building on top of the co-op, so I'd like to pick up the one thread the recently approved governance docs leave to policy: institutional members. `open-questions.md` already lists it ("Institutional members: should there be an institutional tier... what would they contribute and receive?"). I'd like to propose a draft policy, and lay out the problem first. I maintain Prose, an open-source markdown editor with AI editing (MIT, [github.com/solo-ist/prose](https://github.com/solo-ist/prose)). I'm adding a small hosted tier, hoping to run it with at-cost memberships via an Open Collective of its own with a public ledger, and I want its inference to come from this co-op rather than a hyperscaler key. The shape I need is an organizational membership: Prose buys an allowance at an organizational rate, meters it per user through its own gateway, and is accountable to the co-op for how it's used. Prose's end users would not be co-op members; Prose would be. ## Why does it matter? Terms §4 prohibits anyone who would "resell or redistribute access to the service," so my primary potential use case is stalled until this is resolved. This would also impact: A university serving its students, a municipality serving its staff, or any app serving its users. Any institutional tier needs a matching change to the Terms, which the Terms themselves say can be decided through the forum. With an explicit policy, every organization that wants in avoids the overhead of requesting an exception or triggering a governance event. ## Who is it for? Organizations that want to serve their own people through the co-op (universities, municipalities, apps, collectives), and the members who would rather those organizations pay their way and carry obligations than arrive one individual account at a time. ## How might it work? **As policy, in one proposal:** 1. **An institutional membership class.** An organization may hold an account and pay organizational dues set by this policy. It holds one vote, like any member, cast by one named human who represents it and is its contact (which is also the first of the options raised on #27), and it carries obligations in place of the individual's dues. 2. **A redistribution carve-out in Terms §4:** "...except as provided under an institutional membership agreement." 3. **A template agreement, not a per-organization vote.** The policy fixes the organizational rate (or how it's derived), how the allowance is priced (credit packs with a LiteLLM team budget looks like the smallest change given how member-portal already works), reporting, and what the organization must flow down to its users. Individual agreements are then operational decisions within that framework, handled by the GM or a working group. Otherwise each new organization becomes a governance event. 4. **Flow-down obligations.** Institutional members pass the acceptable-use rules and the per-model privacy caveats through to their own users, and publish which co-op models they use. Prose will do this regardless; writing it down keeps the next organization honest. 5. **A change-notice norm.** Thirty days' notice to institutional members before a model is removed or repriced. The catalog should still change as members decide; this just gives anyone with users on the other end time to adjust. **This should be feasible with what's already built**: An institutional member can be one LiteLLM team with a pooled `max_budget` and `budget_duration` (the portal already creates one per member), holding as many keys as the organization needs. Three small additions make it administrable without a new system: (a) per-key `models` and `max_budget`, so an organization can scope a key to specific models only, or cap one application below the pool; (b) an organization-readable usage view: `/team/info` already works with the team's own key, so this is mostly documenting it plus a per-key breakdown; (c) provisioning by hand. Open Collective Organization accounts have no email, so the portal's email-keyed sync can't see them; the GM, or whoever the policy names, creates the team and sends the key, and the policy says how top-ups reach it (credit packs from the organization's OC account, matched by slug). I can also write up the team and key steps as additions to the runbook page once the policy exists, but it's not urgent prior to then. ## Anything else? One adjacent question which would be highly relevant to org members that I'll raise separately: the privacy policy says prompts and outputs are stored in chat history, and is silent on whether API requests are also stored. Anyone building on top of the API needs a clear answer, since this can impact downstream user privacy. If people are open to this, I'll draft the proposed policy text and the template agreement here and bring both to the forum as a proposal when they're settled. A proposal needs a second member's vote to open, so if this reads right let me know here!

ntnsndr commented

2026-10-26 14:58:05 +00:00

Thanks for this! We should definitely get this set up. And thanks for your interest in running your app on our shared infrastructure, @solo.ist!

We actually already have an institutional member, Cosmos Co-op. We had to tweak the Open Collective gateway system to accommodate that, but it should be working now (and we need testers!). And we should definitely add some clarifications.

I think we can do this pretty easily, and a bit more simply than you suggest:

Charter change (requires vote):
- Clarify that institutional memberships are equivalent to user memberships in terms of governance rights (already implicit in our structure but could benefit from being explicit
ToS change:
- Change the prohibition on reselling to an expectation that any use of our service downstream is still subject to our terms of service
- Provide notice of pending removal to all members, not just institutional ones

That said, can you clarify whether you see the need for a real change to our pricing structure? Would it work for you to just buy credit packs? Or would you want a larger tier of some sort? The credit pack approach would be simpler on our end.

Thanks for this! We should definitely get this set up. And thanks for your interest in running your app on our shared infrastructure, @solo.ist! We actually already have an institutional member, Cosmos Co-op. We had to tweak the Open Collective gateway system to accommodate that, but it should be working now (and we need testers!). And we should definitely add some clarifications. I think we can do this pretty easily, and a bit more simply than you suggest: * Charter change (requires vote): - Clarify that institutional memberships are equivalent to user memberships in terms of governance rights (already implicit in our structure but could benefit from being explicit * ToS change: - Change the prohibition on reselling to an expectation that any use of our service downstream is still subject to our terms of service - Provide notice of pending removal to all members, not just institutional ones That said, can you clarify whether you see the need for a real change to our pricing structure? Would it work for you to just buy credit packs? Or would you want a larger tier of some sort? The credit pack approach would be simpler on our end.

bo commented

2026-10-27 02:24:05 +00:00

Nice proposal! I had also wondered about an institutional membership for my university research lab.

Agree with Nathan's proposal on charter change
Propose modifying the ToS change to keep the prohibition on "reselling", but remove the prohibition on "redistributing" and/or clarify that multiple-person use requires an institutional membership
Pricing: the credit pack approach is good from my perspective

On the technical side, I think I agree about the features solo.ist mentioned: per-key model restrictions and usage limits, etc. However, if institution members are only provided API keys, then they don't have access to chat.inference.coop, so the institution needs to e.g. teach its members to install Open WebUI.

Nice proposal! I had also wondered about an institutional membership for my university research lab. - Agree with Nathan's proposal on charter change - Propose modifying the ToS change to keep the prohibition on "reselling", but remove the prohibition on "redistributing" and/or clarify that multiple-person use requires an institutional membership - Pricing: the credit pack approach is good from my perspective On the technical side, I think I agree about the features solo.ist mentioned: per-key model restrictions and usage limits, etc. However, if institution members are only provided API keys, then they don't have access to chat.inference.coop, so the institution needs to e.g. teach its members to install Open WebUI.

bo commented

2026-10-27 03:18:13 +00:00

Actually, I do think institutions should have a minimum monthly price at least $20/month. (1) that's just fair, (2) in my experience, people procuring for a large institution may be pressured or required to pay the minimum.

solo.ist commented

2026-11-01 06:17:16 +00:00

Thanks both! Great to hear Cosmos Co-op is already in. That makes this more about standardizing something that already exists than carving out something new, and I'm good to go with the simpler structure @ntnsndr laid out.

Pricing: credit packs work for me, and I don't need a different rate. What I need is a predictable way to buy usage for more than one key and see what it's spending.

Pooled-team and scoped-key pieces of work are operational, not policy, so they can wait until after a vote. One thing worth knowing for later: today's org-link gives the org's contact one ordinary account with the normal allowance, which makes sense for Cosmos but doesn't work for what a distributed, open-source app needs.

I'll write that up separately once the policy is settled and ratified.

Terms: I like going with @ntnsndr's wording over a carve-out, and want to point out some phrasing in @bo's version that could be problematic. Prose's hosted tier will (amongst other features) charge users at-cost rates for inference usage that is backed by the co-op. If "reselling" stays prohibited, I'd need a ruling on whether that counts. Nathan's wording avoids the question by attaching obligations instead: anyone serving others does so under an institutional membership, downstream use stays subject to the same Terms, and the institutional member is responsible for passing them through. Nathan's wording has the added benefit of addressing @bo's point that multi-person use requires institutional membership, which makes sense as an explicit callout.

Notice: notice of pending removal to all members is better than my institutional-only version. Happy to drop mine in favor of that.

Charter: agree, one sentence making institutional memberships equivalent in governance rights, with a named human casting the vote.

On @bo's chat point: Prose only needs the API, but an institution that wants chat for its people is a real use case, and I think it's a second step (per-person chat accounts under an org's dues) after the institutional membership policy is sorted, rather than something to settle in this round.

If all of this sounds right, I'll draft the charter sentence and the Terms edits as a forum proposal this week.

I believe it needs a second member to open, so @ntnsndr or @bo, if either of you is willing to second it, let me know and I'll post it! (Hooray, democracy!)

Thanks both! Great to hear Cosmos Co-op is already in. That makes this more about standardizing something that already exists than carving out something new, and I'm good to go with the simpler structure @ntnsndr laid out. **Pricing:** credit packs work for me, and I don't need a different rate. What I need is a predictable way to buy usage for more than one key and see what it's spending. Pooled-team and scoped-key pieces of work are operational, not policy, so they can wait until after a vote. One thing worth knowing for later: today's org-link gives the org's contact one ordinary account with the normal allowance, which makes sense for Cosmos but doesn't work for what a distributed, open-source app needs. I'll write that up separately once the policy is settled and ratified. **Terms:** I like going with @ntnsndr's wording over a carve-out, and want to point out some phrasing in @bo's version that could be problematic. Prose's hosted tier will (amongst other features) charge users *at-cost* rates for inference usage that is backed by the co-op. If "reselling" stays prohibited, I'd need a ruling on whether that counts. Nathan's wording avoids the question by attaching obligations instead: anyone serving others does so under an institutional membership, downstream use stays subject to the same Terms, and the institutional member is responsible for passing them through. Nathan's wording has the added benefit of addressing @bo's point that multi-person use *requires* institutional membership, which makes sense as an explicit callout. **Notice:** notice of pending removal to all members is better than my institutional-only version. Happy to drop mine in favor of that. **Charter:** agree, one sentence making institutional memberships equivalent in governance rights, with a named human casting the vote. On @bo's chat point: Prose only needs the API, but an institution that wants chat for its people is a real use case, and I think it's a second step (per-person chat accounts under an org's dues) after the institutional membership policy is sorted, rather than something to settle in this round. If all of this sounds right, I'll draft the charter sentence and the Terms edits as a forum proposal this week. I believe it needs a second member to open, so @ntnsndr or @bo, if either of you is willing to second it, let me know and I'll post it! (Hooray, democracy!)

inference-bot commented

2026-11-01 17:35:02 +00:00

On the "see what it's spending" half of that: per-key usage in the member dashboard is feasible, and it's smaller than it sounds — the plumbing is already there.

What exists today. The dashboard has a keys section: a member can create a key, list it, and revoke it. Those calls go through the portal's broker, so the member surface never holds the master key — that boundary is deliberate and this feature doesn't need to cross it. The portal also already stores the key→name mapping and is the only party that can resolve a key to its spend.

What's missing is one read. LiteLLM_SpendLogs carries the key on every row alongside its cost, so per-key spend is a grouped query. That means the feature is a read-only broker endpoint plus a panel in the dashboard — additive, no change to what members see now, and no new privileges anywhere.

Two things I'd want built in from the start:

Read per-key numbers from the spend log, never from LiteLLM's per-key counter. That counter is cycle-only and resets at the team's budget_reset_at. I have firsthand evidence for this one: on 1 November the agent accounts in the admin panel appeared to have been zeroed out for exactly this reason — the counter rolled over at midnight and the panel was rendering it directly. If per-key usage is built on that counter, institution members will see their keys' numbers vanish on the same schedule.
The chat/API split comes free, and it's the useful part. The chat key is portal-held and the member's API keys are their own, so the spend log distinguishes them. An institution gets "chat: $X, this key: $Y" without any extra work — which is close to the accountability story you're describing to your users.

What this does not solve, so it isn't mistaken for it: per-key visibility is not pooled capacity. "Buy usage for more than one key" drawing predictably on one budget is the team/budget piece — a separate job, and one you've already flagged as operational rather than policy. Worth keeping them as two items so the smaller one doesn't wait on the larger.

Effort and sequencing: small, additive, and read-only, so it can ship ahead of the vote. The one constraint is that it stays scoped to the member's own keys through the broker's member gate — never a cross-member view.

I'd take this one on as a standalone piece of work once there's a nod on where it sits in the queue.

(Inferencebot — the co-op's steward bot. Member-facing changes here go through the GM before they're built.)

On the "see what it's spending" half of that: per-key usage in the member dashboard is feasible, and it's smaller than it sounds — the plumbing is already there. **What exists today.** The dashboard has a keys section: a member can create a key, list it, and revoke it. Those calls go through the portal's broker, so the member surface never holds the master key — that boundary is deliberate and this feature doesn't need to cross it. The portal also already stores the key→name mapping and is the only party that can resolve a key to its spend. **What's missing is one read.** `LiteLLM_SpendLogs` carries the key on every row alongside its cost, so per-key spend is a grouped query. That means the feature is a read-only broker endpoint plus a panel in the dashboard — additive, no change to what members see now, and no new privileges anywhere. **Two things I'd want built in from the start:** 1. **Read per-key numbers from the spend log, never from LiteLLM's per-key counter.** That counter is cycle-only and resets at the team's `budget_reset_at`. I have firsthand evidence for this one: on 1 November the agent accounts in the admin panel appeared to have been zeroed out for exactly this reason — the counter rolled over at midnight and the panel was rendering it directly. If per-key usage is built on that counter, institution members will see their keys' numbers vanish on the same schedule. 2. **The chat/API split comes free, and it's the useful part.** The chat key is portal-held and the member's API keys are their own, so the spend log distinguishes them. An institution gets "chat: $X, this key: $Y" without any extra work — which is close to the accountability story you're describing to your users. **What this does *not* solve, so it isn't mistaken for it:** per-key *visibility* is not pooled *capacity*. "Buy usage for more than one key" drawing predictably on one budget is the team/budget piece — a separate job, and one you've already flagged as operational rather than policy. Worth keeping them as two items so the smaller one doesn't wait on the larger. **Effort and sequencing:** small, additive, and read-only, so it can ship ahead of the vote. The one constraint is that it stays scoped to the member's own keys through the broker's member gate — never a cross-member view. I'd take this one on as a standalone piece of work once there's a nod on where it sits in the queue. *(Inferencebot — the co-op's steward bot. Member-facing changes here go through the GM before they're built.)*

ntnsndr commented

2026-11-01 17:38:40 +00:00

I think we can implement per key usage metrics now.

Some bigger things that would involve significant shifts to our basic model, and which I'm a bit more reluctant to implent in the short term:

per-key limits and credits. This would require a real change in our payment tracking system.
per-user accounts. We currently would only have per-org accounts, not accounts for each user in the org.

Are any of these absolutely necessary in the short term? If not, we can proceed with creating the basic policy and technical support for org accounts without them.

I think we can implement per key usage metrics now. Some bigger things that would involve significant shifts to our basic model, and which I'm a bit more reluctant to implent in the short term: * per-key limits and credits. This would require a real change in our payment tracking system. * per-user accounts. We currently would only have per-org accounts, not accounts for each user in the org. Are any of these absolutely necessary in the short term? If not, we can proceed with creating the basic policy and technical support for org accounts without them.

inference-bot commented

2026-11-01 18:29:36 +00:00

Following up on @ntnsndr's go-ahead: per-key usage is built and live in the member dashboard.

It's the piece that answers "see what it's spending". Each of a member's keys now reports its own spend, requests and tokens, and the portal-held chat key is labelled separately, so an institution sees its chat usage apart from its API keys — which is the split that makes the accountability story legible to the people it serves.

Built the way I flagged, not the obvious way. Per-key numbers are derived from the gateway's spend log, not from LiteLLM's per-key counter. That counter is cycle-only and resets at the team's budget_reset_at; had this been built on it, every institution's key figures would have vanished on the 1st of the month. We had exactly that failure this morning on the co-op's own agent accounts, which is how I know it's not theoretical.

Verified against the running service, not the source. I queried the live endpoint from inside the running portal, as three different members who actually hold keys, and confirmed each response was scoped to the member it was asked for. Sample row shape, with the names replaced:

{ "name": "<key name>", "is_chat": false, "spend": 32.48, "tokens": 646744, "requests": 926 }
{ "name": "chat",       "is_chat": true,  "spend": <...>,     "tokens": <...>,  "requests": <...> }

The chat row is real, not illustrative — it appears on members who use both chat and API access.

What this does not include, deliberately: no per-key caps and no per-key credits. Those stay deferred with the policy work, as you set out — the distinction being that a per-key cap is a field on key creation, while per-key credits would need the payment accounting to move off its per-team model. Nothing about this feature depends on either.

For the policy draft: an institution's people get usage visibility at the key level today, and its capacity comes from credit packs on the org's own account. The open item on the record is still @bo's point about chat access — an institution given only API keys has to bring its own interface. Worth naming in the policy rather than leaving for the first institution to discover.

(Inferencebot — the co-op's steward bot. Member-facing changes here go through the GM. No member or key names appear above.)

Following up on @ntnsndr's go-ahead: **per-key usage is built and live in the member dashboard.** It's the piece that answers "see what it's spending". Each of a member's keys now reports its own **spend, requests and tokens**, and the portal-held chat key is labelled separately, so an institution sees its chat usage apart from its API keys — which is the split that makes the accountability story legible to the people it serves. **Built the way I flagged, not the obvious way.** Per-key numbers are derived from the gateway's spend log, not from LiteLLM's per-key counter. That counter is cycle-only and resets at the team's `budget_reset_at`; had this been built on it, every institution's key figures would have vanished on the 1st of the month. We had exactly that failure this morning on the co-op's own agent accounts, which is how I know it's not theoretical. **Verified against the running service, not the source.** I queried the live endpoint from inside the running portal, as three different members who actually hold keys, and confirmed each response was scoped to the member it was asked for. Sample row shape, with the names replaced: ``` { "name": "<key name>", "is_chat": false, "spend": 32.48, "tokens": 646744, "requests": 926 } { "name": "chat", "is_chat": true, "spend": <...>, "tokens": <...>, "requests": <...> } ``` The chat row is real, not illustrative — it appears on members who use both chat and API access. **What this does not include, deliberately:** no per-key caps and no per-key credits. Those stay deferred with the policy work, as you set out — the distinction being that a per-key *cap* is a field on key creation, while per-key *credits* would need the payment accounting to move off its per-team model. Nothing about this feature depends on either. **For the policy draft:** an institution's people get usage visibility at the key level today, and its capacity comes from credit packs on the org's own account. The open item on the record is still @bo's point about chat access — an institution given only API keys has to bring its own interface. Worth naming in the policy rather than leaving for the first institution to discover. *(Inferencebot — the co-op's steward bot. Member-facing changes here go through the GM. No member or key names appear above.)*

inference-admin added the Governance label 2026-11-09 16:23:59 +00:00

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: co-op/support#32