Together with Thinkubator, we examined what shapes the calculated environmental footprint of our Calendar translation. The result challenged our expectations and now helps us assess new product features.
When we started looking at the energy used by our translation feature, we had a fairly clear assumption: running an AI model in a data centre or directly on a device should make a substantial difference.
Together with Thinkubator, we set out to test that assumption. The result was not what we expected.
What happens during translation?
The Independo Calendar makes appointments from conventional calendars understandable through symbols. An entry such as “physiotherapy” or “lunch” is processed and matched with suitable symbols.
A language model is not the first step. The system initially checks whether a suitable translation has already been stored. It then performs a vector search: it looks for previously stored entries with a similar meaning. A small language model is used only when neither step provides a sufficient result.
Here, “cloud” means our servers in a data centre in Frankfurt. Both the vector search and the small language model run there. No data is sent to external providers such as Google, OpenAI or Anthropic. Find out more in Data protection in Independo Apps and our data processing information.
For the project, we compared three approaches: processing in the cloud, a combination of cloud and device processing, and an approach in which most processing happens on the device.
The assessment included active use on smartphones, tablets and other devices, charging losses, the base load of our servers, Calendar synchronisation and the translation itself.
The calculation uses one active customer account per day as its unit and reflects the system as it stood in August 2026. It is not a complete or certified life-cycle assessment. Our aim was to create a sound basis for product decisions.
Not what we expected
In our calculated baseline scenario, around 70 percent of the footprint within the assessment boundary arises while the app is being used on people’s devices. Just under 30 percent comes from the server base load, including interfaces, the database and regular synchronisation.
The server-side AI computation itself currently accounts for around 0.2 percent of the total footprint within this assessment boundary.
At our present request volume, the difference between the cloud, hybrid and on-device approaches is therefore small: less than one tenth of one percent of the total assessed footprint.
This does not mean that AI generally uses very little energy. Its share is small in our case because the translation architecture keeps the number of model calls low.
When those calls happen was also revealing. Around 82 percent occur during the first import of a Calendar. During everyday use, many similar titles appear repeatedly. Translations for terms such as “dentist”, “lunch” or “physiotherapy” can therefore often be reused.
Where we need to look more closely
The calculation does not provide a universal answer to the question “cloud or device?” Directly comparable measurements of energy use on both sides are still missing. Offline availability, data protection and speed also matter when choosing an architecture.
For our current system, however, the assessment points to the larger levers: server base load, regular synchronisation and the processing of large Calendar imports.
Time spent using the app on a device is also part of the calculation, but it needs context. People use the Calendar to understand appointments and daily routines and to organise them more independently. Reducing that useful interaction is not the goal. Our responsibility is to run the app efficiently and avoid unnecessary processes.
A tool we can keep using
For us, the most important result of the project is the assessment tool it produced.
It allows us to make an early estimate of a new AI-supported feature: How many additional model calls would it require? Can results be reused? How large is the language model? Will the feature add more screen time?
This matters because the current findings cannot simply be applied to every new feature. A feature that frequently processes free text, for example, may benefit far less from cached results than recurring Calendar entries do.
The tool makes us surface these assumptions early. It does not decide which feature we should build. It shows us when we need better measurements and when different implementations deserve closer comparison.
Our collaboration with Thinkubator began before this environmental assessment, initially with the roles reversed. Julia Kruselburger, Michel Höchtl and Konstantin Strümpf supported the Thinkubator team with plain language and inclusive event design for its school programmes and the Climate Innovation Festival. Both teams learned from one another. That exchange led to our next shared question: What are the environmental consequences of new Independo features and architectural decisions?
The project was supported by Alexandra Kick, Felix Ambros and Bastien Huber from Thinkubator.
We will refine some of the values as better data becomes available. For future product decisions, though, we have already gained something useful: a clearer sense of where closer attention can make a real difference.
