1
00:00:00,079 --> 00:00:05,380
You run a long test suite with Claude
Code, it fails, and right when you expect

2
00:00:05,500 --> 00:00:09,920
Claude to dive in and fix the bug, it sits
there and makes another tool call just to

3
00:00:09,960 --> 00:00:11,399
read a text file on disk.

4
00:00:11,657 --> 00:00:13,857
Oh, mate, the truncation tax!

5
00:00:14,458 --> 00:00:17,837
I cannot tell you how many times I have
stared at my terminal in the shed,

6
00:00:18,237 --> 00:00:22,298
watching Claude run pytest, hit that old
four thousand character wall,

7
00:00:22,697 --> 00:00:25,918
write a temp file, and then burn a whole
extra turn just going,

8
00:00:26,458 --> 00:00:27,937
oh, let me read that file for you.

9
00:00:28,167 --> 00:00:30,007
It was so frustrating!

10
00:00:30,114 --> 00:00:35,607
Every single build error or stack trace
over four thousand characters forced that

11
00:00:35,674 --> 00:00:37,687
extra Read tool call round trip.

12
00:00:37,847 --> 00:00:42,887
But in version two point one point two six
one, Anthropic actually added settings to

13
00:00:42,940 --> 00:00:46,967
raise how much command and background task
output Claude receives inline.

14
00:00:47,077 --> 00:00:50,077
Yeah, they brought in two new knobs in
settings point json,

15
00:00:50,597 --> 00:00:54,597
bashOutputMaxChars and taskOutputMaxChars.

16
00:00:55,258 --> 00:00:58,318
And you can crank those suckers all the
way up to one hundred and twenty eight

17
00:00:58,477 --> 00:00:59,418
thousand characters!

18
00:00:59,739 --> 00:01:02,299
Wait, so one hundred and twenty eight K
inline?

19
00:01:03,079 --> 00:01:04,799
How do you actually set that up in your
config?

20
00:01:04,875 --> 00:01:05,595
Super easy.

21
00:01:05,675 --> 00:01:09,275
You just pop open your local dot claude
slash settings point json,

22
00:01:09,408 --> 00:01:14,315
or your global one in your home directory,
and you add bashOutputMaxChars set to one

23
00:01:14,382 --> 00:01:18,395
three one zero seven two, that is one
hundred and thirty one thousand seventy two

24
00:01:18,453 --> 00:01:19,355
characters.

25
00:01:19,488 --> 00:01:24,555
Do the same for taskOutputMaxChars, and
boom, no more disk dumps for standard test

26
00:01:24,635 --> 00:01:25,275
runs.

27
00:01:25,292 --> 00:01:29,532
That means when you run npm test or
pytest, the whole failure log,

28
00:01:29,552 --> 00:01:33,292
the entire stack trace, streams straight
into conversation context.

29
00:01:33,383 --> 00:01:35,212
Single turn debugging is back!

30
00:01:35,348 --> 00:01:38,227
Well, yeah, but, uh, there is a catch
here, James.

31
00:01:39,147 --> 00:01:41,887
We gotta talk token hygiene versus
execution speed.

32
00:01:42,216 --> 00:01:45,996
Right, because one hundred and twenty
eight thousand characters is not free in terms

33
00:01:46,016 --> 00:01:46,797
of prompt space.

34
00:01:47,304 --> 00:01:47,824
Exactly!

35
00:01:48,524 --> 00:01:52,924
Pumping one hundred and twenty eight K of
inline text dumps roughly thirty thousand

36
00:01:53,045 --> 00:01:57,885
tokens straight into your prompt context
on every single command execution.

37
00:01:58,744 --> 00:02:03,145
If you are running something insanely
chatty like docker build or npm install with

38
00:02:03,204 --> 00:02:07,885
verbose flags on, you are basically
shoveling token cash straight into the furnace!

39
00:02:07,917 --> 00:02:11,837
So if you crank the buffer cap to max, you
really need to pair it with smart test

40
00:02:11,885 --> 00:02:12,397
filtering.

41
00:02:12,537 --> 00:02:17,197
Don't just dump all logs, filter your test
runners down to only output the failing

42
00:02:17,255 --> 00:02:19,197
assertions or specific packages.

43
00:02:19,208 --> 00:02:19,848
Spot on.

44
00:02:19,960 --> 00:02:24,888
Keep the output clean so those thirty
thousand tokens actually carry useful bug

45
00:02:24,958 --> 00:02:28,568
details instead of wall to wall dependency
progress bars.

46
00:02:28,583 --> 00:02:29,623
Makes total sense.

47
00:02:29,760 --> 00:02:34,183
Beyond the inline buffers, there were a
few other really nice developer polish

48
00:02:34,243 --> 00:02:36,743
updates in two point one point two six
one, right?

49
00:02:36,750 --> 00:02:38,430
Oh, absolute gems!

50
00:02:38,563 --> 00:02:43,070
My favorite CLI flag addition is append
subagent system prompt file.

51
00:02:43,283 --> 00:02:47,950
If you build massive subagent prompts, you
used to hit OS command line length limits

52
00:02:47,984 --> 00:02:50,270
trying to pass them as raw string
arguments.

53
00:02:50,370 --> 00:02:54,430
Now you can just read that massive
subagent prompt straight off disk from a file.

54
00:02:54,417 --> 00:02:56,897
That is huge for complex agent workflows.

55
00:02:57,037 --> 00:03:01,777
And speaking of CLI comfort, they finally
fixed the prompt input keybindings to

56
00:03:01,817 --> 00:03:03,857
match native Bash shell muscle memory.

57
00:03:04,001 --> 00:03:09,057
Ctrl W deletes back to whitespace, Alt F
and Alt D jump by words,

58
00:03:09,110 --> 00:03:11,137
so typing feels way less janky now.

59
00:03:11,664 --> 00:03:16,284
Mate, my fingers were tripping over fresh
code constantly before that fix!

60
00:03:17,004 --> 00:03:18,764
And they also beefed up safety prompts.

61
00:03:19,364 --> 00:03:25,264
The dangerous rm safety check now catches
rm r f inside double quoted subshell

62
00:03:25,324 --> 00:03:26,844
scripts and positional parameters.

63
00:03:27,042 --> 00:03:31,202
So less chance of accidentally nuking your
repo while letting Claude automate heavy

64
00:03:31,246 --> 00:03:32,162
terminal scripts.

65
00:03:32,402 --> 00:03:35,922
Crank those inline buffers up to one
hundred and twenty eight K,

66
00:03:35,954 --> 00:03:39,362
tune your test filters, and save yourself
those extra round trips.