Skip to content

vocab: should @fallback / @maxTokens be first-class on core template.toolcall? #237

Description

@dmealing

Question

Should @fallback and @maxTokens be first-class attributes on core template.toolcall, rather than each provider/consumer re-registering them (or riding them on the attr.properties bag)?

Context

From a tool-call modeling review of a reference-impl consumer: the throw-vs-fallback contract and a per-call token budget are genuinely in the metadata, but @fallback is carried on the attr.properties bag and @maxTokens isn't modeled at all (the runtime hardcodes max_tokens). A registered @fallback was "one entry away" from the existing @retryReminder pattern.

These are common enough across LLM tool-call consumers that promoting them to core template.toolcall (registered attrs, conformance-gated) may be warranted — vs keeping them provider-extension concerns. Run them through the ADR-0037 decision procedure + ADR-0023 (needs the can't-be-computed justification + a registry-conformance fixture in all five ports if promoted).

Related runtime findings from the same review (separate from the vocab question): max_tokens is a hard 1024 and stop_reason is never read, so a long tool-call response truncates into a deterministic double-failure → fallback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions