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)

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.

Richard Seidl spricht in dieser Folge mit Thomas Fehlmann über Quality Function Deployment (QFD) und die Rolle von Ursache-Wirkung-Denken im Zeitalter großer Sprachmodelle. Sie diskutieren, wie Unternehmen mit QFD Kundennutzen greifbar machen und diesen Nutzen systematisch in Softwaretests übersetzen können.

Thomas Fehlmann ist seit 2016 offiziell im Ruhestand – theoretisch. Praktisch jedoch bleibt er ein aktiver und leidenschaftlicher Forscher. Seine Arbeit präsentiert er regelmäßig auf internationalen Konferenzen, wo er Erkenntnisse mit Fachkollegen diskutiert und seine neuesten Ergebnisse veröffentlicht. Ursprünglich prägten Themen wie Six Sigma und Prozesssteuerung seine wissenschaftliche Laufbahn. Doch seine Neugier für Künstliche Intelligenz (KI) reicht viel weiter zurück: Bereits im Studium beschäftigte er sich intensiv damit – und blieb der Disziplin treu, selbst durch mehrere KI-Winter hindurch. Heute widmet sich Thomas Fehlmann der Frage, wie Graphmodelle der kombinatorischen Logik helfen können, das Innenleben moderner KI-Modelle nachvollziehbarer zu machen. Sein Fokus liegt darauf, besser zu verstehen, wie KI funktioniert und welchen realen Mehrwert sie für ihre Nutzer schafft.

Software-Testing im Gespräch

Bei diesem Format dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Warum KI keine Ursache-Wirkung kann – und QFD hilft – Thomas Fehlmann“.

(mdo)