Version 6.18.1.0 is a regular release, which introduces the much-awaited-for concept of "radio-button codes" (i.e. mutually exclusive codes). It also extends LLM support to 5 additional models (GPT 5.6 terra, GPT 5.6 luna, Claude Fable 5, Claude Haiku 4.5 and Llama 3.3). Behind the scenes, the APIs for EPPI Reviewer and EPPI Visualiser are now rate-limited, which is a safety feature that is aimed at improving stability and interoperability.

New Features

Radio-button codes (mutually exclusive codes)

Coding activities often rely on "answering questions that admit only one answer". For example, many screening exercises require to pick one and only one screening code (items are expected to be either included or excluded, not both), and many Quality Assurance or Risk of Bias questions admit one answer from a short list of choices, like "Yes, no, unclear". Until now, in all such situations, EPPI Reviewer relied on reviewers to observe the implicit (and not enforced by EPPI Reviewer itself) rule of only ticking one such code per item. With this release, it is now possible and optional to enforce the "only one of these codes can be ticked" rule. This is done with the mechanism called "Radio-button codes". Here is how they work:

1. Creation: 
   1. Radio-button codes can be created in "edit coding tools", in "item details" (full UI) and in "create new code" from the toolbar in the collaborate tab
   2. Codes of the following types can be created as "Radio buttons": Include, Exclude and Selectable
   3. However, "Admin" coding tools do not allow "Radio buttons" at all (even when using the "selectable" type)
2. Visual:
   1. In "Edit tools", they show with a circle after the codename
   2. In the main screen, they are not marked out (we don't show any code-type visual cue in this view)
   3. In item details, they show a round, not square, checkbox
3. Main Behaviour:
   1. The "radio" functionality (/mutual exclusivity) operates between siblings. If someone ticks a radio button code when a different sibling radio-code (i.e. a radio-button that appears at the same level in coding tool, as it has the same parent code) is already ticked, the tick in this second code is removed
   2. Radio and not-radio codes can co-exist within the same level, and their order has no effect, all that matters is their level in the hierarchy (or, more precisely, which radio-button codes have the same parent code)
4. 4. Limitations:
   1. Bulk assigning items and search-results to radio-button codes is not allowed. Upon trying, EPPI Reviewer will show a notification that explains this fact. This is because bulk assignments can require to concurrent "bulk un-assign" other codes, to respect the "mutually exclusive" nature of these codes - as a consequence, errors or unexpected results may happen, and/or conflicts, when multiple users are coding the same items. (Bulk un-assigning is allowed.)
   2. For similar reasons, it is possible to convert a radio-button to "not-radio", but existing "not-radio" code buttons cannot be made radio
   3. Moreover, once created, radio-button codes can be deleted, but it is not possible to change their immediate ancestor (i.e. moving a single radio button code to a different part of its coding tool). This is because the "mutual exclusivity" nature of this codes operates on all their siblings, not just the single code; thus, moving radio-button codes can and often would generate situations of inconsistent data, i.e. where the "mutual exclusivity" rule isn't respected
   4. It is however possible to move a whole branch of a coding tool, even if it contains radio-button codes

Overall, radio-button codes come with a number of restrictions, which is somewhat unusual in EPPI Reviewer; on the other hand, they allow one to enforce commonly deployed "coding rules", and for this reason, we believe they can be a very useful functionality.

Five additional large language models (LLMs)

These are GPT 5.6 terra, GPT 5.6 luna, Claude Fable 5, Claude Haiku 4.5 and Llama 3.3.
- GPT 5.6-terra: is the latest "flagship" model from OpenAI. It promises to be the most accurate of the OpenAI models, and of course, it is also the slowest and most expensive one to run.
- GPT-5.6-luna: is marketed as designed for cost-sensitive, high-volume workloads and as roughly corresponding to the nano model tier used in earlier GPT-5 families.
- Claude Fable 5: latest flagship model from Anthropic. Like the "terra" OpenAI model it is the most accurate, slowest and most expensive model currently available from this family of LLMs. It also has new "enhanced" safety filters, which means it often refuses to answer questions about basic life science papers, or papers about chemistry and radioactive material.
- Claude Haiku 4.5: is the cheaper and faster model of the Claude-4-5 family, it's optimised for cost-effectiveness and speed. It uses older "safety filters", so it refuses to provide answers less often than Fable.
- Llama 3.3: isn't strictly new, but is a mainstream model from the Meta firm. It's marketed as a multilingual model, optimised for assistant-like chat/tasks. It appears now (albeit it's not new) because it took us an unusually long to make it work well for EPPI Reviewer.

List or retired LLMs

All LLMs provided by EPPI Reviewer are accessed via the Microsoft Azure environment/APIs. They almost always come with a "retirement date" which can often change, but is never very far in the future (most have a life-span of 2-3 years). As a consequence, models available from EPPI Reviewer are starting to be retired. For audit purposes, EPPI Reviewer keeps a permanent record of old, now retired, LLM models. This list is now available in the "Automation logs" page, in the "Robot-coding Jobs" tab. On the top right corner of this screen, a new "[Show/Hide] Active and Retired Robot Lists" button allows to access the two lists. Each LLM can thus be selected to visualise its details, including the prices and current retirement date.
The list of already retired LLMs currently is: Mistral Large 24.11, Llama 3.1. 
The next models to be retired are: 
DeepSeek-R1 (13 Aug 2026), OpenAI GPT4 (1 Oct 2026), GPT 4.1-nano and  GPT 4.1 (14 Oct 2026), OpenAI o4-mini and o3 (16 Oct 2026). [All dates are subject to change!]

Automatically detect "new versions"

When a new version of EPPI Reviewer is published, the server-side (API and related) updates in real-time, but what runs in people's browsers (the "client", which is what you see) doesn't necessarily update immediately. We all have the habit of keeping our tabs open, and even if we don't, browsers can and do remember recently visited pages, and thus use their inner cache to reduce loading times. As a consequence, when a new version comes out, it is possible for people to use the older, outdated version of the client for days or even weeks. This isn't ideal because mismatches can and do happen, whereby errors are triggered because the client is sending or expecting the wrong kind of data when communicating with the API.

To address this problem, whenever the login page is loaded, the EPPI Reviewer client now checks if the Version Number has changed. If it detects a change it will show a dialog, offering to re-load the client.
Please note: this change can only work once the new client has been loaded, for this reason, it will kick in at the next update, not this one!

Import coding tool(s): filters/searching

EPPI Reviewer includes functionalities to import(/copy) coding tools, by choosing from the list of public coding tools or from the list of coding tools that appear in reviews where the current user has Admin rights. Both lists are ever-growing, and therefore it is useful to provide ways to find the tool one is looking for, without having to scroll through the whole list. EPPI Reviewer now allows to filter by tool type (all types, screening, standard and admin) and by text present in the coding tool name.

Rate limits for the EPPI Reviewer and EPPI Visualiser APIs

As usage grows, and more organisations tap into the power of EPPI Reviewer, the demand for API-level access to EPPI Reviewer functionalities is growing. 
To begin fulfilling these needs, we believe that the EPPI Visualiser API is ideal for most use cases, at it is simpler to consume and strictly read-only, so inherently safe. However, in exceptional cases (and certainly for internal use within the EPPI Centre) accessing the EPPI Reviewer's own API might be necessary too. Moreover, as EPPI Reviewer grows, it may become more attractive to ill-intentioned parties, who might attempt to disrupt its operations for unsavoury reasons.
Implementing rate-limits on our API is thus a useful measure of self-protection, which protects the reliability of EPPI Reviewer services for all users.
For developers writing software that consumes one or the other API, rate-limits guarantee that our APIs will signal if and when they are being asked for "too much, too often"; this offers 3rd party developers a well understood, well documented way to ensure their own API client will use our APIs responsibly. Concurrently, rate-limits increase the cost of orchestrating Denial of Service (DoS) attacks, which are common, and otherwise relatively easy to engineer. 

The details:

• Both EPPI Reviewer and EPPI Vis APIs have multiple rate-limiting levels, whereby more expensive endpoints implement more stringent limits.
• All limits have been thoroughly tested against what we consider regular usage, and are either very hard or impossible to hit under these circumstances.
• All implemented limits are configurable by design, so can and will be tweaked if we'll find that they are either too stringent or too permissive.
• The EPPI Reviewer client is able to automatically adjust to the rate-limiting system, so real-world usage will remain unaffected. EPPI Visualiser will display an error message, indicating how long one should wait before reloading the page, in case it does hit a limit.

Reconcile "detailed view": allow to merge Infobox text

In the "Reconcile" page, detailed view, the function to transfer coding from one reviewer to the other is present, allowing Review Admins to modify any coding version, before completing it, based on what other people included in the comparison have coded. The same functions allow anyone who is not a review admin to acquire the coding made by other reviewers. Until now, the functionalities implemented meant that the "Infobox" text included in the final "completed/agreed" coding version could belong to one user or the other, i.e.: if the coding existed in the destination, it was possible to overwrite the Infobox text (if any) with someone else's content.
This new release adds the possibility of merging Infobox texts; when used, the resulting text will take this form:

EPPI Visualiser: order of pre-configured maps

Pre-configured maps defined in the EPPI Visualiser setup page can now be ordered. 
In the same page, pre-configured maps will also show their stand-alone URL, which, when a visualisation is "OpenAccess", can be used by any visitor to open a map directly, without having to pass through the Visualisation home page.

BugFixes:

Account manager: record of past purchases
The Account Manager allows to download "invoice" text files that contain details of what was purchased in the past. The way VAT was reported within these files was illogical/confusing and has now been fixed.

Deleting a visualisation that contains a pre-configured map
This used to generate an error and would leave the visualisation empty and generally in an inconsistent sate. This problem has been resolved.

Removing codes from a visualisation, when they are used in maps
We added a range of new checks and systems which act together to warn people when deleting codes or tools, or when unpublishing tools or codes will affect existing pre-configured maps. Moreover, in the setup visualisations page, maps that have been affected by code deletions/removals now show clear warnings.