aaif-goose/goose · error
Failed to create token counter: {error}
Error message
Failed to create token counter: {error} What it means
count_context_tokens estimates the token count of agent-visible messages (used to report retained context around compaction) by first building a token counter with create_token_counter. Any failure in counter construction is re-wrapped with this message, so the {error} suffix carries the real cause (e.g. tokenizer/model initialization failure).
Source
Thrown at crates/goose/src/context_mgmt/mod.rs:214
Err(error) => {
warn!("Failed to count retained context tokens, using billable output tokens: {error}");
summarization_usage.usage.output_tokens.unwrap_or(0)
}
};
Ok(CompactionResult {
conversation,
usage: summarization_usage,
retained_context_tokens,
})
}
/// Estimate the tokens of the agent-visible conversation, counted the same way
/// as the fallback estimation in `check_if_compaction_needed`.
pub(crate) async fn count_context_tokens(conversation: &Conversation) -> Result<i32> {
let counter = create_token_counter()
.await
.map_err(|error| anyhow::anyhow!("Failed to create token counter: {error}"))?;
let total: usize = conversation
.messages()
.iter()
.filter(|message| message.is_agent_visible())
.map(|message| counter.count_chat_tokens("", std::slice::from_ref(message), &[]))
.sum();
Ok(total.try_into()?)
}
/// Check if messages exceed the auto-compaction threshold
pub async fn check_if_compaction_needed(
provider: &dyn Provider,
conversation: &Conversation,
threshold_override: Option<f64>,
session: &crate::session::Session,
) -> Result<bool> {
if provider.manages_own_context() {
return Ok(false);View on GitHub (pinned to 3810898a74)
Solutions
- Read the wrapped {error} detail — it identifies the exact initialization failure
- Fix the underlying cause: ensure network access to tokenizer assets on first use, or clear/repair the token-counter cache
- Where possible rely on session.usage.total_tokens (session metadata) instead of estimating, as check_if_compaction_needed already does when usage is present
Defensive patterns
Strategy: fallback
Validate before calling
// Warm the token counter once at startup and surface its error early: create_token_counter().await?; // after this, count_context_tokens cannot fail on counter creation
Try / catch
match count_context_tokens(&conversation).await {
Err(e) if e.to_string().contains("Failed to create token counter") => {
// fall back to a rough estimate (chars/4) or skip reporting; do not abort the session
}
other => other?,
} Prevention
- Initialize the token counter during provider warm-up, not lazily mid-session
- Ensure first-run network access for tokenizer assets or pre-seed the cache
- Prefer session.usage.total_tokens when the provider reports usage
When it happens
Trigger: Calling count_context_tokens when create_token_counter() fails — typically tokenizer assets cannot be loaded (offline first run, missing cache) or the underlying model/tokenizer init errors out.
Common situations: Air-gapped or proxied environments where tokenizer files cannot be fetched; corrupted token-counter cache; calling the context-token helper before any provider has warmed up the tokenizer.
Related errors
- Failed to create token counter: {}
- Failed to compact: context limit exceeded even after removin
- Cannot resume with provider or model changes because provide
- /compact is not available for provider '{provider}' because
- No agent-visible tool pair found for tool id: {}
AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16).
Data as JSON: /api/errors/73ac4bc89f90e7d3.
Report an issue: GitHub.