GitHub stellt das Bezahlmodell für den KI-Assistenten Copilot ab dem 1. Juni 2026 auf verbrauchsbasierend um: Die monatlichen Kosten für die bisherigen Tarife bleiben gleich, aber GitHub rechnet AI Credits für die Nutzung von Tokens ab. Ein Credit entspricht dabei 0,01 US-Dollar und die Kosten variieren je nach Modell. Leistungsfähigere erfordern mehr Credits pro Token.

In die Kosten fallen hinein: Input-, Output- und Cache-Tokens, so wie sie in der API-Abrechnung des jeweiligen Modells erscheinen. Eine Million Output-Token kosten dabei zwischen 1,25 US-Dollar für GPT-5.4 nano und 30 Dollar für GPT-5.5. Claude Opus 4.7 kommt auf 25 Dollar, Gemini 3.1 Pro auf 12 Dollar.

Einen Fallback auf ein kostenloses, einfaches Modell wie bisher (GPT-5 mini, GPT-4.1 und GPT-4o) gibt es nicht mehr. Anwenderinnen und Anwender, die ihr Budget aufgebraucht haben, müssen ein Update kaufen. Für Reviews kommen die üblichen Minutenpreise für Actions hinzu.

Free-Tarif bleibt

Immer gratis bleiben jedoch Code-Vorschläge und auch den Free-Tarif will GitHub erhalten, allerdings ist noch nicht klar, zu welchen Bedingungen. Derzeit sind es 50 Premium-Anfragen und 2000 Code-Vorschläge.

Der Anbieter rechnet damit, dass in den Pro-Tarifen insbesondere Anwender von Token-aufwendiger Nutzung von agentic coding mit höheren Kosten rechnen müssen. Damit begründet GitHub auch die Umstellung: „Die Nutzung von Agenten wird zum Standard und bringt signifikant höhere Anforderungen an Rechen- und Inferenzleistung mit sich.“ Das bisherige Tarifmodell berechnete Premiumanfragen an teure Modelle unabhängig vom Umfang der Anfrage. Die Komplexität der Anfragen und des Kontexts nimmt mit dem Einsatz von Agenten jedoch erheblich zu.

Automatische Umstellung ab Juni

Kunden der bisherigen monatlichen Tarife stellt GitHub automatisch um. Jährliche Verträge wird die Firma nicht verlängern und berechnet den Kunden während der restlichen Laufzeit einen Multiplikator für teurere Modelle. Ab Mai will GitHub auf der Abrechnungsseite in den Kundenkonten eine Übersicht zeigen, was die bisherige Nutzung nach der Umstellung kosten würde.

Als Zuckerl erhalten Business- und Enterprise-Kunden ein Addon in den ersten drei Monaten: Credits im Wert von 30 Dollar für Business- und 70 Dollar für Enterprise-Verträge („promotional included usage“).

Die vor einer Woche eingeführte Sperre für individuelle Neukunden wird laut GitHub mit den neuen Tarifen aufgehoben. Derzeit versuchen alle Modell-Anbieter, die Kosten zu optimieren. Zuletzt experimentierte Anthropic mit dem Ausschluss von Claude Code aus den Tarifen von Einzelanwendern.

In der Diskussion auf der FAQ-Seite kritisieren Anwender insbesondere den Wegfall der kostenlosen Modelle bei Überschreitung des Budgets. Viele sehen das als Hauptvorteil des bisherigen Copilot-Tarifs gegenüber der Konkurrenz.

(who)

GitHub CLI erhebt mit Version 2.91.0 Telemetriedaten. Die Datensammelei des offiziellen Kommandozeilentools von GitHub erfolgt clientseitig in pseudonymisierter Form und ist standardmäßig aktiv. Anwenderinnen und Anwender, die das nicht wollen, können per Opt-out aussteigen.

Die Datenerhebung dient laut GitHub dazu, die agentische Nutzung von GitHub CLI besser zu verstehen. Dazu benötigt das Entwicklungsteam einen Einblick in die praktische Nutzung der Funktionen. Die gesammelten Daten würden in der internen Analyseinfrastruktur von GitHub landen. Nachdem das Telemetriefeature anfänglich lediglich in den Release Notes zu Version 2.91.0 erwähnt und in die Dokumentation aufgenommen wurde, hat es GitHub inzwischen auch offiziell in seinem Blog kommuniziert.

Die Dokumentation für GitHub CLI nennt mehr als 20 Felder wie agent, architecture, is_tty und skill_names, die telemetrisch im Fokus stehen. Über die Umgebungsvariable export GH_TELEMETRY=log oder die Konfigurationsoption gh config set telemetry log lässt sich ein Protokollierungsmodus aktivieren. Wenn das Logging aktiv ist, gibt das Tool einen Einblick in die erhobenen Telemetriedaten, ohne diese jedoch tatsächlich zu übermitteln.

Drei Möglichkeiten zum Opt-out

Anwenderinnen und Anwender können GitHub CLI prinzipiell das Datensammeln auf dreierlei Arten untersagen: Über das Setzen der Umgebungsvariable export GH_TELEMETRY=false, wobei ein false-äquivalenter Wert wie 0 oder disabled ebenfalls funktioniert; des Weiteren über export DO_NOT_TRACK=true und zum Dritten per CLI-Konfiguration mit gh config set telemetry disabled.

Mit der Analyse von Nutzerdaten begann GitHub bereits im April dieses Jahres. Eine Änderung der Nutzungsbedingungen erlaubt es der zu Microsoft gehörenden Softwareentwicklungsplattform seitdem, Interaktionen der Anwenderinnen und Anwender mit Copilot Free, Pro und Pro+ für das Modelltraining der eigenen KI zu verwenden. Business- und Enterprise-Konten sind davon ausgenommen. Auch hier gibt es die Möglichkeit, dem per Opt-out zu widersprechen. Erwähnenswert: Das Arch-Linux-Paket deaktiviert die GitHub-Telemetrie ab Version 2.91.0-3 standardmäßig. Bei anderen Distributionen müssen Nutzerinnen und Nutzer selbst aktiv werden.

(mro)

Nach einer Einführung in das Framework Crux geht es im dritten und letzten Teil der Artikelreihe nun um fortgeschrittene Konzepte und die praktische Integration in realen Anwendungen. Die folgenden Punkte zu fachlichen Typen, Aufteilung in mehrere Apps und dem Einsatz in konkreten Shell-Technologien zeigen einen detaillierten Blick aus der Praxis.

Fachliche Typen

In langlebigen Softwareprojekten ist es ratsam, fachliche Typen unabhängig vom eingesetzten Framework zu definieren. Im Rahmen der in den vorherigen Teilen gezeigten E-Mail-App bietet sich zum Beispiel der Typ EmailAddress an: Dieser Typ kapselt die Validierung und Repräsentation einer E-Mail-Adresse und stellt sicher, dass nur gültige Werte im System verwendet werden. Die Logik zur Prüfung – etwa auf das Vorhandensein des Zeichens @ – ist direkt im Typ verankert und nicht Teil der Crux-App.

Dadurch bleibt die fachliche Logik klar von technischen Details getrennt. Sie kann unabhängig von Crux, anderen Frameworks oder der konkreten Plattform getestet, wiederverwendet und weiterentwickelt werden. Sollte sich die technische Umgebung ändern, bleibt die Kernlogik erhalten und muss nicht neu geschrieben werden.

Fachliche Typen wie EmailAddress erhöhen die Wartbarkeit und Verständlichkeit des Codes und schützen vor Fehlern, indem sie ungültige Zustände bereits beim Erstellen verhindern.

Listing 1: Fachlicher Typ EmailAddress

#[derive(Clone, PartialEq, Eq, Hash, Debug, serde::Serialize, serde::Deserialize)]
pub struct EmailAddress(String);

#[derive(thiserror::Error, Debug)]
pub enum EmailError {
    #[error("missing @")]
    MissingAt,
}

impl EmailAddress {
    /// Der Smart-Constructor garantiert eine gültige Adresse
    pub fn parse(s: impl Into) -> Result {
        let s = s.into();
        if s.contains('@') { Ok(Self(s)) } else { Err(EmailError::MissingAt) }
    }

    pub fn as_str(&self) -> &str { &self.0 }
}

Fachliche Typen wie EmailAddress lassen sich unabhängig vom Framework testen.

Listing 2: Tests für EmailAddress

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn valid_email_is_accepted() {
        let email = EmailAddress::parse("marcel.koch@example.org");
        assert!(email.is_ok());
        assert_eq!(email.unwrap().as_str(), "marcel.koch@example.org");
    }

    #[test]
    fn invalid_email_is_rejected() {
        let email = EmailAddress::parse("marcel.kochexample.org");
        assert!(email.is_err());
        assert_eq!(email.unwrap_err(), EmailError::MissingAt);
    }
}

Der erste Test prüft, dass eine gültige E-Mail-Adresse akzeptiert und korrekt gespeichert wird. Der zweite Test stellt sicher, dass eine ungültige E-Mail-Adresse (ohne @) abgelehnt und der passende Fehler (MissingAt) zurückgegeben wird.

Aufteilung in mehrere Apps oder Crates

Wächst das Entwicklungsteam der App, kann es sinnvoll sein, das Team und auch die Anwendung in mehrere eigenständige Apps und Crates aufzuteilen. Ein Kontaktmanagement könnte die bisherige E-Mail-App erweitern und alle eingehenden Kontaktdaten speichern, aktualisieren oder löschen. Dabei bekommt das Kontaktmanagement eine eigene Crux-App, verwaltet in einem separaten Crate. Dieses separate Crate beinhaltet ein abgegrenztes Feature und wird auch als Feature-Crate bezeichnet. Jedes Feature-Crate definiert dabei seine eigenen Events, Models, ViewModels und Effekte – das Model ist also explizit Teil des jeweiligen Features. Die Haupt-App integriert die einzelnen Feature-Crates und koordiniert deren Zusammenspiel.

Listing 3: contacts (Feature-Crate)

// contacts/src/lib.rs
#[derive(Clone, Debug)]
pub struct Contact {
    pub name: String,
    pub email: EmailAddress,
}

pub enum ContactsEvent {
    AddContact(Contact),
    RemoveContact(EmailAddress),
    EditContact(EmailAddress, Contact),
}

#[derive(Default)]
pub struct ContactsModel {
    pub contacts: Vec,
}

pub struct ContactsViewModel {
    pub contacts: Vec,
}

pub enum ContactsEffect {
    ShowContactAdded(EmailAddress),
    ShowContactRemoved(EmailAddress),
}

pub fn update(event: ContactsEvent, model: &mut ContactsModel) -> Vec {
    match event {
        ContactsEvent::AddContact(contact) => {
            model.contacts.push(contact.clone());
            vec![ContactsEffect::ShowContactAdded(contact.email)]
        }
        ContactsEvent::RemoveContact(email) => {
            model.contacts.retain(|c| c.email != email);
            vec![ContactsEffect::ShowContactRemoved(email)]
        }
        ContactsEvent::EditContact(email, new_contact) => {
            if let Some(c) = model.contacts.iter_mut().find(|c| c.email == email) {
                *c = new_contact.clone();
            }
            vec![]
        }
    }
}

pub fn view(model: &ContactsModel) -> ContactsViewModel {
    ContactsViewModel {
        contacts: model.contacts.clone(),
    }
}

Das E-Mail-Feature übernimmt die Funktion der bisherigen E-Mail-App:

Listing 4: email (Feature-Crate)

// email/src/lib.rs
pub enum EmailEvent {
    SendEmail(EmailAddress),
    EmailSent(bool),
}

#[derive(Default)]
pub struct EmailModel {
    pub last_sent: Option,
}

pub struct EmailViewModel {
    pub last_sent: Option,
}

pub enum EmailEffect {
    SendEmailRequest(String),
}

Die Haupt-App aggregiert die Feature-Modelle und koordiniert die Kommunikation:

Listing 5: Haupt-App-Integration (App-Crate)

// app/src/lib.rs
use contacts::{ContactsEvent, ContactsModel, ContactsViewModel, ContactsEffect};
use email::{EmailEvent, EmailModel, EmailViewModel, EmailEffect};

pub enum AppEvent {
    Email(EmailEvent),
    Contacts(ContactsEvent),
}

pub struct AppModel {
    pub email: EmailModel,
    pub contacts: ContactsModel,
}

pub struct AppViewModel {
    pub email: EmailViewModel,
    pub contacts: ContactsViewModel,
}

pub enum AppEffect {
    Email(EmailEffect),
    Contacts(ContactsEffect),
}

pub fn update(event: AppEvent, model: &mut AppModel) -> Vec {
    match event {
        AppEvent::Email(email_event) => {
            email::update(email_event, &mut model.email)
                .into_iter().map(AppEffect::Email).collect()
        }
        AppEvent::Contacts(contacts_event) => {
            contacts::update(contacts_event, &mut model.contacts)
                .into_iter().map(AppEffect::Contacts).collect()
        }
    }
}

pub fn view(model: &AppModel) -> AppViewModel {
    AppViewModel {
        email: email::view(&model.email),
        contacts: contacts::view(&model.contacts),
    }
}

Durch diese Aufteilung bleibt die Anwendung modular, testbar und erweiterbar. Jedes Feature verwaltet seinen eigenen Zustand und lässt sich unabhängig entwickeln, testen und warten. Die Haupt-App sorgt für die Orchestrierung und das Zusammenführen der einzelnen ViewModels zu einer konsistenten Oberfläche. So entsteht eine skalierbare Architektur.