Repository navigation
v0.13.0: per-tool time limit
A time limit per tool, in both runtimes: one slow tool can get more time while StepTimeout stays short for every other step. Go module github.com/eadwinCode/agentic-kit/packages/go-agentenkit@v0.13.0, npm agentenkit@0.13.0 and use-agentenkit@0.13.0.
No breaking changes.
New: a tool's own time limit (#42)
Go: Tool.Timeout, or agentenkit.WithToolTimeout(t, 30*time.Minute). TS: withToolTimeout(tool, ms), which returns a copy of the tool.
- While a call runs, its step has at least that long, even when
StepTimeout(TS:stepTimeoutMs) is shorter. Once the call returns, the step is back toStepTimeout, counted from then. - A call past its own limit ends the step like a step past
StepTimeout: the samestep N ran longer than …error, naming the limit that ran out, and the same retry. - Other tools keep the step limit. A tool in the same step as a slow one shares its longer time.
- The tool must stop when its
ctxis done (TS: when itsabortSignalfires), as with the step limit. - It does not lift
SegmentTimeout, or a queue's own job limit, such as Flow's step time. Keep those longer than your slowest tool.
New: a subagent's own time limit (#42)
Go: SubagentsConfig.Timeout. TS: subagents.timeoutMs. A child's whole run happens inside one spawnSubagent call, so inside one step of the parent. This gives that call its own limit, so a child, and a slow tool inside it, can outlast the parent's StepTimeout.
Changed
- Go: a step whose tools include a timed tool now has a context with no
Deadline(), because a deadline cannot be moved later. When time runs out,ctx.Err()isCanceledandcontext.CausesaysDeadlineExceeded. The timed call itself gets a real deadline. Steps with no timed tool are as before. - Go: a timed-out step keeps the provider's own error text, for example
context deadline exceeded (stream read: context canceled). TS keeps it as the error'scause. - TS: a step whose time runs out just as the model finishes now fails and retries, as in Go.