Yeti uses two different types of licenses, an interactive license (yeti_i in the license file) and a render license (yeti_r in the license file).  

Yeti licenses are shared per host, multiple instances of Yeti on a single host (workstation or server) will only use a maximum of 1 interactive and 1 render license regardless of the number of users or instances on that host.  

Some features of Yeti require an interactive license and others only a render license. 

An easy way of differentiating is to ask yourself whether or not a graph is being evaluated to produce a result (for display or rendering) which would require a render license, or is a graph being edited, a user is grooming or graph inputs are being updated (animation and dynamics) which would require an interactive license. 

The exception to this rule is if Maya is running in batch mode which will only ever use a render license, this means that scripted pipeline tasks that are distributed on servers using Maya in batch mode will only consume render licenses. 

All of this should be kept in mind when designing a pipeline that uses Yeti, if published assets used by animators have live Yeti graphs then each animator will need an interactive license.  

On the other had, if fur caches are written out when animation is published and lighters reference these cache files then they will only ever need a render license.

Yeti will only query the license server once a Yeti node is in use, so the Yeti plugin can be loaded even if a license isn't available.  When a Yeti node is created, it will only attempt to check out an interactive license if a node is being edited, otherwise a render license will be used.  If the user has a render license checked out and they start and editing process then Yeti will first check and see if an interactive license is available, if so this will be checked out and the render license returned - otherwise it will hold on to the render license and the attempt to edit will fail. 

Limiting access to Interactive licenses

There may be some situations where you want to limit access to Yeti interactive licenses, maybe to avoid a specific group of users from mistakingly using them if a wrong asset is published or opened.  

The YETI_INTERACTIVE_LICENSE environment variable is available and when set to 0 will cause all attempts to check out an interactive license to fail. 

Setting YETI_INTERACTIVE_LICENSE to 1 will cause attempts to check out an interactive license to succeed and is exactly the same as not setting it at all. 

Ideally this should be used more as a stop gap solution to errant licenses being used vs a permanent solution, ultimately your workflow should ensure this isn't needed.