Symposium 2026 reviews and feedback

Meetings
1

I am possibly a bit close, but anyway.

I gain the impression the remote audio worked well. This is thanks to
Geoff. Who setup a custom Microphone feed for Zoom from the room’s
Microphone.

The main issue was the presenter having to hold the big Microphone while
trying to type stuff on their laptop.

I have since realised that an appropriate (Boom?) Microphone Stand would
likely have solved that issue.

I liked all the presentations, but my favourite was the Easy Dairy
Presentation, not much (any) Delphi or any other code shown in it, but
It showed what you can do with the right (Mr Yes in this case) attitude.
And a bunch of work. I also wound up with a Stress Cow :slight_smile:

cow-1
cow-12439×2068 107 KB

Watching the Cow not wanting to be where it they wanted it to be, was
cool. (Reminds me of me at times) Also the big plasma cutter, chopping
assorted holes in the tubular steel.

Lunch was served a bit late but was good. “Late” was almost certainly my
fault, sorry about that. I remember running late last year, but forgot
we then largely caught up…

Other bits and pieces.

I liked the part (Malcolm) where the clients loved the AI integration
they made, but when the AI bill came in were quite shocked, and they
then downgraded the AI to the cheapest model that still worked
acceptably.

I have a bunch of stuff I need to look at, review from both Alister’s
and Michael’s presentation. Also seems that I likely need to learn
markdown a bit.

I like CNPack, my original use case for it was on a very old delphi that
did not have the highlighting for code sections. So sometimes very hard
to find a missing/misplaced end statement.

Feel free to add any reviews, comments, feedback you might have.

2

Good audio for the zoomers was at the expense of good audio in the room. I often struggled to hear the speakers clearly although I had no trouble last year.

3

It really needed someone to take a mike around the room, so that the zoomers could hear the audience

1 Like
4

I enjoyed it. I thought it was worth the expense of visiting in person.

My most valuable take was the the chat with the AI sends the whole conversation to the server, every time I type in a new sentence.

This was not obvious to me, it should have been perhaps.

This explains

  1. Why a session becomes slower and slower
  2. Why it starts repeating itself
  3. Why it uses too much resources.

I will have to change how I use Claude.

I have also been inspired to run my own AI on a NUC, it can do everything else except tricky coding. With no cost, no running out of resources and total privacy.

For people who may not have heard of RemObject’s Codebot. I have spent some time beta testing it, I should spend some more.

It integrates into the IDE itself and will, if you let it, do commits to your GIT, modify the files in the project itself, and compile the code for you. I believe it can do this cyclically. I am sure it can do a lot more. But I am a bit cautious of anything touching my repos, so I have not played with that part..

5

That’s annoying, will have to ask around and make sure its ok for everyone, next time.
Because I am very sure we could have turned it up a bit.

6

Well not always sent but the overall impact to context window usage, slowdown, etc is the same. Some IDEs will auto compact conversations when approaching the max context.

OpenAI’s newer (12+ months) Responses API supports conversation state where you only need to send the new prompt/tool response with each request, not the entire history of sent and received messages. That improves prompt caching which can make input quite a bit cheaper. It is easy to implement - you just remember the conversation ID from the first response and pass it with just the new prompt/tool response in future requests and omit sending the history. Prompt caching means that the input tokens are only one tenth the normal processing cost. Note that if you (or the tool you use) don’t use the conversation state feature and instead manage and send the full message history you should try to keep the system prompt and message history unchanged to get the most benefit from prompt caching. eg. Don’t include a “current date/time” in the system prompt that you update when sending each follow-up request.

The Anthropic API has prompt caching with reduced fees (more expensive for single prompt conversations but cheaper after that) but doesn’t support stateful conversations.